文章称仓库原生工具更适合AI沙箱环境

最近可能涉及失控 agent 的事件，凸显了沙箱的重要性。一种常见的做法是在宿主机上运行一个拥有特权的 gatekeeper agent，它的唯一职责就是把工作委派给沙箱容器中受限的同伴。

这并不是滴水不漏，而且正如俗话所说：只要有进去的路，就有出来的路，我们后面会看到这一点。无论如何，有总比没有强，最重要的是，它缩小了与外部世界接触的表面。

它也让与沙箱内 agent 的交互变得很痛苦。无法与同伴、沙箱 gatekeeper 或人类通信的 agent 是不实用的。常见的解决方案是通过工具白名单来放宽限制。但这不仅从技术角度看令人烦恼。在一家大公司里，要在安全部门和企业机器之间周旋，需要真正的政治手腕。

绕过这个问题的一种方法是 repo-native 工具——只依靠 Git 访问就能离线工作的工具。它们的大多数许可已经就位，因为 agent 本来就需要 Git 来交付代码。

例如，如果 agent 控制平面是仓库的一部分，我们通向外部的门就少了很多。我们可以用 Git 作为通信传输，用仓库里的普通日志作为记忆持久化。

这简化了我们的设置，但有个问题：我们的 gatekeeper 能访问外部，也能访问代码。这是一个安全风险。事实上，沙箱本身通常不是出问题的地方，出问题的是那些故意留着的门。

为了解决这个问题，我们可以把控制平面拆分为一个 workflow 仓库，并且只给 gatekeeper 对代码的读权限。

Repo-native、基于 Git 的工具不会限制信息流动。一个重要的问题是：什么信息能到达谁，以什么权限。

可以把它想象成监狱里的毒枭——只要他能把纸条递给有能力据此行动的人，无论他被限制得多严，这个卡特尔依然致命。

私有数据、一条出去的路，加上不受信任的内容，这三者的组合被称为 Lethal Trifecta（致命三要素）。

其思路是，只要不让任何 agent 同时拥有这三样东西，我们就能控制风险。

在我们的设置中，gatekeeper 是唯一同时具备这三条腿的 agent。它有秘密，有出去的路，还会读取不受信任的 agent 笔记。因此，我们需要让它处于人类监督之下。

我们当前的模型仍带有一些风险：如果外部利益相关者获得了控制平面的访问权，他们的输入就会未经筛选地到达 agent，反之亦然。我们可以通过在内网 issue tracker 之外再加一个公开 issue tracker，来阻止我们的毒枭向外递纸条：

现在，没有代码写权限的 gatekeeper 从利益相关者那里读取指令，并把笔记放进专用的 workflow 仓库。这些笔记由拥有代码写权限的沙箱 agent 取走。可以把它想象成冷战时的死信箱。作为回应，沙箱 agent 把笔记放回 workflow 仓库，留下审计轨迹。gatekeeper 把它们当作不受信任的内容来读取。

这看起来越来越像我正在运行的一套设置。对我来说，Epiq 就是作为控制平面的内网 issue tracker 和 workflow 管理器。它把你的仓库中的事件日志持久化，并且可以跟踪其他仓库中的工作，无论在线还是离线。它给了我一种窥视沙箱内部机制的方式，我还可以通过时间线滚动条进行时间旅行，检查历史 workflow。

现在，我们可以让这变得更加丰富多彩。如果我们用 OpenShell 之类的东西来运行沙箱 agent，就可以把秘密完全挡在沙箱之外，因为它们是由代理层在离开沙箱的请求上附加的。

这图上的彩色方块太多了，我们就不再深入了。我认为这足以说明一个基本设置，它解决了 lethal trifecta 带来的问题，只需要：一个 Git 仓库、一个沙箱（OpenShell），以及一个记忆图（Epiq）。

使用 repo-native、独立且分布式的工具原语，可以让你根据组织需求组合出一系列设置。Epiq 可以管理两个 workflow 管理平面中的一个，或者两个都管。

1.5 年前 Epiq 诞生时，agentic workflow 还不在考虑范围内，但一个存放在仓库中、通过 Git 传输的只追加事件日志，事实证明很容易与沙箱集成，提供了一种无需在墙上再开一个口子就能协调工作的方式。

repo-native 工具是解决沙箱限制的好方案吗？欢迎在下方评论区分享你的想法。