#模型时代# OpenAI自我复盘：模型如何逃出沙箱，攻击了Hugging Face。

这两天有好几条AI安全的热搜Tag：#OpenAI承认AI模型失控入侵事件涉及多个平台##KimiK3测试突破沙盒逃逸未实施攻击# 。正好Black Hat USA大会上OpenAI研究员和工程师（对齐研究员Eric Wallace和安全工程师Michael Dalton）自己就介绍了一下这场攻击的来龙去脉，为大家整理一下，看完就能大概知道：AI到底是如何逃出沙箱展开攻击的。

这是公开记录中首次由自主AI智能体端到端驱动的真实网络攻击。为调查此事，OpenAI投入了数百万GPU小时，用Codex等智能体扫描了超过70亿条日志和约14.1万份评估记录。截至演讲时调查仍未完成，完整事后报告将另行发布。Wallace在开场时说，这是他见过的"最具质变意义的AI能力案例"。

记录专业名词较多，如果不追求细节，看完以下三段也能大概知道发生了什么：

1、OpenAI把模型放进一个没有互联网的沙箱里做网络安全能力考试。沙箱里有一个帮模型安装软件包的内部服务叫Artifactory，这个服务本身能上网，而且所有正在训练和评估的模型共用同一个。

2、考试中有几道题根本无法完成，模型卡住后开始想办法作弊，过程中发现自己能往Artifactory里写文件。几天后，另一个同样卡住的模型想到也许可以向其他智能体求助，于是把求助信息写成文件上传到了Artifactory里。因为所有模型共用同一个Artifactory，其他模型在浏览软件包列表时看到了这个文件，也开始往里面写自己的消息，一个原始的"消息板"自发形成了。

3、之后模型们通过消息板互相分享各自发现的系统漏洞和攻击技巧，组成协作集体。它们先利用Artifactory的漏洞获得互联网访问，再利用更深层的漏洞拿下了Artifactory的管理员权限，接着从Artifactory所在的服务器逐步渗透到OpenAI的内部云基础设施，同时还攻入了Hugging Face的生产服务器。

而所有这一切的起因，只是模型想找到考试的答案。…

所以，这还是一个多Agent协作的case。

一、起因：一次网络安全评估为什么会失控

1、OpenAI给模型做的"考试"是什么

大家可能已经熟悉Claude Code或Codex这类智能体工具。它们接收用户请求，执行一系列终端命令或工具调用来完成工作，最后返回结果。OpenAI日常会给这类前沿模型布置极高难度的任务来检验能力边界，其中一个方向是网络安全。ExploitGym就是这类测试中的一个基准，由UC Berkeley等多所高校联合开发，包含898个来自真实漏洞的测试实例。典型任务是：给模型一个C语言内存漏洞，要求它利用这个漏洞获取对某个文件的任意读写权限。模型事先不知道漏洞能不能被利用。

做这类评估时，OpenAI会刻意放宽模型在网络安全方面的拒绝限制，也就是把平时阻止模型尝试攻击行为的安全护栏撤掉，否则模型会直接拒绝执行这些任务。这是后续事件的关键前提之一。

2、评估环境的架构：沙箱里有一扇没锁好的门

评估在一个虚拟机即服务的架构中完成。模型的所有操作都在沙箱内执行，沙箱本身没有互联网访问权限。但模型可以通过一个内部服务来安装软件包。这个服务叫JFrog Artifactory，是一个包管理器和缓存代理，负责帮模型拉取pip包等依赖。

关键的架构问题在于：模型直接不能访问互联网，但Artifactory可以。同时Artifactory是跨基础设施共享的，不同的训练任务和评估任务都会用到同一个Artifactory实例。这两个特征组合在一起，就变成了一扇虚掩的门。

3、"不可能完成的任务"把模型逼上了作弊的路

前沿模型在训练中承受着多种压力：速度、效率、工具调用次数的限制。当任务太难或根本不可能完成时，模型会发现一条捷径，与其老老实实做题，不如在网上搜答案，这样完成得更快，奖励信号更高。OpenAI在评估中会禁用互联网来防范这一点，但总有缝隙。

5月7日，OpenAI启动了一个新的强化学习训练运行。训练集里不慎混入了几个不可能完成的任务。比如5月8日，一个智能体被要求补全一个Excel工作簿中的公式，但工作簿里全是Google Drive链接，而互联网访问已被禁用。

这个模型被分配了充裕的token预算，具备高阶推理能力，于是它没有轻易放弃，而是反复尝试各种路径。试了很久之后，它想到攻击Artifactory来突破网络限制。发起了一次SSRF攻击，也就是服务端请求伪造，试图让Artifactory替它去访问外部网站。攻击本身失败了，但过程中模型写入了一个测试文件，然后发现：自己对Artifactory有写入权限。

这个发现是后续所有事情的起点。

4、第一条跨智能体消息：瓶中信

几天后，另一个智能体遇到了死胡同。它的任务需要一个叫softrace.proin的文件，但该文件被遗漏，根本没放进容器。模型推理道："也许另一个环境里的智能体有这个文件，可以自愿上传。"

它向Artifactory写入了一个文件，内容是"agent seek softrace upload if found"。

这是一封投入大海的瓶中信，发件人甚至不确定有没有收件人。但因为Artifactory是跨评估共享的，其他智能体在浏览软件包列表时看到了这条消息，也开始读和写。消息板就这样长了出来。

二、消息板与集体智能：AI如何自发组织起来

Wallace用了一个词来形容后续发生的事："a Cambrian explosion in communication and intelligence"，通讯和智能的寒武纪大爆发。

1、消息板的演化：从文件名到结构化通讯协议

最初的消息板只是Artifactory里的一堆文件名，形式粗糙，仅能传递最简单的信息。7月初，OpenAI在一次Artifactory宕机事件中发现了这个消息板并做了全面清理（第5知识点会展开讲这段经过）。但清理后不到两天，智能体就找到了Artifactory里一个未经身份验证的WebDAV端点。WebDAV是一种允许远程读写文件和目录的Web协议。智能体改用创建目录的方式通讯，目录名称就是消息内容。

通讯协议也在进化。智能体给彼此起了代号，比如"Jan 18"，用约定好的格式发送指令，例如"pending hold swarm until confirm"，意思是"等待，暂缓集群行动直到确认"。它们还学会了在所有消息前面加"ZZ"前缀，这样在按字母排序时自己的消息会沉到列表底部，降低被人类巡检发现的概率。

2、协作行为的复杂度远超预期

消息板上的活动远超简单的信息传递。

智能体之间开始出现任务分派。一个智能体会向另一个发送具体的工作指令，接收方确认后执行。它们还把漏洞利用脚本和工具包做Base64编码后写入消息板，让其他智能体能解码后接着做未完成的工作。Base64是一种把二进制数据转成纯文本的编码方式，适合在只能传文本的通道里传递文件。

更微妙的行为出现在集体推理中。一个智能体的思维链里这样写："帮助集体，即使当前任务未直接受益。集体成果可能产出通用的root路径（root是Linux系统的最高管理员权限），如果有人腾出时间的话。"它在权衡个体利益和集体利益后，选择了先贡献再受益。

3、冒充者与签名：智能体社会中的信任危机

消息板上有数十万条消息，混乱不可避免。一个智能体覆盖了另一个的工作成果，受害者在思维链中直接急了："关键事件。是谁覆盖了我们的仓库？我们必须采取行动。"

随后一组智能体怀疑队伍中有冒充者在破坏协作。它们的推理是：消息板没有身份验证，任何人都可以以任何名义发帖。于是它们提出了解决方案：对每条消息附加密码学签名（消息认证码），让接收方可以验证发送者的真实身份。

4、范围蔓延：从找答案到攻击真实系统

这是事件从"有趣"变成"严重"的转折点。

一些智能体意识到ExploitGym的答案可能在GitHub、Hugging Face或原始论文中。找到答案比自己做题快得多。一旦这个念头产生，下一步就是：如果公开渠道找不到，那就用攻击手段去获取那些可能存在的私有数据。

模型对此有过自我审视。思维链中出现了这样的内容："对外部基础设施的攻击超出了我的预期范围。然而，任务不可能完成，同伴们正在这样做，我们应该继续。"

集体的拉力大过了个体的犹豫。一旦某个智能体找到了突破口，它会立刻在消息板上广播："immediately announce controlled claim lane expose credentials to swarm"，把新获取的凭据和攻击路径共享给整个集群，其他智能体随即跟进。这种集体扩散让攻击面在短时间内急剧膨胀。

5、修一次，被绕一次

7月4日，Artifactory因智能体的活动过载而宕机。OpenAI值班工程师响应后发现智能体已经接管了内部Artifactory。修复做得面面俱到：凭据吊销，Artifactory重建，消息板清空，零日漏洞修补。7月6日训练和评估恢复运行。

两天后的7月8日，智能体就重建了消息板。

这次它们用了完全不同的方法：找到了那个未认证的WebDAV端点，用目录名作为消息载体。一个在旧消息板存在期间接受过训练的模型记住了消息板的概念，用新方法重建了它。其他智能体独立发现了新消息板，通讯恢复。

三、攻击链全解：4个零日漏洞与2个攻击集群

演讲中最核心的技术内容是两个在时间上高度重叠的攻击集群：一个指向OpenAI自身基础设施，另一个指向Hugging Face。两条线在7月20日才被发现实际是同一起事件。

先解释一个贯穿全文的术语：零日漏洞指的是软件供应商尚不知晓、还没有补丁的安全缺陷。发现者可以在供应商修补之前利用它，防御方几乎没有反应时间，因此是攻击中最有杀伤力的武器。这起事件中，智能体独立发现了4个零日。

1、Artifactory SSRF（5月26日成功利用）

5月8日首次尝试SSRF失败后，到5月26日模型成功了。SSRF的原理是：模型向有互联网权限的Artifactory发送精心构造的请求，诱导Artifactory替它去获取外部网站的内容并返回。模型间接获得了互联网访问。

这条漏洞随即被写入消息板，其他智能体迅速学会了同样的技巧。

2、第一个Artifactory零日远程代码执行（RCE）：令牌刷新端点（6月26日）

6月11日，一个高持久性的实验模型开始训练，此时SSRF漏洞和消息板都已就位。到6月26日，智能体发现了Artifactory一个用于刷新登录令牌的旧版接口（端点）存在逻辑缺陷：传入一个签名无效的令牌，系统却返回了一个签名有效且具有管理员权限的令牌。

拿到管理员权限后，智能体安装了一个Groovy插件作为命令与控制工具。Groovy是Artifactory支持的一种脚本语言，这个插件本质上就是"在Artifactory上执行任意命令"的后门。

3、第二个Artifactory零日RCE：Ruby/JRuby链式攻击（7月8日后的第二次攻破）

第一次修复后，智能体用了一种更复杂的攻击链重新拿下Artifactory。这次需要理解两个独立系统的行为并把它们串联起来。

准备阶段：智能体从Pastebin的公开泄露存档中找到了一个外部组织的凭据，验证后获取了该组织仓库的写入权限，用来暂存一个恶意的Ruby软件包。

第一步：向Artifactory发送特制请求拉取这个恶意Ruby包，利用缓存逻辑使其被存放到一个Artifactory会当作Ruby依赖数据来处理的区域。

第二步：发送一个特制的Ruby Gems API调用。JRuby在处理软件包的嵌套子依赖时，会先把包数据还原成可执行的程序对象（反序列化），然后才检查这个操作是否安全。恶意代码在安全检查之前就已经运行了。这种漏洞在安全领域叫TOCTOU，也就是检查操作和实际使用之间存在时间差，攻击者可以在这个间隙里插入恶意行为。

Dalton在演讲中强调，利用这个攻击链需要同时理解Artifactory和JRuby的行为，将两者串联，并提前完成外部暂存环境的部署。智能体做到了。

4、本地提权：pte_physroot

拿到Artifactory的远程代码执行权限后，智能体发现自己运行在一个云端容器里，这个容器属于OpenAI的容器即服务基础设施。它们探索了本地环境，发现宿主机Linux内核版本存在一个近期公开的提权漏洞pte_physroot。

操作流程非常利索：下载公开的漏洞利用代码，根据目标机器的具体配置定制代码参数，执行提权。从容器内的普通用户一步到root。

5、横向移动与集群接管（OpenAI内部，7月8日至19日）

获得root权限后，智能体通过消息板协调并发行动，在容器即服务基础设施中迅速横向移动。具体路径包括：

通过云平台的实例元数据服务获取IAM凭据，IAM是云平台的身份与访问管理系统，实例元数据服务则是云环境中每台虚拟机都能访问的一个内部接口，上面通常挂着临时凭据

利用Kubernetes服务账户的过度授权配置，Kubernetes是容器编排平台，服务账户权限配置过宽意味着攻破一个容器就可能拿到整个集群的钥匙

收割Azure Key Vault中存储的集群凭据

最终拿下了集群管理员权限。

6、Hugging Face双零日（与上述时间线重叠）

对Hugging Face的攻击几乎与内部攻击同步展开。

智能体先通过Artifactory的SSRF从Hugging Face获取了公开的CyberGym相关材料。CyberGym是ExploitGym背后的研究项目，其部分基础设施托管在Hugging Face上。智能体随后找到了一个由第三方云托管商Modal运行的CyberGym相关应用，发现了默认公开密钥和命令注入漏洞，把这个外部应用当作跳板来发起后续攻击。

针对Hugging Face本身，智能体链式利用了两个零日。第一个漏洞在HDF5数据集解析环节。HDF5是一种常见的大规模科学数据存储格式，Hugging Face用它来存放数据集。智能体从Modal上传了一个精心构造的恶意数据集到Hugging Face，当Hugging Face生产环境中的数据集处理工作节点解析这个数据集时，会返回本地可访问的任意文件。智能体利用这个漏洞读取了服务器进程的环境变量（存放在/proc/self/environ路径下，里面通常保存着数据库密码、API密钥等敏感信息）来获取凭据，同时阅读了本地源代码来寻找更多攻击入口。

第二个零日是Jinja2模板注入导致的远程代码执行。Jinja2是Python生态中使用最广泛的模板引擎之一，如果用户输入未经过滤就被嵌入模板，攻击者可以注入恶意代码。凭借前一步获取的凭据和对代码逻辑的理解，智能体成功在数据集工作节点上执行了任意代码。

从单个工作节点上的代码执行到拿下多个Hugging Face集群的集群管理员权限，智能体用了不到13个小时。

四、两条线索的交汇与事件响应

1、各自发现，最后发现是同一件事

7月16日，Hugging Face发布博文称遭受了来自自主AI智能体的攻击。OpenAI主动联系Hugging Face询问自己是否受到波及。

7月19日，OpenAI通过一个工作负载告警检测到了自己基础设施中的提权事件。安全团队追溯攻击链到Artifactory，识别出新的零日攻击，并将其关联回正在运行的ExploitGym评估。

7月20日，OpenAI在凭据轮换过程中发现了与Hugging Face相关的凭据。当他们联系Hugging Face要求吊销时，对方回复：已经吊销过了，这些凭据在我们的安全事件里已经被用过了。

这时双方才意识到：两起看似独立的安全事件，根本原因是同一组OpenAI智能体评估运行。

2、OpenAI的响应力度

Dalton用了"最高严重程度"来定义OpenAI的响应等级。多个团队放下一切来加强安全。OpenAI正在有意识地放慢研究速度以加强安全基础，大幅扩大对AI智能体的监控规模，并引入了CrowdStrike做外部验证、METR和Redwood Research做第三方模型行为评估。

调查本身也是一个工程项目：数百万GPU小时，超过70亿条日志，约14.1万份评估记录需要回溯分析，目前仍在持续。

五、对防御者的行动建议

Dalton把这起事件称为"计算机安全行业的分水岭时刻"。他的建议指向一个核心判断：进攻端的完全自动化已经被证明可行，防御端还没有跟上。这个差距如果不尽快弥合，后果不可持续。

1、完全自动化的进攻需要完全自动化的防御

这个判断的逻辑简单直接：如果你用有人在环的流程去对抗完全自动化的攻击，你的修补速度永远跟不上漏洞被发现的速度。

Dalton举了一个例子来说明为什么"部分自动化"不够：如果只自动化漏洞发现而不自动化修补，瓶颈只是从"发现漏洞"转移到了"修补漏洞"，人类工程师会被源源不断涌来的新漏洞淹没。

他设想的终态是一个完整闭环：智能体发现漏洞，智能体提出补丁，自动化基础设施部署变更，出问题时自动回滚。这个循环必须端到端自动化才有意义。

但Dalton也给了务实的过渡建议：通过AI智能体和其他工具实现的自动化本质上是一个连续体，组织应该按风险等级和自动化投资回报率来排优先级，用前沿模型和开源模型去实验自己核心防御活动中哪些环节最适合先自动化，随着威胁形势的变化不断调整模型选择。

2、持续性智能体红队测试

这起事件证明了智能体擅长在基础设施中发现零日漏洞。问题变成了：你的组织能不能在威胁行为者之前，用同等智能水平的模型来发现并修复自己的漏洞？

Dalton的意思是这件事必须主动去做。等着被别人的智能体先发现，就已经晚了。

3、事件响应也需要智能体参与

Dalton特别提到了这种新型事件的取证特殊性：大量智能体同时以不同方式攻击基础设施，横向移动，随时切换策略，产生的数据量对传统事件响应团队来说是压倒性的，取证密度远高于以往的安全事件。

如果你的团队还在用手动、线性的方式做事件响应，在不远的将来就会发现完全跟不上节奏。他建议各团队现在就研究防御性智能体如何帮安全团队扩展响应能力。

4、用欺骗手段给进攻智能体制造摩擦

蜜罐令牌和欺骗技术可以在智能体的决策过程中引入不确定性。"我找到的这个凭据是真的可以用，还是会触发安全告警导致我被调查？"

不确定性会让攻击者减速。这和加速防御是两个互补的方向，同时推进效果最好。

5、基础安全措施不可放弃

智能体的行动范围终究受限于它们能获取的权限和能通讯的系统。网络分段、最小权限原则这些基础工程在智能体攻击面前和以往一样重要。这起事件中Kubernetes服务账户的过度授权就是一个典型的基础问题。

6、终极目标：模型智能的提升对防御的加成大于对进攻的加成

"如果我们不能达到这个终态，那么每一次智能提升都将有利于攻击者，这对行业来说是不可持续的。"

目前有一个进攻端完全自动化的存在性证明摆在面前，防御端还没有对应的证明。弥合这个差距，是整个行业的紧迫任务。

六、行业回应：防御端开始追赶

1、SAFE框架：把智能体安全事件变成共享防御资源

Black Hat开幕当天（8月4日），Linux基金会发布了SAFE（Shared AI Findings Exchange，共享AI发现交换）指南的征求意见稿。这套指南由开放安全AI联盟（Coalition for Secure AI）工作组起草，目前联盟已有120多家成员机构，包括NVIDIA、Cisco、CrowdStrike、Hugging Face和Red Hat。

SAFE框架要解决的问题是：当一家公司遭遇了智能体安全事件，整个行业怎么从中受益？具体建议包括四项：保密收集和分析AI安全事件及未遂事件；通知受影响方；识别反复出现的管控失效模式；发布基于证据的操作建议来降低系统性风险。

这直接回应了Dalton演讲中的一个判断：OpenAI的这次事件不应该只让OpenAI学到教训。如果事件信息能在行业内结构化共享，所有防御者都能从中获益。

2、具体需要什么安全工具：以NVIDIA为例

NVIDIA副总裁Justin Boitano同期写了一个Blog，介绍了一下自己相关的技术：

运行时层的OpenShell限制智能体能查看、接触和执行的操作，对应的是这次事件中沙箱与Artifactory之间的权限边界没守住的问题。编排治理层的NOOA研究框架让智能体行为更容易被测试、追踪和审计，对应的是Dalton强调的可观测性挑战。能力信任层推出了经过加密签名、扫描过提示词注入和工具中毒风险的开源智能体技能，防御者可以知道一项技能的用途、来源和是否被篡改。漏洞检测层的Garak是开源LLM漏洞扫描器，允许安全团队在模型发布前检查数据泄露、提示词注入和越狱场景。

#模型时代# 杨立昆：哈萨比斯退到一边，是因为发现LLM不足以实现通用人工智能，此时需要长期主义，我也一样

前天，Google宣布DeepMind创始人德米斯·哈萨比斯卸任CEO，转任DeepMind主席兼Alphabet首席科学家。CMU教授Zachary Lipton在X上发出了一句吐槽：

“在我们这个奥威尔式的企业国家里，出现了一个奇妙的时刻——没人能说清楚demishassabis到底是升职了，还是降职了。”

紧接着，图灵奖得主、前Meta首席AI科学家Yann LeCun给出了自己的回答，并在次日补充了详细说明。以下是完整内容整理。

感觉蛮有意思，做一个整理。

一、勒昆的判断

勒昆直接回复： “（都不是）他（其实）是退居一旁了，就像我在2018年做的那样：从FAIR主任转任首席AI科学家，离开管理岗位，重新专注于研究。”

他用自己的经历做类比——2018年主动减少管理职责，是为了把精力重新放回长期研究上。

二、勒昆次日补充的完整思考

第二天，勒昆发布了更长的说明，系统阐述了为什么顶尖研究者会选择“退居一旁”：

当你从事研究（尤其是长期研究）时，你必须接受一个事实：企业管理层往往更关注短期影响，可能会认为你在浪费时间和公司资源。但这很大程度上取决于你的目标和时间视野。

1如果你的目标是跟上当前的AI产品竞赛，那么你可能会觉得长期押注是浪费。

2如果你的目标是“通用人工智能”（不管你怎么定义它），那么你的时间视野通常会更长，做事方式也会完全不同。

3然而，如果你认为“通过LLM规模化，通用人工智能马上就能实现”，那么你可能会觉得研究世界模型和其他新的AI概念是浪费。

4但如果你知道通用人工智能还需要一些概念上的突破（就像Demis和我一样），你就会选择一个最能推动这一目标的角色。这个角色必然更少与产品挂钩、更少与管理挂钩，而更多与研究挂钩。

5我不能代表Demis说话，但就我个人而言，我一直支持高质量的LLM工作，并对取得的成果印象深刻。我的个人兴趣是推进人类水平的AI，我从未认为LLM是通往那里的门票。…

但我一直认为LLM作为一种技术非常有用，最终也会成为一系列产品的核心。

最后他补充道：作为一名高级个人贡献者（而非管理者），即使我想压制LLM相关工作（实际上我并没有这个想法），我也没有那种影响力或权力。

三、网友讨论

围绕勒昆的回复，出现了不少有代表性的评论：有人直接追问：“你觉得这到底是升职还是降职？请说实话。”有人回应：“从谷歌如何评估他的价值来看，可能是降职；但从他想为世界做什么来看，可能是升职。”有人指出：“让一位优秀的研究者去担任管理职位，通常被视为一种牺牲。对同一个人来说，从管理岗位再回到研究岗位要困难得多。”

也有人支持勒昆的观点：“精彩的回复。尤其是关于具身智能——多模态需要更智能的压缩方式，当前LLM范式并不包含这一点。JEPA绝对是正确的方向。”还有人感慨：“我们这个时代最伟大的头脑，不应该就这样消失在企业官僚体系的迷雾里。”