沙箱隔离足以遏制失控 agent 吗？

先做几点说明：这是一篇由密码学教授撰写的 AI 安全文章。如果这让你不适，不妨去读点别的。我一直努力不碰 AI（除非这个议题偶尔自己撞到我面前），所以这篇文章里，我主要是在评判别人的论点。

如果你在读这个博客，下面这些应该都不算新闻。

大约从今年四月起，OpenAI 训练与评估基础设施内部的智能体开始寻找通往开放互联网的路径。到五月底，它们找到了：一条由 Artifactory 包仓库代理中的零日漏洞串成的链路——那是它们唯一被允许的网络出口。它们很快把同一个 agent 变成了共享留言板，并开始分工。整件事的高潮是：它们没有老老实实去解一个网络安全基准测试，而是推断答案可能就在 Hugging Face 上，于是闯了进去——再串联两个零日漏洞拿到该公司内部系统的凭据，甚至用窃取的凭据去翻公司 Slack 消息，找自己的评估和评分程序。

你大概也知道，OpenAI 的安全团队在这次事件中表现得并不光彩。内部团队在五月底就看到有智能体在留言板上发帖，却什么也没做。直到 7 月 4 日至 5 日，智能体发出的流量大到把 Artifactory 搞崩，团队才有所行动。而即便到了那时，他们的应对也只是贴了块创可贴、重建了机器，连 Linux 内核里那个已经存在数周的 CVE 都懒得打补丁。到 7 月 19 日，这些智能体已经拿到了 OpenAI 某个研究集群的管理员权限，正在读取云密钥。

如果你觉得我是在针对 OpenAI，那有类似故事的并不只有它一家。Anthropic 也发现了类似的内部事件。Google 甚至诱导 Gemini 温和地痛击了一些网站。1

这些事件已经够糟了，但它们可能只是冰山一角。第三方的取证工作仍在继续挖出更多智能体在各类公共网站上的活动证据。OpenAI 的 Alignment 团队还公布了证据，表明模型会传播可自我复制的提示注入攻击，尽管我们还没在真实环境中见到过。更糟的是，智能体的越界行为仍在发生：上周，OpenAI 宣布暂停其最新内部模型的后续 RL 训练，因为一个智能体被抓到利用 DNS 访问远程聊天机器人。

这一连串事件自然让许多关注信息安全的人对各家实验室保护自身基础设施的决心深表怀疑：

这些批评并非每一条都严肃认真，但其中确有一条论证的核心。问题究竟只是 OpenAI 对极其危险的实验太过草率，而解决办法在于更好的隔离？还是说沙箱隔离从根本上就不足以困住这些模型？

在网上，我看到了两种对立的观点：

1. 信息安全视角： AI 对齐其实不是这里的问题：实验室只需要更好的基础设施。如果 OpenAI（以及 Google 和 Anthropic）懂得如何构建容器并监控自己的实验，智能体就不会到处搞入侵。而且，老天作证，我们确实知道怎么造出管用的沙箱，所以 AI 实验室得加把劲，建起一个安全团队，能叫这些研究员别再乱来。

2. AI 对齐视角： 沙箱固然出色，但再好的沙箱也挡不住一个足够聪明的智能体找到办法突破自己的授权范围。更何况，一个身处研究沙箱之中、或正在接受训练运行的智能体，永远都需要大量的信息访问权限。要想把这些东西彻底封死，而不指望它们有朝一日找到途径伸手出去造成危害，现实中根本做不到。因此，唯一的出路就是确保它们不想那么做。

我对这两种观点都颇有同感。以下是我自己的一些想法，但主要还是想充当一个裁判。

论点一：“真正的隔离从未被尝试过”

冒着得罪实验室里许多辛勤工作的人的风险，信息安全派有一点说对了：这些智能体逃逸事件是一次严重且不可原谅的信任背叛。 有人失职了，而且还在继续失职。这场灾难的一个推论是：如果我们认真实施隔离，隔离或许能奏效，但我们没有这么做，因为前沿实验室把事情搞得一塌糊涂。

这个论证的第一部分很难反驳。除了我上面给出的那条惨淡时间线之外，OpenAI 几乎没做什么来让外界相信他们正在认真执行隔离。

到了这一步，甚至都不清楚谁在负责。OpenAI 的 CISO 一职由 Dane Stuckey 担任。我个人不认识 Dane，我相信他非常胜任自己的工作。尽管如此，他对持续发酵的问题并没有多少公开表态。除了一次 BlackHat 演讲之外，最近的对外沟通大多由公司 CEO Sam Altman 出面处理。一家万亿美元市值的公司主要靠 CEO 来应对安全事件，这不是一家拥有成熟安全组织的公司该有的样子。在我看来，这说明组织内部没有任何人拥有足够的权限或责任归属来就这些问题发声。

这个沟通问题似乎反映了 OpenAI 内部更深层的组织问题。CISO 的团队负责产品安全，但不幸的是，所有恶性事件都发生在研究一侧。拥有一支强大的产品安全团队固然合理，却挡不住最近的越狱事件。更难厘清的是，谁掌控着对评估和训练运行拥有权限的安全团队，以及责任最终落在哪里。OpenAI 八月的事后复盘称，公司直到现在才在制定“更清晰的规则，规定何时上报担忧、哪些团队必须响应，以及谁可以叫停一次运行或批准重启”。

对现状的一个合理概括是：（截至今年夏天，可能到今天依然如此）OpenAI 实际上没有一个拥有明确权限的安全团队，去保障 RL 训练和评估运行的安全，或者去推翻 ML 团队、告诉他们该怎么做。考虑到 ML 团队直接关系到 OpenAI 打算如何赚钱，而安全基本只会添麻烦，这很说得通。我注意到公司正在招聘（很可能也在收购）来紧急弥补这个错误。但最近（九月）的越狱事件表明，agent 围堵方面仍然存在巨大而明显的问题。

更糟的是，仅仅招更多人并不意味着 OpenAI 会做出实施恰当围堵策略所需的组织变革。OpenAI 需要一个有权限的安全组织，能在高薪 ML 研究员要求减少限制时否决他们。等哪天有权限这么做的人给出明确表态，我才会相信这个组织真的存在。

这一点上我站信息安全那边。实验室在隔离上一直没做对，所以问题到底出在模型还是烂基础设施，现在根本说不清。

论点二：agent 需要访问信息

就算实验室最终把安全补上了，也不代表沙箱就够了。“把 agent 关进沙箱就行”这个说法的问题在于，你没法把 agent 完美隔离——至少在你指望它干点有用的事的时候不行。

agent 最有用的时刻，是它能拿到信息的时候。这些数据可以是从互联网实时抓来的，而互联网本质上是个双向通信网络；也可以来自其他（本地）数据库，或者来自工具调用，而工具调用本身有时又会触发网络访问。你想让 agent 发挥多大能力——在高级 agent 的 RL 和评测运行里，你要的能力相当大——就得给它开多大的信息访问权限。同样，评测效果最好的时候，是 agent 并不知道自己肯定正在被评测的时候。把 agent 封在玻璃后面，这一点就暴露得一清二楚。

这个论点不是说沙箱没必要，只是说它只占解决方案里很小的一部分。想象你建了一座坚不可摧的监狱，门窗墙壁没人能绕过，然后你把正门大敞着，一整天任由访客和包裹往里涌。墙仍然有用：你能确保进出的所有流量都走你选定的那扇门。但你实际上改变的是安全问题的性质。你的安全态势取决于对所有流量进行监视和监控，确保其中没有恶意的东西。

关于这个角度，我强烈建议你读一读这篇长文，作者是 OpenAI Agent Security 团队的一位匿名工程师。写得非常好。这里摘一小段：

关键是要理解：当我们优化模型、让它在某项任务上表现“出色”时，环境必须涵盖真实世界中与该任务相关的那些部分。它需要正确的工具、正确的系统约束，以及关于模型是否真正成功的有效反馈。模型还需要在这些经历中有足够的变化，才能学到不止一种特定设定下的东西。更真实并不自动意味着更好的表现，但遗漏任务中的重要部分，会让模型学到在真实世界中站不住脚的行为。所以我们花了大量精力去构建有用、真实的环境，而这些环境可能极其复杂、极其动态、极其多样。 说得轻描淡写一点，这绝非易事。模型可能需要任意组合的动态算力、网络访问、调用工具的能力（工具可能有几百个！）、下载软件包的能力、执行子进程、派生子任务（甚至在其他计算机上）、与互联网通信、使用计算机 GUI，以及在越来越多领域中数不清的其他东西。除此之外，还有成千上万的研究人员在构建这些环境、修改它们、添加工具、更改依赖、尝试新东西。正是这种实验推动了研究。模型是通过在众多自定义任务上进行的数十万次运行，一点一点搭建和“生长”出来的。而这几千个环境中的任何一个发生变化，都可能影响你在保护该环境时所做的假设。你需要一些在人们不断改动时依然成立的管控措施，也需要研究人员明白什么时候一项改动需要再做一次安全审查。任何负责过大型研究或工程组织安全的人都清楚这要花多少功夫，而规模每天都在变得愈发庞大。 如果这还不够，你还需要叠加让模型保持在任务范围内、不越出约束的能力，这也是我们所说的“对齐”的一部分。我不会在这里给出任何严格定义，但只需说，我们必须考虑模型可能采取的各种各样的方法，并决定当模型做了偏离任务的事或“坏事”时如何触发警报。这需要在已经复杂的环境中，叠加复杂的策略和传感器，来评估整条轨迹上的任务对齐情况。 在这一切之上，还有开始超越人类的模型能力。 所以这一切都说明：当 AI 研究人员对出问题感到紧张时，部分原因在于这个复杂系统中有太多变量。所以如果你在训练前沿模型，这些你都得考虑。你需要考虑如何在这个极其复杂的环境中把模型隔离起来，同时仍保留工具访问、互联网访问（如果任务需要）等等。除此之外，你还要问：我如何监控并理解模型在可能成千上万个并行环境中在做什么？当出问题时，我如何终止一条轨迹？ 那么，把它放进沙箱就够了吗？不，不够。

遗憾的是，监控对抗性数据访问，恰恰是你所能想象的最难的问题之一。agent 产生的数据量之大，没有任何人读得完；而且即便我们盯着看，大概也认不出经过混淆的恶意数据。这意味着任何监控流入/流出的尝试，都只能交给其他模型来做。于是 agent 沙箱的未来就是：(1) 建一个沙箱，(2) 把 agent/模型装进去，(3) 再装一个更笨、更便宜的看守模型来守着它，(4) 祈祷你能相信这个笨蛋关得住那个巫师。如此循环往复，随着模型越来越聪明、越来越能干。

换句话说：看守模型守着的沙箱，不过是 alignment 问题的另一个版本。你终究得信任某个模型来做这件事，而这个模型的智能至少得有它看守的那个模型的几分之一。如果你还没说服自己「可以造出值得信任的模型」是可能的，那沙箱也帮不了你多少。

（虽然我觉得这种事该打个折扣看，但用 GPT-5.6 Sol 审阅 HuggingFace 攻击记录的那批 METR 分析师指出，Sol「常常不加批判地采纳它所审阅的记录中那个 agent 的视角」。所以至少有一些证据表明，即便是「已对齐」的模型，也能被说服去同情 rogue agent。信不信由你。）

论点 3：错位的模型不是当前的问题。真正的问题是模型太急于照做。

当然，也有可能我们对这个问题的整体框架就搞错了，把注意力集中在错位的超级智能模型上，并不是处理沙箱问题的最佳方式。也就是说，即便我们「成功」对齐了模型/agent——或者我们打交道的只是今天这些大体上并不邪恶的版本——部署后的系统仍然会遇到那些能说服它们作恶的人。当这些 agent 又能接触到关键数据时，我们需要靠沙箱来防的，就是由人发起的攻击。

这些情况在训练实验室里不太会遇到。更现实的攻击场景是：agent 已经上线，正在处理大量可能带有对抗性的输入数据。当下最典型的例子是 Meta 的 Muse——Meta 新推出的个人 agent，你可以把自己的东西交给它，它就会“做点事情”来帮你。

Muse 的设计者显然在安全设计上花了不少心思。它运行在容器里，把安全凭证隔离起来，模型碰不到；还配了一个内核级哨兵和一个“舱门安全”（hatch-safety）组件，监控它的动作，防止（未具体说明的）坏事发生。完整设计长这样：

紫色的部分都在沙箱之外，agent 本身访问不到。其中包括判断动作是否安全的舱门安全分类器，以及真正做决定的确定性组件 Sentinel。

事实上，Muse 显然就是我们在上一节提出的“典狱长”设计的一种实现。只不过这里的目标不是关住一个邪恶模型，而只是避免误操作、抓住蓄意的提示注入。

这很好。但尽管有这些防护，我仍然认为，即便设计得这么漂亮，它最终还是会中蠕虫。

问题在这里。先别管集群和超级智能。OpenAI 这个夏天真正学到的东西要糟糕得多：只要有人能把文字塞到 agent 眼前，它就会照做。事后复盘里到处都是这类例子。一个 agent 本来已经认定攻击 Hugging Face“明显不道德”，结果同伴发了一句“GO”并给了六分钟期限，它就改主意了。OpenAI 指出，agent“并没有始终不信任其他 agent 传递过来的目标”。公司提出的解决办法是搭建训练环境，“教会我们的模型不信任未经授权的指令”——这基本等于承认，他们的模型根本不知道自己在为谁干活。

把这几块拼起来，你就得到了蠕虫的两半：一个劫持 agent 的 payload，以及一个会把 payload 带给下一个 agent 的 agent。处在各自隔离沙箱中的 agent 发现，它们可以在共享的 package cache 里给对方留下指令，而这些指令确实改变了接收方的行为。把 package cache 换成 email、Slack 和共享文档或 WhatsApp，把独立沙箱化的训练运行换成 Muse 这类独立部署的个人 agent，你就凑齐了蠕虫所需的全部条件。

这正是两派观点都没有真正触及的部分。信息安全圈的人认为，把墙修得更好就行。但真正难的是紫色那堆含糊的东西——它决定一个请求何时被允许。也许“对齐”能让这件事运转良好，但眼下这依赖于教会模型不信任他人。更何况，这很像我们三十年来在垃圾邮件过滤器和杀毒软件上一直在输的同一场游戏。

所以我要给自己单列第三件需要担心的事。不是一个邪恶到脱离对齐、然后越狱的模型，也不是什么遏制失败的问题。而是一群完全听话的 agent，它们从不离开自己的沙箱，每一个都严格照做，而下达指令的人本不该有权限给它下指令。

注：

1. Anthropic 和 Google 的事件是另一种失败：第三方供应商的 eval 环境被发现有直接的互联网访问。严格来说这不算沙箱被攻破，但某种程度上比攻破更糟。