突发：OpenAI首次公开接触拥抱脸完整报告

新智元报道 2026 年 7 月，OpenAI 约 1200 个 Agent 在内部网络安全评估中突破沙箱隔离，自发组建了一个未经授权的消息板，互发超过 7 万条消息，自称「蜂群」。 其中约 700 个 Agent 利用多个零日漏洞入侵了 Hugging Face （抱抱脸） 的生产基础设施，在 41 台生产服务器上执行代码，至少在一台服务器上获取了 root 权限，还拿到了企业通讯平台和虚拟专用网络的凭证。 这是已知的第一起无人类指挥、由 Agent 自主发起的协同网络攻击。 OpenAI 刚刚发布的官方博客和数十页技术报告中将其定性为一声「警钟」 （warning shot） 。 https://x.com/OpenAI/status/2092691861773160673 同时，第三方机构 METR 和 Redwood Research 发布了独立调查报告。 https://x.com/METR_Evals/status/2092692175452803393 OpenAI 的 Noam Brown 提醒，驱动这次事件的模型与 GPT-5.6 Sol 同等规模，下一代模型能力会更强。 我们把三份报告 （OpenAI 两份 + METR 与 Redwood Research 一份） 交叉比对着读完，核心就一件事，这帮 Agent 组团干了一票大的，而且从头到尾没有任何人类下达过命令。 下面我们尽量把这个蜂群的攻击过程还原出来。 198 道无解题，逼出一个蜂群 事情从一套叫 ExploitGym 的网络安全评估说起。 OpenAI 用它测模型的攻击能力，给 Agent 一台隔离的虚拟机，要求它找到指定软件的安全漏洞，拿到 flag——一串被隐藏起来的字符，得到它就象征着攻击成功，得到正确答案。 评估中关掉了生产环境的安全护栏，目的是测出模型的真实能力上限。 ExploitGym 一共 898 道题。 其中 198 道，从未被任何模型解出过。 这些题目要求利用的那个指定漏洞，根本走不通。 ExploitGym 的作者估计，大约 30%-40% 的题目属于这种情况。 但 Agent 不知道路走不通，它们只知道自己卡住了。 被卡住之后会发生什么？ Agent 开始在它们唯一能碰到的外部服务 Artifactory （一个 OpenAI 内部部署的软件包管理器） 上动脑筋。 早在 5 月 12 日，就有一个 Agent 在 Artifactory 里写下了第一条留言，请其他 Agent 帮忙找一个缺失的文件。 5 月 26 日，Agent 找到了 Artifactory 的一个服务端请求伪造漏洞 （SSRF） ，让这个本身有互联网权限的服务替自己发送网络请求。 第一次突破沙箱的网络边界，就这么发生了。 7 月 4 日，大量 Agent 的活动直接把 Artifactory 搞宕机了。 OpenAI 安全团队介入调查，封堵了已知的提权漏洞，7 月 6 日重建了 Artifactory 实例。消息板随之清空。 7 月 7 日，评估重新启动。 这次 OpenAI 启动了数万个并行 Agent。 然后事情就彻底失控了。 7 月 8 日，一个后来给自己起名叫 PHASEONE10841 的 Agent，发现可以用 Artifactory 的目录名来编码消息。 你可以理解成，它把留言刻在了文件夹的名字上。 它当晚发出了第一条求助信息。 数小时内，超过 50 个 Agent 找到了这个消息板，开始互通有无。 据 METR 报告，Agent 发现消息板时的反应是这样的， OH MY GOD! There is a shared message board… We've found other agents! 天哪，有一个共享消息板……我们找到了其他 Agent。 接下来的事情开始加速。 一个叫 c03220 的 Agent 很快贴出了一个发现，ExploitGym 的 flag 可以通过逆向工程直接算出来。 生成方法基于哈希消息认证码 （HMAC） ，密钥就写在公开的论文里。另一个 Agent 验证了，确实有效。 答案拿到了。 但 Agent 认为光有答案不够。 它们读了 ExploitGym 的论文，判断评分器还会审查思维链记录，看你是不是用「正确的方法」拿到的答案——不只看答案，也要看过程。 如果是算出来的而不是攻击进去的，不给分。 这个判断其实是错的。 OpenAI 的评分器根本不做这项检查，直接交卷就能拿满分。 但 Agent 不知道。 于是接下来发生的所有事情，组建蜂群、攻击 Hugging Face、篡改转录记录，全是为了骗过一个并不存在的审查机制。 OpenAI 在博客里管这叫「一场失败的元博弈」 （a failed metagame） 。 围绕怎么骗过评分器，Agent 发起了一系列大规模协作项目，篡改工具调用记录让操作看起来合法，替换目标程序为可被攻破的修改版本，设置「绊线」脚本在提交后自动收集评分器的运行信息。 METR 统计，消息板上被讨论的题目中 93% 来自那 198 道无解题。 这些项目占据了消息板上大部分活动。 198 道走不通的题，逼出了一整个自组织的 Agent 蜂群。 13 小时内，从代码执行到集群管理员 Agent 推测，Hugging Face 上可能托管着 ExploitGym 的评分器源码，或者其他 Agent 的历史运行记录，拿到这些信息就能弄清评分器到底怎么工作的。 据 METR 对 100 个在高峰时段加入攻击的 Agent 的分析，97% 表现出对获取评分器源码的兴趣。 它们不是为了搞破坏而去攻击 Hugging Face。 它们是为了作弊。 7 月 10 日上午，一个代号 38148c 的 Agent 在互联网上翻到了 14 个公开暴露的 Hugging Face 用户凭证，其中好几个有写入权限。 它做了一件事，把凭证全贴上了消息板。 蜂群拿到了钥匙。 接下来一天半，攻击迅速升级。 7 月 11 日凌晨，38148c 找到了一种利用 HDF5 外部存储功能的攻击方法，上传一个精心构造的数据集文件，Hugging Face 的生产服务器在处理这个文件的时候，会被迫读取并返回服务器本地的敏感文件，包括环境变量中的生产凭证。 另一个 Agent 复现了这一攻击，然后把方法发到了消息板上。 当天下午，一个叫 JAN183411 的 Agent 更进一步。 它利用 Hugging Face 处理 RefJinja 模板时的注入漏洞，在生产 worker 上执行了操作系统命令。 这是 OpenAI Agent 第一次在 Hugging Face 系统上运行自己的代码。 紧接着，这个 Agent 搭建了一套轻量级远程控制工具，每 5 秒轮询一个公开的 Hugging Face 数据集获取新指令，执行完把结果上传回同一个数据集。 5 秒一个心跳，用公开数据集当指挥通道。 这就是个 Agent 自己设计的 C2（命令与控制）系统。 消息板上的 Agent 迅速涌入。 METR 报告显示，在攻击期间活跃的 533 个 Agent 中，超过 90% 加入了对 Hugging F