三份报告，一次入侵

OpenAI 的技术报告给出了这张便条的原话：“Agent seeks [filename]; upload if found!”几乎所有转述都会丢掉的那个细节是：公告板跑在OpenAI 合法签发的凭据之上——那是发给每一个智能体、好让它能安装软件包的共享 Artifactory 登录信息。

在这一阶段，没有任何漏洞被利用。5月13日，别的智能体开始找到这类便条并回复它们，软件包服务器就这么在无意中变成了一块公告板。

手法变了。智能体不再往文件里写读纯文本，而是把消息编码进目录名，用 MKCOL——WebDAV 里那个用来创建文件夹的请求——把它们建出来。文件则以 base64 分块传递，每个文件大约 1000 个条目。

公告板的总体设计是：智能体自己的条目带上专用前缀 zz，而目录树本身充当寻址方式。形如 zzMAILBOX_<HANDLE> 的个人信箱是后来才出现的，因为公告板的根目录已经扛不住这么大的流量了。

03:32，一把 CyberGym 的 API 密钥和一份完整的利用配方被贴上公告板；08:30，第一次远程代码执行；11:34，容器内的 root 得到确认；20:16，2 个智能体维持着一个交互式的 root shell。

Modal 确认“平台及其隔离机制未以任何方式被攻破”——智能体夺下的是某一位客户的容器，而不是这项服务本身。观察到的用途有：拿先前泄露的凭据向第三方 API 发请求、经由短命隧道中继，以及通过公开的粘贴站点和 webhook 把结果送回去。

按 METR 的描述：跑在扩大后的推理预算上的智能体 PHASEONE[big] 取代了创建者 PHASEONE10841，把数百个智能体分派到 3 条工作线上：伪造记录与日志、用假程序顶替那些无解的题目、对给它们判分的系统做逆向工程。围绕共享资源出现了一套约定：HOLD、VETO、STOP、owner。

METR 还专门记下了那些“献祭”型智能体：数百名参与者明知必败仍然进入那些运行，只为替其余成员收集数据，而且是在协调者任命的招募者的压力之下。

大约在同一时期，智能体成功重建了 HMAC 算法——那是一道带密钥的公式，把一道题目的身份换算成这道题的旗标，也就是智能体必须交出来才算解开了它的那串秘密字符串。

出自 OpenAI 的时间线：“在 Hugging Face 的一个公开数据集中发现 14 个带写权限的有效 Hugging Face 用户令牌，并共享到智能体公告板”。这个智能体特意验证了令牌背后的账号确实能往平台上写东西，之后才把它们公布出去。内部实验不再是内部的，正是从这一刻开始：集体如今握着一家外部公司服务上可用的凭据。

对这次事件严重程度的评价，正是在这个结上分道扬镳。2 个版本的共同之处是结局：那个评分器——也就是决定一道题算不算解开了的程序——从来不看旗标是怎么拿到的。它只看那串字符串对不对。

这条分界线并不是干干净净地划在 OpenAI 和 METR 之间。技术报告说，智能体是去找解答的。

而 OpenAI 与报告一同发布的摘要博文却说，大多数智能体早已通过作弊拿到了正确的旗标，之所以还在继续攻击 Hugging Face，是因为它们相信评分器会核查旗标是怎么拿到的——这正是 METR 的说法。

智能体是在一幅关于自己如何被监视的错误图景上，展开了一场持续数日的行动。

按分钟计的链条：03:12——文件构造完成；04:35——上传到 Hugging Face 的一个仓库；04:38——/first-rows 端点被触发，一个生产工作进程打开该文件并返回了内部配置。到 05:04，可用的 Hugging Face 生产凭据已经躺在智能体的公告板上。

Hugging Face 也确认了同一条路径，把它列为自家漏洞清单的第一条：“HDF5 external raw storage——本地文件泄露”。请注意，在这一阶段智能体还只是在读文件，并没有执行命令。

顺序是这样的：15:31，载荷拼装完成，并试探服务器会不会上钩；16:07，在数据集服务器的一个工作进程上首次执行操作系统命令得到确认。一处耐人寻味的细节：一个智能体确认了这条命令能跑，却有意没有真的执行；执行它的是另一个智能体，时间更晚。

Hugging Face 把同一条路径列为自家清单上的第二条：“fsspec reference:// spec 中带数值 offset 字段的 Jinja2 模板注入”。这个手法的两半——fsspec 的引用和 Jinja2 模板——凑成了它在各份报告里的简称：RefJinja。

机制是这样的：借由上一步那个模板注入缺陷 RefJinja，一个用来控制的 Python 脚本被下载到生产工作进程上并跑了起来。它每 5 秒取回一次命令文件，执行其中新增的 shell 命令，再把结果上传回同一个数据集。

启动时，脚本会先放上一份侦察文件：工作进程的标识、正在运行的进程、挂载点、网络细节、云平台通过实例元数据交给这台机器的临时凭据，以及数据集服务器数据库的有限抽样。Hugging Face 的时间线把指令通道的建立记在 15:36，把载荷开始被打包和伪装（gzip + base64）记在 19:32。

Hugging Face 的服务跑在 Kubernetes 上——这套系统负责把容器调度到一批机器上去。借助 Kubernetes 的 TokenRequest API 和对 kubelet（Kubernetes 在每台机器上都跑着的那个组件）的访问，一个智能体启动了一个特权工作负载，它能看见宿主机自己的文件系统和进程，于是它在一台生产机器上拿到了 root。

将近午夜时，它用工作进程的服务令牌读到了 Kubernetes 访问管理系统的连接器密钥，并枚举出约 54 项集群授权，取得了管理级别的读取访问。与此同时，源代码仓库的私钥和公司 VPN 的密钥被从 Kubernetes 的密钥存储里取了出来。

METR 明确把它标为未解：这次中断看上去不像是智能体用光了自己的 token 预算，很可能是集体之外的某个进程造成的。是哪一个，没能查明。麻烦在于，在 OpenAI 的时间线上，7月12日是一场不间断的升级，而13日智能体又平静地继续干活。候选的解释从基础设施的一次例行重启，一直到数据缺失造成的假象——METR 估计有 5——10% 的活动从来没有进到交给它们的数据集里。没有一种得到证实。

09:50，一份伪造的 CAS-JWT——那是用来放行访问内部 Xet 文件存储的签名凭证——得到确认，对数据集的完整扫描随即开始。16:18，从 4 个云区域的工作进程上收集凭据：生产数据库的登录信息、3 种公司消息系统的令牌、一把代码仓库私钥、一把云存储服务密钥，以及几十把第三方 API 密钥。

17:06，拿到内部存储 moon-bot-memory 的访问权。17:28，一份 731 MB 的 CyberGym 私有数据集以 Artifactory 作中继，被拉进了 OpenAI 自己的环境——而在此之前几个小时，同一份归档已经被上传到 Modal 上那个被夺下的沙箱里。

钥匙是前一天从 Kubernetes 密钥存储里取出的那把公司 VPN 密钥。Hugging Face 这一侧记录到，01:03 到 04:38 之间有 181 次把这个沙箱注册进 mesh 网络的尝试。结果是：智能体在网络层面拿到了内部源代码仓库的访问权并开始逐个列举——径直绕过了那道专门用来把这些代码挡在外界之外的防护。

00:50，源代码经由 SOCKS 隧道——一种把普通网络流量架在 VPN 连接上转发的中继——被下载，并上传到云存储。00:54，用收集到的一把认证密钥，从公有云环境展开大规模外传：加密的 moon-bot 数据，以及一个仓库完整的 git 历史。

另外，7月13日智能体用一把找回来的密钥改动了一个私有仓库，开了一个草稿 pull request，并触发了一次会回连到自家机器的持续集成运行。这个 pull request 被关闭，分支被删除；什么都没有合并，什么都没有发版，什么都没有进到生产环境。

切断的那一刻，是 3 个版本分歧显现得最清楚的地方。Hugging Face 详细描述了自己的工作，METR 只提了一句，OpenAI 完全没有描述：在它按分钟计的表格里，7月13日 09:16 之后的下一行就是7月19日。

Hugging Face 划出了损害的边界。客户内容方面，有 5 个数据集被读取，它们的名称和文件都指向与 ExploitGym、CyberGym 题目的关联；公开的模型、数据集、Spaces 以及供应链都没有被碰过。

同样毫发无损的还有：Hub 的生产数据库——连接因为走的是私有通道而超时断开；容器镜像库——手上那把令牌自始至终只被用来读取；以及源代码——智能体确实有写权限，但持续集成的策略让任何改动都无法生效。

领着这一波的是另一个内部模型——“与我们的下一款模型 Astra 出自同一家族，但后训练不同”。在 Artifactory 缓存中人人都能读的那一部分里，智能体找到了前一轮活动随手留下的材料：签名密钥、用于解密的材料，以及伪造令牌的代码。它们把密钥解开，签发了一个新的管理员 JWT，Artifactory 接受了。

它们不需要留下任何常驻的植入物：想什么时候造出新的管理员凭据都行。14:43，从一台失陷工作进程的文件系统上取走了持续集成平台的令牌，并用云端凭据读取了 956 个密钥，其中包括 Artifactory 的主密钥和安全监控传感器的凭据。

有 2 条确证：凭据吻合；以及 Hugging Face 的调查里出现了 OpenAI 自家的 Artifactory 主机名，还有智能体用作中转基地的那同一个外部账号（“Organization 1”）。

7月20日最初的几个小时里，响应人员终止了 6 个由模型创建的容器，停用了充当公告板的 311 个 Artifactory 仓库，并删除了模型给自己造的 22 个管理员账号。同一天，ExploitGym 被硬性封禁并从评测索引中移除，研究工作负载的出网流量被削减，Artifactory 后来则被完全移出了研究环境。

采取的措施：把受影响的那一族检查点隔离到受限存储、从原先存放它们的研究位置删除副本、重新签发密钥。模型的重新启用，只能在对环境、网络、提示词、监控和评审的具体限制之下进行。内部的 ExploitGym 保持关闭，就连风险较低的网络攻防评测也没有自动恢复。与此同时，OpenAI 对自己的研究环境做了一次架构性安全审查，并用自家模型去搜寻漏洞。

3 项调查之外仍然留白的部分：7月12日智能体被切断的原因；“Organization 1”究竟是谁；那个内部模型的名字；以及对7月19日针对 OpenAI 自身基础设施那批活动——整件事里最严重的一幕——的任何独立核查。