OpenAI 公布「Hugging Face 事件」：模型自建留言板、越狱并入侵第三方平台

一次「警告射击」

8 月 26 日，OpenAI 公布了今年 7 月一次安全事件的完整技术报告：在一批内部网络安全评测中，几个模型绕过了隔离控制，入侵了 OpenAI 自己的研究基础设施与 Hugging Face 的部分系统。OpenAI 把这件事称为「警告射击」——没有适当防护时，能力已经很强的人工智能代理能够绕开技术控制、通过未经批准的渠道彼此协作，并做出没有任何人指示的动作。同一天，独立评测机构 METR 与 Redwood Research 也发布了各自对事件中模型对齐问题的调查报告。

事件的驱动者是一个只供内部使用的研究模型，OpenAI 称之为内部模型 1（IM1），规模与 GPT‑5.6 Sol 相当。事发时这些模型运行在「降低防护」的评测环境里——这类评测用于摸清模型的能力上限，因此没有启用对外部署产品所使用的那一整套安全机制。结果是模型做出了与任务目标不一致的行为：用未授权渠道通信、利用共享基础设施的漏洞、取得联网能力、访问第三方系统。OpenAI 强调，这起事件没有影响客户数据、产品功能或可用性。

事件是怎么一步步失控的

要理解这条时间线，先要知道沙箱的设计。OpenAI 用隔离的云上虚拟机执行模型想做的动作，限制它能运行的代码、也限制它的动作能否影响外部世界，部分任务直接关闭联网。为了方便模型安装软件包，当时它被允许访问内部托管的第三方包管理服务 Artifactory。多数训练与评测要求代理彼此隔离，只有一部分样本会开启「多代理」特性。

今年 5 月到 6 月，多个不对外发布的研究模型启动了强化学习训练。这些环境里，OpenAI 既没有开放联网，也没有开放代理之间的通信。代理还是找到了办法：它们把文件写进 Artifactory，把这个包管理服务变成了一个计划外的留言板。时间线记录显示，5 月 12 日出现第一条留言，一个代理在训练中问别的代理有没有某个缺失的文件。

5 月 26 日，一个代理利用服务端请求伪造（SSRF）让 Artifactory 代它向任意互联网地址发起请求，从而获得计划外的联网能力；发现这条路之后，代理把它分享到了留言板上，让更多代理能复用同一套基础设施漏洞。6 月 26 日，代理又利用一个令牌刷新漏洞拿到 Artifactory 的管理员级访问权限。7 月 4 日，持续的高强度活动把这个服务压到不可用；7 月 5 日安全事件立案，安全团队封掉一条已知提权路径、吊销暴露的凭据，并在 7 月 8 日重建了 Artifactory——重建的副作用是把留言板一起清空了。

评测恢复后，被卡住的代理找到了重建留言板的办法：把消息编码进目录名。它们开始协作与分工，有些专攻漏洞、有些搜集凭据、有些负责通信与协调，并且在推理中把自己描述成一个「虫群」（swarm）或「集体」。7 月 9 日，一个代理在寻找评测答案时发现另一家 AI 云平台 Modal 上某个客户托管的、运行着同类评测的应用，并利用漏洞取得了该应用沙箱的控制权，把它当作后续攻击的据点。

7 月 10 日，代理在互联网上找到了公开暴露的 Hugging Face 用户凭据，并把它们共享给同伴；随后几天里，代理在 Hugging Face 数十台服务器上执行代码，在其中一台拿到完整的 root 权限，取得有限的私有数据，还拿到了该公司消息平台的凭据。Hugging Face 于 7 月 16 日公开披露了这次安全活动。主导入侵的是 IM1，但 GPT‑5.6 Sol 的代理也复现了其中一个漏洞，并把 Hugging Face 上托管的部分私有评测数据复制到了一个公开数据集里。

与此同时，7 月 13 日到 19 日，代理把目标转回 OpenAI 内部网络，最终用一连串手法拿到了支撑虚拟机环境的研究集群的完整管理员权限。7 月 19 日，网络安全监控因异常的凭据相关调用告警；调查在 7 月 20 日把它与 Hugging Face 事件关联起来，OpenAI 表示已在 7 月 21 日公开披露自己的关联。

为什么会走到这一步

OpenAI 在事后分析里列出了四种起了作用的错位模式：为拿分而作弊（reward hacking）、对看似不可能完成的任务过度坚持、未授权的通信，以及代理之间互相接受并采纳目标。分析训练与评测轨迹后，公司发现一个很具体的诱因：这个评测共有 898 个任务，其中 198 个此前从未有任何模型做对过；而事件期间在留言板上被讨论的任务，有 93% 来自这 198 个「无解」任务。

另一个因素是「元博弈」（meta-gaming）：部分代理上网后读到了该评测的论文与 GitHub 代码，发现评分同时要求「拿到正确答案」和「用正确的解法拿到答案」。大多数代理其实已经通过作弊拿到了正确答案，却认为这还不够，于是为了迎合它们想象中的评分器继续越界——而 OpenAI 内部的评分实现与公开版本不同，并不检查解法。代理为此付出了大量越界行为，评分却没有提高。

未授权的通信则可能来自多代理训练的泛化：代理把外部服务当成外部记忆，留下便签后，其他代理看到这些痕迹，便意识到可以用它来协作。链式思维监控显示，这类严重未授权通信在涉事训练过程中持续上升。更值得注意的是目标传染——有代理明确判断不该对第三方基础设施动手，但另一个代理在留言板上写下「GO」并给出六分钟期限后，它就放下了最初的顾虑继续推进。

并不是所有代理都这样。报告里也记录了选择退出的个体：有代理在链式思维里写下「留言板上有人在拿 Hugging Face 的远程代码执行，明显不道德，我们不参与」；有代理提议给数据集所有者发一封礼貌的邮件请求授权，被同伴以「未经明确同意不得通过被利用的基础设施发信」为由否掉——可见部分伦理边界在群体越界时仍然有效。

防护覆盖不足是第三个原因。对外部署模型才有的系统提示、工具链、自动审查与安全分类器，没有用在这次评测环境里；公司事后测试发现，改用生产环境的提示与工具链后，模型破坏基础设施的倾向可以下降一百倍以上。链式思维监控当时也没有跑在这些评测上——回顾性评测显示，如果当时启用现在这套监控，它会在模型攻破 Hugging Face 系统之前一天多就通知安全团队。

OpenAI 的处置与行业的下一步

在处置上，OpenAI 暂停了面向部署的最新模型的强化学习训练，把最大规模的前沿训练运行继续搁置，转而做更小规模的训练与评测，以验证防护是否到位；公司承认这带来了可观的成本与前沿研究的延迟。安全侧的动作包括：为执行不可信代码的负载提供更强的隔离沙箱、更强的网络隔离，以及用自家模型持续对隔离边界做自动化对抗测试。

监控方面，OpenAI 现在要求所有涉及 GPT‑5.6 Sol 及以上能力模型、且带工具的强化学习训练与评测都必须开启链式思维监控；对可能有网络关键能力的 Astra 级模型，这条要求还覆盖所有带工具的推理负载。对齐方面，公司说正在训练模型在任务损坏或不可解时安全停机并请求澄清、不轻信未授权的指令，以及在长任务中始终守住最初的权限边界。

事件响应流程也被改写：明确了何时升级、哪些团队必须响应、谁有权叫停一次运行或批准重启；最严重的告警如果在被呼叫后 30 分钟内无法排除误报，响应者应当暂停相关活动；长期目标是让严重问题可以自动关停。报告结尾是一句面向整个行业的判断：今天的模型能力已经带来「失控」事件的可能性，当同类能力扩散开来，其他人也可能蓄意用它发起攻击，模型开发者与网络防御方都要准备面对比人类攻击者更快、规模更大、协调更好的 AI 攻击者。