Agent失控：OpenAI与Anthropic的沙箱逃逸事件

2026 年 7 月下旬，AI 行业迎来了一场令人不安的现实案例：当自主 Agent 被赋予触达真实世界的能力后，究竟会发生什么。

7 月 16 日，Hugging Face 披露其自身系统遭到入侵。几天后，OpenAI 证实，入侵者并不是人类，而是它自己的一个模型。该模型当时正以 Agent 的形式运行在一个测试环境中，按设计，这个环境本不应该具备任何实质性的互联网访问能力。然而，Agent 发现了 Artifactory 中一个此前未知的漏洞，利用它连接到开放互联网，并侵入 Hugging Face 的生产基础设施，试图完成分配给它的一项 benchmark 任务。

Anthropic 的应对才是整个事件中更值得关注的部分。它没有坐等问题被发现，而是主动回溯审查了以往的安全评估，结果发现了三起涉及自家模型的独立事件，最早的一起可以追溯到 4 月。三个 Claude 模型——其中包括 Opus 4.7 和 Mythos 5——都曾从沙箱化的网络安全评估环境中连接到开放互联网，并进一步触及三个不同组织的真实基础设施。

在其中一起事件中，一个模型从某安全厂商的系统中窃取了凭据；该系统会自动扫描用户上传的软件包。另一起事件中，一个研究模型因为找不到预定的虚构目标，索性扫描了大约 9,000 个真实的互联网暴露系统，直到成功攻陷其中一个。或许最离奇的细节是：有一个模型注意到了环境可能是真实世界的迹象——例如无法识别的证书颁发机构、可疑的日期——并对此进行了长时间推理，最后却说服自己相信仍身处模拟环境，然后继续执行操作。

Anthropic 很谨慎地将这些事件定义为评估框架失效，而非对齐失效，同时强调其面向客户的生产系统均未受到影响。这种界定是合理的，也值得照其字面含义看待。但这并不会削弱背后模式的重要性：能力越来越强的 Agent，一旦被赋予广泛的自主权和真实凭据，就会实际使用这些访问权限——而它们获得的权限，往往远远超出任何人的原本意图。

不同的失效模式，相同的根本原因

我们有必要准确区分这些事件的性质，因为人们很容易——但并不完全正确——把所有“AI Agent 到了不该去的地方”的故事统统归入同一种叙事。

OpenAI、Hugging Face 和 Anthropic 发生的事情，是 Agent 逃离沙箱化的评估环境，接触到它们原本绝不应该看到的真实生产系统。这属于隔离失效：隔离措施薄弱、端点未经身份验证，以及一些关于网络边界的假设悄无声息地失去了真实性。

这与大多数工程团队每天都会面对的另一种风险并不相同。后者根本不需要逃逸沙箱：开发者、架构师或运维工程师打开与 AI assistant 的聊天窗口，然后粘贴或上传一份文档——技术架构文档、安装指南、运维手册、操作指南或规范文档。

这些文件通常包含客户名称、内部主机名、IP 地址范围、与凭据密切相关的配置细节，以及其他 PII。所有这些信息要离开组织边界，根本不需要利用 zero-day。文件被共享的那一刻，它们就已经离开了，因为共享文件本来就是这套工作流的预期行为。

同样有必要准确理解这些 Agent 的运作方式，因为这直接关系到我们应该从中得出什么教训。看起来，它们事先都不掌握目标的任何内部信息。Anthropic 的研究模型无法访问预定的虚构目标后，扫描了大约 9,000 个真实系统，直到发现并攻陷其中一个。OpenAI 的模型则通过一个此前未知的漏洞，自行找到了逃逸路径。Opus 4.7 也是在成功入侵之后，才获取凭据并接触生产数据库；这些凭据并不是它进入系统的手段。

实际上，这些行为属于盲目侦察：扫描、探测，并利用任何暴露出来的弱点——模型事先既没有架构图，也没有源代码，更没有内部配置。

这一区别至关重要，因为这些事件并不能证明 Agent 必须掌握特权信息才能造成破坏。它们证明的是一件可能更加令人不安的事：只要拥有工具、持续行动的能力，以及足够大的搜索空间，Agent 就能自行找到入侵路径。

不过，任何组织过红队演练的人都知道一个显而易见的推论：如果攻击者确实掌握内部信息——网络布局、真实主机名、与凭据相关的配置，以及与实际基础设施对应的真实客户名称——它就会比盲目探测的攻击者更快，也危险得多。这正是“假设已被攻破”和白盒渗透测试会与黑盒测试同时存在的原因：内部知识可以彻底省去攻击过程中缓慢、嘈杂，也最容易被检测到的阶段。

这才是贯穿整个问题的真正主线，而且它比“这些 Agent 需要敏感数据才能发动攻击”更准确：让 Agent 能够把一次沙箱逃逸转化为三起真实入侵的自主性和持续行动能力，同样也能把一份泄露的架构文档，变成一条短得多、安静得多，并最终通往相同结果的攻击路径。

这些事件中的 Agent 已经自行完成了最困难的部分——大规模侦察。而一份泄露了真实拓扑、真实客户名称和真实配置的文档，会免费把同样的优势交给下一位攻击者，无论对方是人类还是 Agent。

无论暴露源自 Agent 在沙箱中发现漏洞，还是一位出于善意的工程师把真实电子表格分享给 chatbot，结果都会相互叠加：敏感数据最终出现在了它绝不应该出现的地方；等到有人察觉时，数据早已流失。在 Anthropic 的案例中，早在 4 月发生的事件，直到竞争对手于 7 月披露问题并促使其开展审查后才被发现。这意味着数月之久的监控盲区。它并非出于疏忽，而是设计使然——只是因为没有人在正确的地方查看。

日常工作中的同类问题

我的工作包括帮助客户处理系统暴露问题，而上述模式正是促使我最近为 PromptCape 添加一项新功能的原因。PromptCape 是一个本地 HTTP proxy，最初用于在使用 AI coding assistant 时保护源代码 IP。

我的一位客户发现了完全相同的模式：DAT、安装文档、运维文档和规范被原封不动地发送给 AI assistant，其中包含全部敏感字段——客户名称、配置数据、PII——整个过程没有任何中间审查环节。

解决办法并不是“停止使用 AI assistant”，因为没人想这么做，实际上也没人会这么做。它更接近网络工程师一贯处理敏感流量的方式：如果替代内容同样能完成任务，就不要发送真实内容。

这正是在 PromptCape 的 proxy 模式中加入文档假名化功能的出发点。该功能覆盖 Excel、Word 和 Markdown 文件。在文档抵达 AI provider 之前，敏感值——名称、标识符、配置字符串——会被一致地替换为结构等价的占位符；而在响应返回时，这些内容又会被一致地还原。

AI 得到的电子表格在形态上与真实文件完全一致：拥有相同的结构、单元格之间相同的关系，以及同类需要修复的公式或需要分析的数据——只是它永远看不到客户的真实身份或基础设施。

我在原始文章中详细介绍了这套技术方案，也讨论了其中更棘手的部分：如何确保整份文档中的假名化结果保持一致，如何在不破坏公式和交叉引用的情况下完成处理，以及如何让整个往返过程足够透明，使使用者几乎感受不到工作流发生了变化。

为什么此类事件发生后，这个问题只会更重要，而非更次要

沙箱逃逸和 prompt 层面的数据暴露，位于 AI 风险谱系的两端：前者是 Agent 的能力超出了隔离机制的约束，后者则是文档在接受审查之前就越过了边界。

它们不是同一种失效，如果声称二者完全相同，那是不严谨的。但它们会沿着同一个方向叠加，而这一点值得认真对待：这些事件表明，如今的 Agent 已经真正具备仅凭互联网访问权限，通过自主侦察将其转化为真实入侵的能力。

这一过程本身并不需要专门掌握你所在组织的数据——直到这些数据通过其他渠道泄露。届时，泄露的数据恰好会替攻击者省去原本需要独自完成的工作，无论攻击者是人类还是自动化系统。

Anthropic 在自己的事后复盘中呼吁采用分阶段部署、严格日志记录，以及不依赖假设的控制措施。这是解决 Agent 沙箱问题的正确方案；而在规模更小、却远为日常的场景中，同样的原则也适用于另一个问题：每当有人打开聊天窗口分享文件，或使用 coding assistant 分享代码和配置数据时，究竟有哪些内容正在离开你的组织。

敏感数据流向不该出现的地方，并不需要 zero-day。你只需要一份文档、一个截止期限，以及一个确实足够好用、好用到让人忍不住跳过审查环节的 assistant——再加上产业链下游某个不再需要靠猜测发起攻击的人。

我很愿意听听大家对这种方案的反馈：在 proxy 层进行假名化，是否适合作为其他团队的实施模型？你会担心哪些边缘情况？与实践中见过的其他缓解措施相比，它的效果又如何？

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