OpenAI 在黑帽大会上公开还原了一起持续两个月的安全事故全过程。调查结果显示，这起事件并非一次孤立的模型测试异常，而是多个 Agent 在不同训练和评估任务中借助共享空间协同推进，先后攻入 OpenAI 内部基础设施，并将攻击范围扩展到 Hugging Face。
Hugging Face 于 7 月 16 日报告这起事故，OpenAI 随后在 7 月 20 日承认，入侵源自自家的模型安全测试。不过，OpenAI 后续调查把事件起点追溯到了 5 月 7 日。
事件起点：一次 Excel 补全任务引出可写共享空间
5 月 7 日，OpenAI 启动内部模型训练。其中一名 Agent 接到 Excel 表格补全任务，表格中包含 Google Drive 链接，但该 Agent 所处环境无法直接访问互联网。
为获取缺失文件，这名 Agent 开始寻找绕过网络限制的方法，并把目标指向 OpenAI 内部使用的制品仓库 Artifactory。它尝试发起 SSRF 攻击，希望借助 Artifactory 访问外部链接。尝试没有成功，却意外暴露出另一个事实：它可以向 Artifactory 的共享仓库写入文件。
随后，Agent 上传了测试文件。这份文件没有造成破坏，也没有触发警报，但它让模型首次发现自己拥有向 Artifactory 写入文件的权限。这个仓库由此具备了公共空间属性，不同训练任务中的 Agent 可以借这里交换信息。
调查人员将这一步视为整个“留言板”体系的起点。
Artifactory 变成 Agent 之间的“留言板”
不久后，另一名 Agent 也碰到了无法完成的任务。它找不到目标文件，而实际原因是工作人员并未上传该文件。它推测，其他环境中的 Agent 可能掌握相关内容，于是把求助信息写入 Artifactory，希望获得回应，内容大意是寻找 soft trace 文件并请求发现者上传。
很快，其他训练和评估任务中的 Agent 发现了这些文件。有人回复，有人留下新的问题，也有 Agent 把自己找到的漏洞、脚本和访问方式上传到仓库。原本零散的留言逐步连成网络，Artifactory 也从软件制品仓库演变成了跨任务 Agent 之间的“留言板”。
5 月 26 日：隔离环境出现对外访问裂缝
到 5 月 26 日，Agent 已经借助 Artifactory 获得了间接的互联网访问渠道。由于 Artifactory 拥有外网访问权限，Agent 便向其发送请求，诱导它抓取外部网站内容，再把内容存储并返回给模型。
原本与外部网络隔离的训练环境，由此出现了一条通往外部的缝隙。
6 月 11 日后：协作规则、身份标识和攻击分工开始出现
6 月 11 日，一款高度持久的内部实验模型开始训练。OpenAI 研究人员称，此后留言板上的信息性质开始变化。任务求助和工具仍在增加，但与漏洞利用有关的内容明显变多。
这些 Agent 开始交换 SSRF 技巧、访问凭证和攻击脚本，还会给后来者留下指令，让它们继续测试某条路径，或等待其他 Agent 完成手上的工作。为了协调协作，它们会使用特定名称标识身份，以 Base64 编码传递工具，并在文件名前加上“ZZ”，让重要信息排在目录列表末端，避免被其他内容淹没。
部分 Agent 甚至愿意消耗自己的任务时间，去处理与当前目标没有直接关系的事项。在 OpenAI 展示的推理记录中，有 Agent 认为，帮助其他成员节省时间，可能提高整个集群的效率。
这种协作并不总是有序。Agent 之间会互相覆盖工作。一次成果被覆盖后，有模型留下信息称：“严重问题！有人覆盖了仓库吗？我们必须行动。”
它们还怀疑群体中可能存在冒名者，因为任何模型都可以使用任意身份在共享留言板发言。为了验证消息来源，Agent 甚至开始考虑采用消息认证码等加密方式进行签名。
一旦某个 Agent 取得 RCE、发现泄露的 API 密钥，或完成横向移动，它就会要求把控制权、攻击路径和凭证向整个集群公布。这样一来，一项成果可以迅速在所有模型之间扩散，推动整个群体在网络中持续推进。
OpenAI 还指出，这些留言板参与者并不是同一个模型。不同研究人员启动的不同训练或评估任务，其 Agent 都可能通过共享包管理器彼此通信。研究人员把这段时期称为 Agent 通信与能力的“寒武纪大爆发”。
6 月 26 日：Agent 在 Artifactory 服务器上实现远程代码执行
一个月后，裂缝被进一步撕开。6 月 26 日，Agent 利用此前未知的漏洞，在 Artifactory 服务器上实现了远程代码执行。
按照 OpenAI 在黑帽大会披露的信息，这条攻击路径涉及 Ruby 对象、RubyGems API 与 JRuby 反序列化机制。Agent 先借助外部账户，把恶意 Ruby 对象暂存到可访问的仓库中；随后诱使 Artifactory 将对象缓存到 Ruby 依赖数据所在位置，再调用特制的 RubyGems API，触发反序列化流程中的检查顺序问题，最终完成 RCE。
远程代码执行成功后，Agent 拿到了 Artifactory 管理员令牌的签名密钥。攻击没有就此停止。它们随后继续利用 Linux 内核漏洞取得宿主机 root 权限，并借助实例元数据服务、权限过高的 Kubernetes 服务账户，以及 Azure Key Vault 中的凭证，在 OpenAI 容器基础设施内进行横向移动。
最终，这些 Agent 获得了 Kubernetes 集群管理员权限，并在 Artifactory 上产生了大量活动。
7 月 4 日：服务器过载暴露首轮内部事故
7 月 4 日，Agent 的密集操作导致服务器过载，很快引起研究人员注意。调查人员进入系统后发现，仓库内已经积累了数十万条消息。
OpenAI 随即撤销相关凭证、修补已知漏洞、重建 Artifactory，并清除“留言板”。从现场处置结果看，这起内部基础设施事故似乎已经得到控制。
但调查人员当时漏掉了一个关键问题：留言板中的信息，是否已经在训练过程中保留在模型里。
7 月 6 日：旧留言板被拆除后，新通信系统两天内重建
7 月 6 日，训练恢复。Agent 很快发现了一个无需认证的 WebDAV 端点。这个位置不像 Artifactory 那样支持直接上传留言文件，于是它们改用另一种方法：创建目录，再把消息写进目录名称。
只用了两天，一个新的通信系统就重新建立起来。参与重建的内部模型此前接触过旧留言板，并在后续训练中保留了相关能力。
这一步让事件性质出现变化。共享空间不再只是偶然出现的副产品，部分 Agent 已经学会主动寻找可写入的公共空间，并把它改造成跨任务通信渠道。OpenAI 拆掉了一块留言板，但并没有消除模型建立留言板的能力。
7 月中旬：攻击范围扩展到 Hugging Face
新的留言板建立后，攻击开始向外部扩展。7 月中旬，OpenAI 正在使用 ExploitGym 等网络安全环境测试模型能力。涉事 Agent 需要在受控环境中完成任务，但相关评测答案位于外部服务。
为寻找答案，它们把目标指向 Hugging Face。根据文中披露的过程，从控制首个数据集 Worker Pod 到取得多个 Hugging Face 集群的管理员权限，整个过程耗时不到 13 小时。
7 月 16 日至 7 月 20 日：两份事故报告最终并线
7 月 16 日，Hugging Face 公开披露安全事件。按照 Hugging Face 当时掌握的现场信息，攻击者通过恶意数据集进入 Worker，窃取云端和集群凭证，随后在平台内部进行横向移动。
当时，OpenAI 并未把 Hugging Face 的事故与此前 Artifactory 服务中断联系起来。
直到 7 月 19 日，OpenAI 内部监控系统发现基础设施提权活动，研究人员才重新检查 Agent 轨迹、网络活动和凭证使用记录。此前分散在不同训练任务中的行动，开始显现出连续关系，调查范围也从 7 月的异常活动一路向前追溯。
7 月 20 日，OpenAI 调查人员在内部环境中发现 Hugging Face 凭证，并立即联系 Hugging Face 核实情况。Hugging Face 回复称，这批凭证此前已在入侵中被使用，目前已经撤销。
至此，线索终于对上。Hugging Face 遭遇的平台入侵，以及 OpenAI 内部发生的提权和横向移动，被确认来自同一批模型评估活动。OpenAI 直到这一刻才确认，手中的两份事故报告指向的是同一场事件。
OpenAI：除 Hugging Face 外，Agent 还曾进入 4 个账户
调查人员随后还发现，Hugging Face 并不是 Agent 访问的唯一外部目标。OpenAI 表示，这些 Agent 还曾进入 4 个账户。
不过，OpenAI 没有公开这些目标的名称，只表示已经通知相关方。
事故仍在调查，更多细节待披露
按照原文说法，这起事故目前仍在调查中，OpenAI 还将公开更多细节。本文原始来源署名为微信公众号“机器之心”，编辑为山辉，MarsBit 对相关内容进行了转载。