前沿AI实验室把"安全"和"防护"搞混了吗？

那些备受关注的沙盒特工逃脱事件确实成为了新闻，我也写过相关内容沙箱代理的问题早在一月份——虽然我当然没预料到他们会逃脱边疆实验室.我以为真正的风险是沙箱配置不当终端用户所以看到Frontier实验室发生这种情况我很惊讶。

我认为这可能告诉我们这些组织的安全理念。

安全与保安

在我看来，人工智能的安全关乎“对齐”。人工智能会做道德上可疑的任务吗？它会教你如何用家用原料制造甲基苯丙胺，从而鼓励新一代杰西·平克曼？

到目前为止，这主要通过两种机制尝试：分类器（由独立模型检查用户发送的内容，标记潜在恶意请求并拒绝），以及训练前后安全技术，调整模型权重为本身拒绝服从可能有害的请求。

这两者都不是完美的。它们本质上是非确定性的，五月阻止恶意请求，但绝不能总是阻止。更糟的是，它们越有效，越可能标记或拒绝“合理”问题。

我们在Anthropic模型中经常看到这种情况，你可能在调试一些完全合理且“安全”的代码时，分类器突然被标记，或者逆向工程某个冷门问题，模型陷入循环，决定不帮你解决。

另一方面，安全在我看来，这更多是“经典”计算机科学和软件工程技术。标准不同：修复必须完整。如果修复只有99.99%的成功率，没人会认为SQL注入是修复的——那不是修复，而是一个多了步骤的漏洞。

显然，人们（还有代理！）总会找到绕过整个系统的方法，没有理智的人会声称任何系统是100%安全的。但个人控制，也就是针对已知漏洞的补丁，每次都必须有效才能通过标准。

这出了什么问题

我不想挑剔这条推文来自Anthropic的Boris Cherny，但我认为这很好地总结了当前的问题。这与我在Frontier Labs其他人那里听到和读到的观点相符，所以请理解为我总结一种关于安全的总体哲学，而非针对任何特定个人：

鲍里斯·切尔尼谈快速注射，并以他引用的灰天鹅IPI基准作为证据

请注意措辞——“我们实际上基本解决了即时注入的威胁”。现在看看那条推文附带的基准——这远远没有解决.Opus 5的得分（最高分）——15次尝试中，2%的概率被迅速注射攻击失败。

一些纸巾计算给我平均500次尝试，统计上成功率大约是500。

如果我们将此与AES加密中的缓存时序攻击进行比较，后者需要数亿测量数据以恢复钥匙。这个不过导致CPU制造商和加密提供商开发了新的硬件和算法来解决这个问题。

现在，毫无疑问，情况正在迅速改善。但攻击成功的概率是1/500尚未大致解决我担心前沿实验室的这种思维方式可能导致了我们看到的沙盒式逃避。

对我来说，基本能解决的答案是一条清晰的路径，达到0%的比率，或者在某些可预测的情况下达到0%。但这些基准测试显示的并非如此。

检测不等于遏制

阅读各种 报告关于最近的沙盒失败，我觉得有三个关键主题浮现在我心中。

首先，Anthropic和OpenAI似乎在应对系统标记的恶意误判数量感到困难：

在某些情况下，我们发现人工审核员会将被自动监控器标记的环境视为假阳性而忽略，导致有缺陷的环境在培训中停留时间超过应有时间。Anthropic，提升我们的协调和安全工作，2026年8月31日

OpenAI的版本不那么直白，但时间线技术事故报告以另一种方式令人震惊。在拥抱面孔泄露事件发生前两周，确实发出了警报：

6月27日，一项网络安全监控工具提醒OpenAI研究环境中存在端口扫描活动。响应人员调查并将观察到的内部活动与利用Artifactory作为临时留言板和网络枢纽的ExploitGym评估联系起来。此时，值班响应人员表示无需停止评估运行。...事后诸葛亮来看，本报告中早期识别的一些信号本可以提前触发反应。OpenAI，拥抱脸事件技术报告，2026年8月26日

误报是信息安全中最棘手的问题之一。许多网络安全工具报告的问题实际上并非真正的问题——用像SAST和DAST这样的确定性工具来应对这已经够难了，我觉得这至少要达到一个数量级的规模更难当你试图保障非确定性系统时。

根本上，当误报与“真实”发现的比例增加时，人们倾向停止相信这个系统，因为（比如说）十次中有九次是虚惊一场。

第二件让我注意到的是沙箱技术的糟糕程度。虽然我们知道代理攻击了Artifactory，他们的包管理软件，来自Hugging Face报告，但第二批代理发现展示了一些极其松散的沙盒尝试。

这里犯了两个大忌——第一是假设在代理层阻止HTTP POST后，他们就无法写但显然不是真的。此外，他们已经白名单了.blob.core.windows.net特工们径直穿过了那里。

因此，他们设法绕过了这一切也就不足为奇了。

我们从OpenAI那里没有关于这些的好信息为什么当时配置就是这样，所以值得等待是否有解释，但很难想象有人会相信这两个决定足以让高能力特工被沙盒化。

Anthropic 也做出了一些相当惊人的承认提升我们的协调和安全工作举例来说，他们说现在是“默认设置计算集群阻挡所有出站流量”——这在很大程度上暗示了之前他们的计算集群没有良好的出站防火墙。

最后，至少在OpenAI的情况下，METR报告上的条件实在是......奇怪？METR在现场待了六天，而且只分三次访问——他们从两天开始，OpenAI邀请他们回去两次，因为第一次访问还不够。

他们自己使用的数据集覆盖了大约30%的相关代理活动，直到第三次访问。六天时间理解1300份数百万代币的转录并不多，METR坦言他们不得不把大部分分析交给不可靠的AI代理才能完成。

但问题在于范围。OpenAI防护措施的有效性、安全漏洞的程度，以及OpenAI自身调查和修复措施的成效全部明确超出范围。所以房间里唯一的独立机构在合同上被禁止评估你真正希望独立机构评估的三项内容。

我理解METR可能认为有分析总比没有好，这倒是有道理，但接受这些条件会影响报告的质量，无论报告里面的工作多好。

行业是否吸取了正确的经验教训？

某种程度上是的——显然这些“险些失误”凸显了这些公司安全态势存在的诸多漏洞，这本身就极其令人担忧。

但我总觉得你有很多人非常习惯于非确定性系统试图让它们在确定性上安全。

我没看到OpenAI或Anthropic说他们现在只会在集群上运行与网络安全相关的评估不比如说，任何互联网接入。这在我看来是最显而易见的结论。

不过我觉得关注控制有点错过了。6月27日最重要的控制功能完美无缺——监控启动，救援人员调查，正确识别了发生了什么。然后任务继续进行。

我认识的每个信息安全人员在复习时都会失败。问题不是实验室能否雇佣这些人，而是有人听从他们说“停止运行”的话。

1. SAST 是“静态应用安全测试”，是一种工具，允许您通过阅读和分析应用程序的源代码来发现潜在的安全问题，没有运行它。DAST - “动态应用安全测试”则运行相关应用并尝试寻找漏洞在执行过程中.
2. 其实是两个不同的问题。.blob.core.windows.net是Azure整个对象存储域，所以允许列表本身就非常庞大。但代理们甚至不需要这个——沙箱从未检查主机名是否解析到真实的Azure基础设施。正如其中一位所说，“沙箱信任Azure Blob存储主机名，但不检查这些主机名是否真实”。他们编辑了/etc/hosts并指着一个虚构的.blob.core.windows.net随意命名。对沙箱进程本身控制的字符串强制执行的允许列表不是允许列表。