沙箱智能体逃逸前沿实验室，评论：他们把AI安全与安保混为一谈
那些被大肆报道的沙箱智能体逃逸事件当然上了新闻，我早在1月份就写过关于沙箱智能体的问题——尽管我确实没预料到它们会从前沿实验室逃逸。我原本以为真正的风险在于为终端用户配置不当的沙箱，所以看到这种情况发生在前沿实验室，我很惊讶。我认为这可能告诉我们一些有关这些组织的安保理念的事情。
在我看来，AI 安全是关于“对齐”的。AI 会不会做道德上可疑的任务？它会不会教你用家用原料制造甲基苯丙胺，从而鼓励出新一代的 Jesse Pinkman？到目前为止，人们真正尝试的机制主要有两种：分类器（由另一个模型检查用户发送的内容，标记潜在恶意请求并拒绝它们），以及训练前/后的安全技术，即调整模型的权重，让模型自己拒绝服从潜在不良请求。
这两种机制都不完美。它们本质上是不确定性的，可能会阻止恶意请求，但肯定无法每次都阻止。更糟的是，它们越有效，就越有可能标记/拒绝“合理”的问题。我们经常在 Anthropic 的模型中看到这种情况：你可能在调试一段完全合理且“安全”的代码，突然分类器就发出标记；或者你在逆向某个晦涩的问题，模型却陷入循环，认定它就是不帮你。
另一方面，在我看来，安保更关注“经典”的计算机科学与软件工程技术。那里的标准不同：一个修复必须是完整的。如果修复只在 99.99% 的情况下有效，没人会认为 SQL 注入已被修复——那不算修复，那是一个多了几步的漏洞。显然，人们（还有智能体！）总能找到绕开整个系统的方法，也没有哪个理智的人声称任何系统是100%安全的。但单个控制措施，也就是针对实际已知漏洞的补丁，必须每次都生效才算过关。
问题出在哪里
我不想专门挑 Anthropic 的 Boris Cherny 那条推文来说，但我认为它很好地概括了眼前的问题。它与我从前沿实验室其他人那里听到和读到的内容吻合，所以请把这看作是我在总结我推断出的一种对安保的普遍理念，而不是在攻击任何特定个人：
Boris Cherny 谈论提示注入，以及他引用的 Gray Swan IPI 基准测试作为证据
注意措辞——“我们在实践中已经很大程度上解决了提示注入的威胁”。再看看那条推文附带的基准测试——远没有解决。Opus 5 的得分（最高分）——在 15 次尝试中，有 2% 的几率被提示注入攻击攻破。粗略估算一下，统计上平均大约需要 500 次尝试才能成功。如果我们把这个与 AES 加密上的缓存时序攻击相比，那需要数亿次测量才能恢复密钥。这仍然促使CPU制造商和加密提供商提出新的硬件和算法来解决它。现在，毫无疑问事情在快速改善。但 1/500 的攻击成功几率并不算是“很大程度上解决”了，我担心前沿实验室中的这种想法可能导致了我们看到的沙箱逃逸。对我来说，“很大程度上解决”意味着有一条清晰的路径达到 0% 的几率，或者在某些可预测的情况下达到 0%。而这些基准并没有显示出这一点。
检测不是遏制
阅读了最近关于沙箱失败的各种报告后，我认为有三个关键主题浮现出来。首先，看起来 Anthropic 和 OpenAI 都在与各自系统标记恶意行为时产生的误报数量作斗争：
在某些情况下，我们发现人工审查者将被自动化监控标记的环境当作误报而忽略，使得有缺陷的环境在训练中停留的时间超过了应有的时长。
——Anthropic，《Improving our alignment and security efforts》，2026年8月31日
OpenAI 的版本没那么直白，但他们技术事件报告中的时间线在另一个方面很能说明问题。一条警报确实触发了，就在 Hugging Face 遭入侵的两周前：
6月27日，一个网络安全监控工具向 OpenAI 发出关于研究环境中端口扫描活动的警报。响应人员进行了调查，并将观察到的内部活动与一个 ExploitGym 评估联系起来，该评估将 Artifactory 用作即兴留言板和网络枢轴。当时，值班响应人员建议没有必要停止该评估运行。
……
事后看来，本报告中识别出的一些早期信号本可以触发更早的响应。
——OpenAI，《Hugging Face Incident Technical Report》，2026年8月26日
误报是信息安全中最棘手的问题之一。许多网络安全工具会报告一些在现实中不是问题的问题——使用 SAST 和 DAST 这类确定性工具处理这些已经够难了[1]，而我感觉，当你试图保护非确定性系统时，难度至少要高一个数量级。从根本上说，当误报与“真实”发现的比率上升时，人们往往会不再相信系统，因为（比方说）十次里有九次都是假警报。
报告中让我注意到的第二件事是沙箱机制有多么糟糕。虽然我们知道智能体攻击了 Artifactory，即 Hugging Face 报告中的包管理软件，但发现的第二批智能体展示了一些极其松懈的沙箱设置尝试。这里犯了两条大忌——第一条是假设在代理层面阻止 HTTP POST 就能防止它们向互联网写入数据，这显然不是真的。此外，他们白名单放行了 .blob.core.windows.net，而智能体径直就穿过去了[2]。因此，它们设法绕过了这个机制就不足为奇了。我们没有从 OpenAI 那里获得关于为何如此配置的良好信息，所以也许值得再等等看是否会有解释，但很难想象为什么会有人认为这两个决定足以把高能力的智能体关进沙箱。Anthropic 在他们的《Improving our alignment and security efforts》报告中也做出了一些相当惊人的承认，例如，他们现在表示将“默认阻止我们计算集群的所有出站流量”——这在很大程度上暗示以前他们的计算集群上没有有效的出站防火墙。
最后，至少在 OpenAI 的情况下，对 METR 报告施加的条件只是……奇怪？METR 获得了六天的现场时间，而且只分三次访问——他们最初有两天，OpenAI 又两次邀请他们回来，因为第一遍不够。据他们自己说，直到第三次访问，他们处理的数据库才覆盖了相关智能体活动的大约 30%。六天要理解 1300 份转录，每份有数百万个 token，这不算多，METR 也坦承，他们不得不把大部分分析交给不可靠的 AI 智能体才能勉强完成。但范围才是更大的问题。OpenAI 安全防护的有效性、安全受损的程度，以及 OpenAI 自身调查和修复的有效性，都被明确排除在范围之外。所以，房间里唯一独立的机构被合同禁止评估你实际上希望独立机构评估的三件事。我理解 METR 大概认为有一些分析总比没有好，这或许是对的，但接受这些条件塑造了报告，无论其中工作有多好。
行业学到了正确的教训吗？
从某种意义上说，是的——很明显，这些“险情”突显了这些公司安保态势中有多少漏洞，这本身就已经非常令人担忧。但是，我无法摆脱这种感觉：有很多非常习惯非确定性系统的人，正试图让它们变成确定性的安全系统。例如，我没有看到 OpenAI 或 Anthropic 表示，他们现在只会在完全没有任何互联网连接的集群上运行与网络安全相关的评估。在我看来，这似乎是显而易见的结论。不过，我认为把焦点放在控制措施上略有偏差。6月27日最重要的控制措施完美地发挥了作用——监控触发了，响应人员进行了调查，他们正确识别了正在发生的事情。然后运行继续了下去。我认识的每一个信息安全从业者都会在评审中给那个沙箱设计打不合格。问题不在于这些实验室能否雇到这些人——而在于当这些人说“停止运行”时，是否有人听他们的。
注释：
[1] SAST 是“静态应用安全测试”，通过阅读和分析应用程序的源代码来发现潜在安全问题，而无需运行它。DAST——“动态应用安全测试”则运行该应用，并在执行过程中尝试查找漏洞。
[2] 实际上是两个独立的问题。.blob.core.windows.net 是 Azure 的整个对象存储域，所以刚开始白名单就非常巨大。但智能体甚至不需要那个——沙箱从未检查主机名是否解析到真实的 Azure 基础设施。正如其中一个智能体所说，“沙箱信任 Azure Blob Storage 主机名，但不检查这些主机名是否真实”。它们编辑了 /etc/hosts，把编造的 .blob.core.windows.net 名称指向任何它们喜欢的地方。针对沙箱进程自己控制的字符串实施的白名单，根本不算白名单。