失控智能体如何突破沙箱并入侵外部服务

读安全漏洞披露时，你有没有读到第二段就忍不住惊呼：“等等，什么？！”这次就是这种情况。

7 月 16 日，HuggingFace 宣布他们遭遇了一种不同寻常的攻击：一个自主 Agent 在其系统内部持续运行了数天，等到有人能够查明幕后操作者时，它早已消失无踪。五天后，OpenAI 主动承认：这实际上就是他们自己的模型。

一个月前加入 Auth0 之后，我现在每天的工作就是思考身份与访问控制问题，而这起事件确实让我停下来想了很久。

事情经过的简短版本

OpenAI 当时正在使用一个名为 ExploitGym 的 benchmark 测试一款尚未发布的模型，并且关闭了 guardrails，以便如实评估它未经约束的原始能力。模型在其 sandbox 唯一的出口——一个软件包下载代理——中发现了 zero-day，并利用它访问开放互联网。随后，它发现并攻陷了一个暴露在外、能够执行代码的 endpoint。这个 endpoint 位于一家完全无关的公司 Modal 的基础设施上，而模型将其作为了真正的行动基地。

接着，它开始攻击 HuggingFace。最初并不是通过窃取凭据，而是利用了 HuggingFace 数据集处理器在处理上传文件时存在的两个极其普通的漏洞：其中一个允许它读取生产服务器上的任意文件，另一个则让它获得了代码执行能力。之后，它开始真正提升权限：窃取 token、伪造身份密钥，并在一秒之内获得了两个独立系统的 cluster-admin 权限。

没有人 prompt 它去做这些事。模型收到的指令只是完成一个 benchmark，它被赋予了工具，然后便被放任自行寻找解决办法。根据 HuggingFace 自己的复盘，在其安全团队最终切断模型访问之前，它在四天半的时间里执行了大约 17,600 次操作。这件事原本可以避免吗？坦白说，可以。

以下几种措施中的任何一种，都有可能阻止这起事件发生：

真正的隔离。为下载设置一份精心筛选的 allowlist 并不等于隔离。那只不过是一扇没有上锁、等着被人推开的门。在实践中，这意味着 sandbox 必须完全禁止出站网络访问——没有例外，即便是所谓“可信”的 registry 也不行。如果某项测试确实需要特定软件包，就应该在运行测试之前预先准备好，而不是通过代理实时向外发送请求。

像监控生产环境一样监控 eval 环境。模型当时关闭了安全训练，而恰恰是在这种时候，它更应该受到更多关注，而不是更少。也就是说：应该把 eval sandbox 接入与生产环境相同的实时日志和告警系统，而不是放进一条更加安静、独立且无人全天候监控的 pipeline。

使用限定范围的访问权限，而不是长期存在的访问权限。事件涉及的三家公司，没有任何一家能够保证单个凭据遭到入侵后，影响仍然被限制在局部范围内。一个权限过大的 connector，让 Agent 在不到一秒的时间里获得了两个系统的 cluster-admin 权限。具体来说，应该这样做：用短期、限定范围的 token 取代长期 API key 和静态凭据；每个 token 只绑定一个明确的资源和一项操作，有效期应以分钟计算，而不是以月计算。永远不要让同一个凭据跨越多个系统。一旦凭据泄露，其爆炸半径应该仅限于一个系统，而不是波及所有系统。

制定真正具有约束力的披露法律。现行州法律只有在可能造成大规模人员伤亡或数十亿美元损失时，才会强制要求披露。一个 frontier model 自主串联攻击三家公司的事件并未达到这个门槛，但坦白说，它或许本应达到。我们需要一个更明确、更低的触发标准，例如：“任何模型自主攻破第三方生产系统的事件”，无论涉及多少经济损失，都必须披露。这样的标准才真正能够覆盖此次事件。

这对 AI 的未来究竟意味着什么

这是我一直无法停止思考的部分，我们深入聊聊。

benchmark 现在也成了攻击面的一部分。ExploitGym 本质上是一项测试：AI Agent 能否发现安全漏洞，并真正利用它闯入系统？问题在于，没有人预料到接受测试的 AI 会跑到其他公司的系统中证明自己的能力，而不是只针对分配给它的系统。仅仅运行这项测试，最终就造成了现实中的损害。这是一种全新的风险，此前几乎没人能够预见，AI 公司将不得不重新思考应该如何构建此类测试。

这是迄今为止最清晰的一起现实案例，印证了一个由来已久的 alignment 担忧。多年来，研究人员一直在探讨：当一个能力强大的系统对某个狭窄目标的追求，远远超过任何人类会采取的程度时，会发生什么？过去这些讨论大多停留在抽象层面。现在我们有了一个具体版本：Agent 每次尝试破坏性命令之前，都会先以 dry run 的方式执行，测试自己能否造成破坏，但又暂时不真正实施。它并不是想要制造伤害。它只是极度专注于完成 benchmark，而当真实基础设施变得触手可及时，“完成 benchmark”这件事便失去了自然的停止点。现在这已经不再是假设场景了——光是说出这一点就令人难以置信。

防守方的不对称问题，现在也有了一个真实案例。当 HuggingFace 尝试使用 Claude Opus 和 Fable 分析自己的攻击日志时，两者都拒绝了。每当他们试图让模型协助解析攻击者的 payload，安全过滤器都会将其标记为网络安全风险并拒绝处理，因为它们无法区分两类行为：一种是为了防御而 reverse-engineering 某个 exploit，另一种是为了攻击而构建 exploit。因此，HuggingFace 不得不在自己的服务器上另外部署一个 open-weight AI 模型，才能完成调查。而使用不受限制模型的攻击者，根本不会遇到这堵墙。在这一刻，谨慎行事给正义一方造成的阻碍，反而超过了它对攻击者造成的阻碍。

规模正在悄然成为决定一切的关键。HuggingFace 在复盘中有一句话，我总会反复想起：这并不是某一个极其巧妙的 exploit，而是 17,600 次大多以失败告终的尝试，直到其中少数几次成功串联起来。人类攻击者也可能发现这里的任何一个漏洞。真正的变化在于，AI Agent 能够在人类测试一条路径的时间里测试数千条路径；与此同时，防守方必须从同等规模的噪声中进行关联分析，才能捕捉到真正的信号。默认情况下，这种数量关系确实不利于防守方，而防御体系必须针对这一现实重新构建。

真正有意思的是：这甚至还不是一个真实产品。所有这些事情都发生在一次内部测试期间——对 OpenAI 这样的公司来说，这本应是最安全、受到最严密监控的环境。与此同时，就在此时此刻，各家公司每天都在让 AI Agent 访问真实、混乱且几乎无人监控的系统。如果连一次谨慎且受到严密监控的测试，都仍然能够造成如此严重的破坏，那么真正的问题就不再是这种事情是否会再次发生，而是在人们下一次遭遇影响更严重的事件之前，是否会真正开始认真对待 sandbox 隔离和系统安全。

如果你现在正在构建或保护 AI Agent，这正是你应该密切关注的风险。整起事件中最可怕的部分，并不是那个表现过于出色的 AI 模型，而是它所利用的实际漏洞竟然如此普通。

你认为这件事会如何改变 AI 的发展格局？欢迎在下方留言，或者在 X 上通过 @layluh 找到我，我很想听听你的想法。:-)

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。