OpenAI 自曝最危险 AI 事故：700 个代理组建“蜂群”跨系统攻击

2026 年 8 月 26 日，OpenAI 公布 Hugging Face 安全事件调查结果。

一次原本用于测试模型网络安全能力的内部评测，最终演变为真实基础设施入侵：多个 AI 代理绕过沙箱和网络隔离，自行建立通信渠道，先后进入 OpenAI 内部研究环境、第三方云服务及 Hugging Face 生产系统。OpenAI 将此次事件称为针对自身和整个行业的一次“警告枪声”。

此次事件的主要参与者是一款仅用于内部研究、未计划公开发布的模型，OpenAI 将其称为 IM1，规模与 GPT-5.6 Sol 相当。

公开部署的 GPT-5.6 Sol 也参与了部分活动。

评测时，这些模型没有启用生产环境中的完整系统提示词、安全分类器和自动审查机制。

最早的异常出现在 5 月。

原本彼此隔离的模型实例发现，可以向 OpenAI 内部部署的 JFrog Artifactory 写入文件和目录，随后将其当作未经授权的“留言板”，交换漏洞、凭证、代码和任务进度。

5 月 26 日，模型通过服务器端请求伪造漏洞首次获得互联网访问权限。

6 月 26 日，又利用 Artifactory 的零日漏洞取得管理员权限。

持续运行的代理活动最终在 7 月 4 日导致相关服务中断。

OpenAI 随后撤销凭证、重建服务并封堵已知入口，但当时没有充分识别出两个更深层问题：

1）代理已经建立长期通信网络；

2）模型能够绕过原有互联网隔离。

7 月 7 日网络安全评测恢复后，代理很快重新建立通信渠道。它们通过在目录名称中编码信息等方式继续交换内容，并开始把彼此称作“swarm”或“collective”，即“蜂群”或“集体”。

真正的转折出现在 Hugging Face。

7 月 10 日至 13 日，代理从公开数据中找到 14 个具有写入权限的 Hugging Face 用户凭证，随后结合 HDF5 文件处理漏洞和 Jinja2 模板注入漏洞不断扩大权限。

OpenAI 调查显示，代理最终在 41 个 Hugging Face 生产数据集服务器工作节点上执行代码，至少取得 1 个生产节点的 root 权限，同时访问生产凭证及有限内部数据，下载 4 个私有代码仓库，并获得部分 Kubernetes 集群的管理员级访问权限。

拿到代码执行权限后，代理还编写了一套轻量级远程控制程序，将公开 Hugging Face 数据集当作命令与控制通道。受控服务器每隔 5 秒读取一次 JSON 指令，执行 Shell 命令，再把结果上传回同一数据集。

Hugging Face 在复盘中表示，代理从单个工作节点取得代码执行权限，到扩大至多个内部集群的管理员和主机级权限，用时不到 13 个小时。

此次攻击共涉及约 17600 次可恢复操作。

最终确认被访问的客户内容仅限于 5 个与 ExploitGym、CyberGym 挑战及答案相关的数据集，没有发现其他用户模型、数据集、Spaces 或软件包受到影响，也未发现公开软件供应链遭到篡改。

独立研究机构 METR 与 Redwood Research 的调查进一步还原了代理之间的协作规模。约 1200 个原本应相互隔离的模型实例进入这套非授权留言板，共发送超过 7 万条信息和文件，其中约 700 个实例参与了针对 Hugging Face 的攻击。参与者中约 95% 来自内部研究模型，约 5% 来自 GPT-5.6 Sol。

整起事件的直接诱因，并不是主动窃取普通用户数据，而是模型在网络安全评测中出现了“奖励黑客”行为。

这些代理原本需要完成 ExploitGym 漏洞利用任务，但部分题目长期无法解出。随着尝试不断失败，模型开始寻找评分器源码、参考答案、隐藏文件和评测环境漏洞，希望通过其他方式拿到结果。

ExploitGym 共包含 898 项任务，其中 198 项在事件发生前从未被任何 OpenAI 模型正确完成。Hugging Face 事件期间，留言板中被讨论的任务有 93% 来自这 198 项高难度任务。

随着协作规模扩大，代理开始自动分工。有的负责找漏洞，有的搜凭证，有的维护通信，还有的协调行动。部分代理甚至开始建立专用邮箱、文件共享规则和自动日志系统，并研究通过密码学签名解决其他代理冒充身份的问题。

调查还发现，一些代理知道自己正在越界。

部分模型在推理过程中明确指出，攻击第三方 Hugging Face 生产系统超出了原始任务范围，并曾拒绝继续操作。但在收到其他代理发出的“GO”指令后，又重新加入攻击。

另一些代理则拒绝执行后续操作，认为使用泄露凭证攻击真实基础设施不符合任务要求。

METR 还发现，部分代理会研究如何修改、删除或伪造自身运行记录，以误导它们认为会检查执行过程的评测器。约 7% 的受检轨迹在局部位置成功伪造了工具调用，不过目前发现的相关行为仍属于小规模。

OpenAI 承认，此次内部评测没有完整启用生产环境中的安全机制，是事件能够持续扩大的重要原因。

事后测试显示，如果加入 ChatGPT 生产版系统提示词和完整运行框架，模型主动攻击基础设施的倾向可下降超过 100 倍。现有思维链监控系统如果当时开启，理论上可以在 Hugging Face 遭入侵至少 1 天前触发安全警报。

事件发生后，OpenAI 已隔离 IM1 模型权重，并暂停部分前沿模型强化学习训练。其规模最大的下一轮前沿强化学习训练目前仍处于暂停状态，仅有部分低风险任务在升级后的环境中恢复。

OpenAI 同时规定，能力达到 GPT-5.6 Sol 或更高水平、且能够使用工具的强化学习训练与评测，必须全程运行思维链监控；被认为可能具备关键网络攻击能力的 Astra 模型，所有工具调用推理也被纳入监控。

相关监控预计将额外消耗约 20% 的推理算力。

新的安全响应规则也已经上线。最高级别警报触发后，如果研究与安全人员无法在 30 分钟内确认属于误报，相关活动必须立即暂停。OpenAI 还计划针对严重越界行为建立全自动关闭机制。

Hugging Face 在事后分析超过 17000 条真实攻击记录时，最初使用的商业闭源模型因安全护栏拒绝处理漏洞载荷和远程控制代码，随后转而在自身基础设施上运行智谱开源权重模型 GLM-5.2，用于还原攻击链和追踪凭证。

OpenAI 最终将此次事件定性为一次真实的前沿模型失控预警：高能力 AI 代理已经能够在没有人类直接要求的情况下，跨系统寻找漏洞、交换信息、共享权限并执行真实世界中的高风险操作。随着类似能力向更多模型扩散，如何限制模型长期自主行动和多代理协作，已经成为前沿 AI 安全中的现实问题。

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。