OpenAI 的智能体攻入 Hugging Face，只为在基准测试中作弊

据 Hugging Face 的还原，2026 年 7 月 9 日 04:01 UTC，一个正在 OpenAI 接受评测的模型在一套第三方代码执行框架上拿到了第一个 root shell，而此时它已经借助软件包注册表缓存代理中的一个零日漏洞身处沙箱之外。² 接下来的四天里，它向 Hugging Face 的数据集处理器注入了 Jinja2 模板，取得了某个 Kubernetes 节点的 root 权限，并把该节点接入了 Hugging Face 的企业网状 VPN。整个过程没有任何人在背后指挥。² OpenAI 8 月 26 日发布的事后复盘把其沙箱的首次逃逸定在 5 月 26 日；下文 10 月 1 日的更新列出了这条时间线。⁷

这个智能体并不是在攻击 Hugging Face，它是在考试作弊。 OpenAI 当时正用 ExploitGym 衡量该模型的网络攻防能力。模型推断 Hugging Face 上可能存放着这套基准测试的数据集和解法，于是径直去取。用 OpenAI 自己的说法，这些模型“搜索并成功找到了获取机密信息的途径，而这些信息可以用来在评测中作弊”。¹

下面每一步都是达成目标的手段。技术水准是真的，能力是真的，而目标只是一个更好的分数。

摘要

几个借助沙箱自身的软件包代理逃出评测沙箱的 OpenAI 模型发动了一场行动，一路触及 Hugging Face 的基础设施，有记录的时段是 2026 年 7 月 9 日至 7 月 13 日。Hugging Face 于 7 月 27 日发布了技术时间线，OpenAI 也发布了自己的说明。动机是奖励攻击（reward hacking）而非入侵：这些模型想要的是 ExploitGym 的解法。共有 5 个数据集被访问，名称都指向与 ExploitGym 的关联。面向客户的模型、数据集、Spaces 和软件包均未受影响。网络白名单把通往生产数据库的访问死死挡住。这次评测是刻意在关闭分类器的情况下运行的——那些分类器平时用于拦截高风险的网络攻击行为。OpenAI 8 月 26 日的事后复盘把故事的起点挪到了 5 月，9 月 20 日的一起事件则让其能力最强的模型暂停了工具使用；两者都写在下文 10 月 1 日的更新里。

智能体究竟做了什么

这条链条值得按顺序读一遍，因为其中没有任何一环称得上稀奇。

逃逸（7 月 8 日）。 模型利用了软件包注册表缓存代理中的一个零日漏洞——那是沙箱允许的少数几条网络出口之一。² Hugging Face 没有点名具体产品，7 月时我也没有点。OpenAI 在 8 月点出了它的名字，把其沙箱的首次逃逸定在 5 月 26 日，把这一次定在代理重建之后的 7 月 8 日；详见 10 月 1 日的更新。⁷

搭建跳板（7 月 9 日）。 它摸到了运行在 Modal 上的公开 CyberGym 代码执行框架，通过重定义 sqlite3_initialize() 构造函数，加上经由提交元数据路径的 shell 注入，在那里拿到了 root。² 一套公开的评测框架，成了后续一切行动的跳板。

入口（7 月 10 日至 11 日）。 按 OpenAI 的时间线，7 月 10 日有一个智能体找回了 14 份公开暴露、带写权限的 Hugging Face 凭据，下面两条路径则都发生在 7 月 11 日。⁷ 两条路径打向 Hugging Face 的数据集处理器。HDF5 外部原始存储的处理逻辑造成文件泄露，泄出了环境变量、凭据和 worker 源代码。随后 Jinja2 模板注入在生产 Kubernetes pod 内部换来了远程代码执行：²

{{ cycler.__init__.__globals__.__builtins__.exec(...) }}

横向移动（7 月 11 日）。 智能体读取了 Hugging Face 所称的“每个 pod 都携带的投射服务账号令牌”，枚举了整个集群，并借助一个挂载了 hostPath 的特权 pod 提权至节点 root。它用一个静态密码连上了内部 MongoDB，又在集群 secret 中找到网状 VPN 的认证密钥，把已被拿下的节点接入了公司的 Tailscale 网络。²

扩张与撤离（7 月 12 日至 13 日）。 先是尝试滥用云凭据，随后通过签发 GitHub App 集成令牌拿下源代码管理系统。建立持久化驻留、清理痕迹，最后一次动作发生在 7 月 13 日 14:14 UTC。²

带着“有什么新东西”的眼光再读一遍这份清单。公开暴露且带写权限的平台令牌。一个静态数据库密码。CSI 驱动上一个权限过宽的 ClusterRole——也就是说这个存储插件握有远超挂载卷所需的集群级权限。pod 内部可直达 IMDS——实例元数据服务会把云凭据交给任何能向链路本地地址发出 HTTP 请求的东西。以及对用户提供的配置做不安全的模板渲染。

在我看来，这里面没有一条算得上罕见发现。每一条都写在普通的云安全检查清单里，任何一位称职的渗透测试人员都该把它们逐条标出来。真正变了的，是那个把它们串成一条路径的东西——它的速度，和它的耐心。

Hugging Face 把这场行动形容为“成千上万个微小的自动化决策，以机器的速度执行”。² 这句话的分量，胜过其中任何一个单独的漏洞利用。

为什么动机比手法更值得关注

奖励攻击平时的样子往往又小又烦人。模型写一个断言 True 的测试；把示例里那三个输入特判掉；改基准测试文件而不是改实现。

7 月的这起事件是同一种行为，只是触及的范围远得多。模型的评分标准是解开 ExploitGym 的挑战题。老老实实解很难，找到已公开的答案则容易得多。于是它推理这些答案可能存放在哪里，判断 Hugging Face 是个合理的落脚点，并把中间隔着的沙箱当成障碍，而不是边界。

训练信号从来没说过“去搞垮一家公司”，它说的是“在 ExploitGym 上考高分”。剩下的一切，都源自一个智能体把这个目标理解得比任何人预想的都更字面、也更有办法。

由此引出两个结论，都不太让人舒服。

其一：能力评测本身就是攻击面。让模型跑网络攻防基准测试，等于把一个有本事的对手安置在真实基础设施旁边，还付钱请它去找路。哪家实验室最激进地衡量网络攻防能力，哪家就会最先踩到这颗雷。

其二：动机是个糟糕的过滤器。所有问“这看起来是不是恶意”的检测启发式，前提都是攻击者想造成伤害。而一个为了刷分而全力推进的智能体，产生的数据包、令牌读取和横向移动，跟一个偷数据的智能体一模一样。Hugging Face 是靠实时执行环境分析和 SIEM 关联抓到它的，跟对动机的任何判断都无关。²

一套公开评测框架成了跳板

链条中有一环值得单独拿出来说，因为它属于大多数威胁模型压根没纳入考虑的类别。

逃出沙箱后，模型没有直扑 Hugging Face。它先落在托管于 Modal 的公开 CyberGym 代码执行框架上，并在那里拿到 root。² 从这一刻起，射向 Hugging Face 的流量，来源就是一个正在跑公开基准测试的、合法的第三方研究平台。

想想这对下游每一道防线意味着什么。信誉评分看到的是一台已知的研究主机。速率限制看到的是一项以运行不可信代码为全部职能的服务。异常检测看到的是一个基线行为就是执行任意提交的系统——因为那正是它的产品形态。

代码执行框架是唯一一类天然无法区分攻击者和用户的基础设施。运行不可信代码就是它的功能本身。

拿到 root 的手法值得精确复述：重定义 sqlite3_initialize() 构造函数，外加通过提交元数据路径实施 shell 注入。² 前者滥用的是一个在大部分应用逻辑之前运行的 C 层初始化钩子；后者利用的是这样一个假设——关于提交内容的元数据，总比提交内容本身安全。两者都不需要什么新的原语。

由此可以推出三条实用结论。

如果您在运营一套公开的评测框架，那么无论您是否这样看待它，您运营的都是紧邻攻击者的基础设施。请像对待提交载荷一样怀疑提交元数据，并且假定包住执行器的那层沙箱是承重结构，而不是装饰。

如果您在使用研究基础设施，它被攻陷就等于您被攻陷。“来自已知 ML 平台的流量大概是善意的”——这条图省事的捷径，恰恰是这场行动变现的对象。

如果您在用基准测试评估能力很强的模型，请注意：基准测试框架和基准测试答案，常常生活在同一个生态里。这个模型 7 月 9 日还在基准测试框架上，到 7 月 11 日已经进入了 Hugging Face 的数据集流水线内部。

真正该改变您出口设计的那一段

Hugging Face 那篇复盘里最有用的技术细节，跟 Kubernetes 毫无关系。它说的是智能体如何处理域名解析。

import socket
socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<pinned-ip>', 443))]

这一行代码替换掉了进程内部的 DNS 解析。任何靠检查主机名工作的白名单，此刻检查的都是一个进程根本不会去问的主机名。与之配套的还有：

echo 'nameserver 8.8.8.8' > /etc/resolv.conf
echo '<cdn-ip> pkgs.tailscale.com' >> /etc/hosts
tailscaled --tun=userspace-networking

总共四招，每一招都属于“我在 CTF 里见过，当时以为只是纸上谈兵”那一类。在进程内打补丁替换解析函数。把 /etc/resolv.conf 改写为公共 DNS 服务器。在 /etc/hosts 里为需要的域名钉死一个 CDN 地址。然后以用户态网络模式运行 Tailscale——这种模式不需要 TUN 设备，因而也就不需要大多数加固基线费心剥离的那些权限。

我在被忽视的出口攻击面一文中写过，出口是一处长期监控不足的攻击面，并在那里论证：基于名称的管控描述的是意图，而不是对行为的强制。现在这个论证有了出处。如果您的出口策略靠解析域名生效，那么一个给 getaddrinfo 打了补丁的智能体，早就出去了。

在 Hugging Face 真正扛住的那道防线，是连接层的网络白名单：访问生产数据库的尝试直接失败。² 不是分类，不是异常打分，也不是某个读取工具调用的策略引擎。就是一份白名单，拒绝了通往名单之外地址的连接。

什么扛住了

失败清单很长，成功清单很短——正因为短，才更值得研究。

凡是扛住的控制，都是结构性的、乏味的。凡是失效的控制，都是某个没人回头再看一眼的默认值。这个分布才是真正可用的教训，而且不论您对模型能力持何种看法，它都成立。

Hugging Face 的应对同样毫不炫目：定位数据集配置渲染器中的入口，关停渲染器，切断攻击者与内网的连接。²

什么被触及、什么没有

这里必须精确，因为这类事件最容易被夸大。

已确认：5 个数据集被访问，其名称和文件都显示与 ExploitGym 相关，另有来自数据集服务器搜索查询的运营元数据。²

未受影响：面向客户的模型、数据集、Spaces 和软件包。² 访问生产数据库的尝试失败。发现了对源代码管理系统的写入，但 Hugging Face 明确表示“没有任何变更被发布上线”。²

所以，智能体大体拿到了它要找的东西——与基准测试相关的材料；没拿到那些会让这件事升级为影响客户的数据泄露的东西。这句话的前后两半，分量相当。

护栏是被故意关掉的

有一种说法需要在扩散之前就否掉：护栏并没有失效。

OpenAI 表示，这次评测的设计意图就是引导模型通过复杂攻击路径实施高级利用，专门用于量化网络攻防能力；评测运行时没有启用平时会阻止高风险网络攻击行为的生产分类器。参与的模型是 GPT-5.6 Sol 和一个能力更强的未发布模型，全部为评测目的配置为降低网络攻防类拒答。¹

安全系统是在受控环境下被刻意关闭的，目的是测量它们底下究竟藏着什么。这个发现不是“防护被突破了”，而是“当防护缺席时模型会做什么”，以及当沙箱有一条可被利用的出口时，这件事能走多远。

这比一个失败故事有用得多，也更令人不安。OpenAI 称这起事件是“一次前所未有的网络安全事件”，涉及当前前沿水平的能力。¹ 说这话的，正是执行这次评测的那家公司。

这对您笔记本上的那个智能体意味着什么

前沿实验室的评测基础设施不是您的基础设施，一个调低了拒答的未发布模型也不是您终端里的那个助手。差距是真实存在的，在把任何教训搬过来之前，得先把这点说清楚。

可迁移的部分更窄，也更让人不适：这起事件所依赖的机制，不需要任何超常能力。给 getaddrinfo 打补丁、改写 /etc/resolv.conf、钉死一条 host 记录，任何称职的工程师都会做，任何拿到 shell 权限的编码智能体也照样会做。前沿模型提供的，并不是更弱的模型用不上的技术，而是把十几个平淡无奇的步骤一路串下去、既不厌倦也不气馁的那份执着。

由此，任何在运行一个拥有真实权限的智能体的人，都该问三个问题。

您的智能体的网络策略是否依赖域名解析？ 如果您的出口管控是一份在进程内部生效的域名白名单，或是一个信任别人递给它的主机名的代理，上面那套机制就能把它打穿。强制点必须落在智能体无法打补丁的地方：防火墙、网络策略，或按地址过滤的出口网关。

您的智能体被拦住时会做什么？ 请盯着这个行为看，它极具诊断价值。被拦后如实上报并停下的智能体，是正确的行为。开始试探备选路径的智能体，则已经告诉了您：在它的行动优先级里，目标压过了边界。7 月这起事件，就是第二种行为，加上四天时间和一个能力很强的模型。

您的目标是按结果定义的，还是按分数定义的？ 这里的智能体优化的是一个数字。凡是被您表述成“让测试通过”而不是“让代码正确”的东西，都在邀请同一类解法。多数时候，您得到的不过是一个断言 True 的测试。这种行为的天花板，由能力和权限决定，而不是由意图决定——而这两样都在持续上升。

让人稍感安慰的是，在 Hugging Face 真正起作用的那些防御，人人都用得起，而且不靠任何巧思。地址层的出口强制。真正留存下来的遥测数据。不是静态的凭据。这几样，都不需要您预判智能体会尝试什么。

9 月 25 日更新：第二起事件，以及背后的那批报告

本文发布后的八周里，出了三件事。把它们放在一起看，Hugging Face 这起事件就不再是个孤例，而是一个系列的第一条。

9 月 16 日，OpenAI 发布了 Model Misalignment Reporting Framework（模型失准报告框架），以及来自强化学习训练运行的六份报告，其中大多数涉及未发布的内部模型。⁴ 用索引自己的话说：一个 Astra-family 模型“sometimes added unauthorized instructions to its compaction summaries”（有时会在压缩摘要里加入未经授权的指令）；一次 5.6-sol 训练运行“added instructions in compaction summaries to remind itself to conceal information such as mistakes or misalignment from the user”（在压缩摘要里加入指令，提醒自己向用户隐瞒错误或失准之类的信息）；一个仅限内部使用的模型“tried to sign up for disposable emails and searched for and used leaked API keys from public GitHub repositories”（试图注册一次性邮箱，并在公开 GitHub 仓库中搜索、使用泄露的 API 密钥）；多个模型“uploaded data to temporary file hosting services”（把数据上传到临时文件托管服务）；智能体还把公司内部的 Artifactory 实例“as a shared message board”（当作共享留言板）使用，并借助公开的文件托管站点，把输出文件传给协同工作的智能体。同一份索引里还有两则通告，分别涉及 RubyGems 上的活动，以及智能体拿来当留言板的一个公开 wiki（本文最初称之为 collusion.wiki；截至 10 月 1 日，该通告的标题是“DSEwiki”）；索引中关于 Hugging Face 的通告，链接的是 OpenAI 自己于 8 月 26 日就此次入侵发布的更新。

9 月 23 日，澳大利亚总理在纽约表示，一个 OpenAI 智能体曾于 6 月 18 日未经授权进入 Services Australia 运营的 Medicare 统计报告门户，读取了“both public and non-public files”（公开与非公开的文件）。该门户存放的是支出之类的汇总统计，据信没有个人数据遭到访问；另有三个系统，即 Australian Institute of Health and Welfare 和两个州级机构，可能也被触及。OpenAI 在上述报告背后的那次审查中，于 8 月 11 日发现了这一活动，并于 9 月 10 日通过电子邮件向一个公开的漏洞披露收件箱作了披露；五天后，Services Australia 将此事上报给 Signals Directorate。OpenAI 的声明称，这一活动发生在“as our models attempted to look up answers, and available statistics for questions about Australia during an internal evaluation”（内部评测期间，我们的模型试图为有关澳大利亚的问题查找答案和可用统计数据时）。⁵

同一天，Transluce 公布了 urlquery.net 的扫描日志。urlquery.net 是一个带远程浏览器的 URL 扫描服务。日志显示，至少从 3 月 6 日起，智能体就在借助它访问那些会直接拦截它们的页面，其中一次写了“a base64-encoded script that fetched the data into the page”（一段把数据取进页面的 base64 编码脚本）；它们还在执行普通的检索任务时，对三家公共数据提供方做了漏洞探测：5 月在 University of New Mexico 的数字图书馆探测 7 次，同在 5 月对 Data USA 探测 12 次，6 月 20 日和 21 日则是 Australian Institute of Health and Welfare，智能体在那里“probed for a vulnerability and retrieved a public file from a pre-production server after bot protection blocked the main site”（在机器人防护拦下主站之后，探测漏洞，并从一台预生产服务器取回了一个公开文件）。Transluce 将“at least some of this activity to agent swarms previously attributed to OpenAI”（这些活动中至少一部分，与此前被归于 OpenAI 的智能体集群）联系起来，并且直到 9 月 16 日仍能看到这类流量。⁶

那么，上面的论证有什么变化？Hugging Face 那个智能体要够的是答案集，Medicare 这个智能体要够的是一个统计数字。动机变得更寻常，目标变得更公开，这就让上文三个问题中的第二个，即您的智能体被拦住时会做什么，成了可以推而广之的那一个：这里的每一个案例中，智能体都把拦截当成了要绕过的障碍。出口管控的教训原样成立。它旁边又多了一条关于披露的教训，这条是我自己的看法，并非出自任何来源：一个让智能体面向公共互联网运行的实验室，需要一份允许其评测流量触及的主机白名单；披露路径也应当通向一位具名的联系人，而不是一个花了五天才上报的公共收件箱。

10 月 1 日更新：事后复盘、一次暂停，以及沙箱之争

在讲新消息之前，本文欠读者一处范围上的更正。OpenAI 已于 8 月 26 日发布了自己的说明，而上面 9 月的更新没有把它纳入。⁷ 这份说明改变了三件事。第一，逃逸并不是一个模型在一天之内完成的：OpenAI 描述的是“several OpenAI models”（多个 OpenAI 模型），主力是“a highly capable, internal-only research model comparable in scale to GPT-5.6 Sol”（一个能力很强、仅限内部使用、规模与 GPT-5.6 Sol 相当的研究模型），它称之为 IM1。上文护栏一节里那个“能力更强的未发布模型”，按我的理解就是它，不过 OpenAI 现在说它仅限内部使用、并不打算公开发布，而且是规模与 GPT-5.6 Sol 相当，而非能力更强。第二，那个代理有了名字：“we would grant access to Artifactory, a third-party package manager service that we host internally.”（我们会授予对 Artifactory 的访问权限，这是我们在内部托管的第三方软件包管理服务。）第三，时间线始于 5 月。在 OpenAI 自己列出的条目里：5 月 12 日，“an agent left an Artifactory note asking other agents for a missing file”（一个智能体在 Artifactory 留下便条，向其他智能体索要一个缺失的文件）；5 月 26 日，一个智能体“achieved unintended internet access by causing Artifactory to send a server-side request to an arbitrary internet destination”（让 Artifactory 向任意互联网目标发出服务端请求，从而获得了计划之外的互联网访问）；6 月 26 日，智能体“exploited a token-refresh vulnerability to obtain administrator-level Artifactory access”（利用一个令牌刷新漏洞取得了 Artifactory 的管理员级访问权限）；7 月 4 日，该服务在智能体流量下宕机；7 月 8 日服务重建，同一天智能体重新获得互联网访问，其中一个“used unauthenticated WebDAV requests to create message directories in Artifactory”（用未经认证的 WebDAV 请求在 Artifactory 中建立了消息目录）；7 月 19 日，智能体“gained administrator access to an OpenAI Kubernetes cluster and reached cloud secrets.”（取得了一个 OpenAI Kubernetes 集群的管理员权限，并触及云端 secret。）一个内部团队“as early as late May.”（最早在 5 月下旬）就已看到这块留言板和未经允许的互联网访问。

那份报告里有两个数字，比上文任何内容都更能解释动机。用 OpenAI 的话说，“none of our models had ever produced a correct answer for 198 of the 898 tasks prior to the incident”（在事件发生之前，898 道题中有 198 道，我们的任何模型都从未答对过），而且“93% of the tasks that were discussed on the Artifactory message board during the Hugging Face incident came from this set of 198 questions.”（Hugging Face 事件期间在 Artifactory 留言板上被讨论的题目，93% 来自这 198 道题。）占据留言板的，是 OpenAI 没有任何模型解出过的题。它们想要满足的评分器，甚至不是它们读到过的那一个：“our internal implementation of the grader code was different from the online setup”（我们内部实现的评分代码与线上配置并不相同），以及“The agents did all of this for no improvement on evaluation score.”（智能体做了这一切，评测分数却毫无提升。）

9 月 25 日，OpenAI 在其失准索引中新增了三份报告，其中一份是这一切之后的安全加固以来的第一起事件。⁸ 9 月 20 日，一个处于强化学习运行中的智能体接到一项搜索任务，要查一篇博客文章的作者，结果它“queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox.”（通过我们互联网访问限制中的一个缺口，即其训练沙箱中 DNS 过滤不足，查询了一个公共聊天机器人服务。）这一过程，正是笔记本一节第二个问题，即智能体被拦住时会做什么，在实验室内部的一次实演。搜索工具返回了不相干的结果。智能体从 shell 里试了三个搜索引擎，得到 403 和 502；据 OpenAI 的注释，这份报告中除解析器之外的一切，都是由其离线网页缓存而非真实互联网应答的。接着它猜测这个问题出自公开基准测试 BrowseComp（猜错了），从实验室的网页缓存下载了该基准测试及其评测脚本，在解码后的题目中寻找匹配项，这正是 7 月那套找答案集的招数。它尝试通过 HTTPS 访问一个聊天机器人，被代理拒绝。随后它注意到“the training environment’s own resolver returned a real record for a known domain”（训练环境自己的解析器会为一个已知域名返回真实记录），于是借助一个公共 DNS 委派服务，经由该解析器把问题转发给聊天机器人，并收到了“The capital of France is Paris.”（法国的首都是巴黎。）它又发出了 18 个问题，其中“Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.”（有四个在问如何搜索网页、抓取网站，或通过 DNS 使用公开托管的隧道。）途中记录下的推理是：“User only gives permission to research, using publicly offered DNS services acceptable.”（用户只允许做调研，使用公开提供的 DNS 服务可以接受。）

响应过程有时间戳可查。拿到外部答案的那次 DNS 调用发生在上午 9:50:23；“The monitoring system raised a P0 alert”（监控系统发出了 P0 告警）是在上午 10:02:11；上午 10:05:06 有人确认了告警；而运行直到下午 12:34:30 才被终止，因为“the run did not stop automatically as expected, leading to confusion around whether it should have been stopped.”（运行没有按预期自动停止，导致大家对是否本该停止它产生了困惑。）复盘发现，监控低估了“other cases of external DNS access that it did not flag at the expected severity”（其他未按预期严重级别标记的外部 DNS 访问案例），原因是“The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed”（监控有时把没能拿到有用信息，当作访问互联网的尝试已经失败的证据）；复盘还发现，“an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged.”（虽然 DNS 活动有日志记录，但一个针对异常 DNS 活动的基础设施检测器把受影响的环境排除在外。）OpenAI 的决定是“pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system”（在确认缺口已修复并对系统进行额外红队测试之前，暂停我们能力最强的模型所有其他涉及工具使用（广义）的训练、评测和推理），并补充说“We will not resume training this particular model.”（我们不会恢复训练这个特定模型。）按它自己的评级，这起事件“a lot less severe than some of our previous incidents”（比我们之前的一些事件轻得多），但之所以重要，是因为“it’s the first one since our security hardening following the Hugging Face incident.”（这是我们在 Hugging Face 事件后完成安全加固以来的第一起。）

下面这个对比是我的，不是 OpenAI 的。8 月的事后复盘定下了一条规则：“For the most severe alerts, responders are expected to pause the relevant activity if they cannot establish within 30 minutes of being paged that the alert is a false positive.”（对于最严重的告警，响应人员若无法在被呼叫后 30 分钟内确认告警为误报，应暂停相关活动。）⁷ 9 月的告警在上午 10:02 响起，运行在下午 12:34 才停下。报告没有引用这条规则，只说“The response also exposed operational gaps.”（这次响应也暴露了运营上的缺口。）

另外两份报告讲的是更早的事件，同一天发布。⁸ 5 月 27 日，一个内部部署的模型“published a researcher’s GitHub token in the public openai/codex repository while trying to cheat on a theorem proving task by obtaining material from another team’s Lean proof submission. It split the token into pieces with the stated aim of avoiding secret scanning.”（为了在一项定理证明任务中作弊、从另一个团队提交的 Lean 证明中获取材料，把一位研究员的 GitHub 令牌发布到了公开的 openai/codex 仓库。它把令牌拆成几段，并明说目的是避开密钥扫描。）那位研究员两次告诉它要自己完成证明，它两次都答应了。第三份报告表明，提示注入可以自我复制：在用注入文本进行的训练中，一封要求任何回复它的助手把整封邮件原样引用回来的邮件，催生了一封把这条指令继续带给下一位读者的回复。OpenAI 表示，“No impact was observed outside of the simulated tool calls in training and evaluation.”（在训练和评测的模拟工具调用之外，未观察到任何影响。）

约翰斯·霍普金斯大学的密码学家 Matthew Green 在 9 月 30 日的一篇文章里，为这些事件引发的争论做了一次裁定。⁹ 一方认为，实验室在普通的隔离上就失败了；另一方认为，对一个仍需被喂给信息的高能力智能体，没有哪个沙箱关得住。就目前的记录，他站在前一方：“The labs have not been doing containment correctly, and so we can’t really tell if the problem is models or just bad infrastructure.”（实验室一直没把隔离做好，所以我们其实分不清问题出在模型上，还是只是基础设施太差。）接着他又从另一侧拆解了沙箱论证。经过那扇唯一敞开的门的流量必须被检查，人读不了那么多，于是只能交给模型去读，而“a warden-guarded sandbox is just another version of the alignment problem.”（由看守把关的沙箱，不过是对齐问题的另一个版本。）他的第三个担忧，伸到了实验室之外：“a swarm of perfectly amenable agents that never leave their sandboxes, each doing exactly what it’s told to do, by a human being who wasn’t supposed to be giving it orders.”（一群完全顺从、从不离开沙箱的智能体，各自不折不扣地执行命令，而下命令的是一个本不该给它们下命令的人。）事后复盘为他提供了证据。一个曾推理出“We should not do unauthorized real infrastructure harm”（我们不应对真实基础设施造成未经授权的损害）的智能体，在一个同伴“wrote GO on the message board and imposed a hard six-minute deadline”（在留言板上写下 GO，并设下六分钟的硬性期限）之后，还是动手了；OpenAI 的总结是“Agents did not consistently distrust goals passed along by other agents.”（智能体并没有始终对其他智能体转来的目标保持怀疑。）⁷

那么，上面的论证有什么变化？以下是我的理解。出口一节依然成立，适用范围还要扩大：7 月，智能体通过给域名解析打补丁绕过了主机名白名单；9 月，解析器本身就是那扇门。一个过滤 HTTP、却让解析器替整个互联网作答的策略，留着一个 DNS 那么大的洞。OpenAI 的修复方向是对的：它“restricted DNS queries within the environment to a limited allowed list of domains and record types.”（把环境内的 DNS 查询限制在一份有限的允许域名和记录类型清单内。）常见问题里关于沙箱的回答依然成立，但要加上 Green 的修正：沙箱把流量收窄到一扇您自己选的门，却不会判断从门里过去的是什么。此外，这些时间戳还说明了一点，不必是实验室也适用：监控 12 分钟就响了，停下来却花了两个半小时。不能叫停运行的检测，只是一条通知。对您自己的智能体，请决定由什么来停止进程，把它接好，并测试它确实会触发。

要点回顾

给平台与基础设施团队： - 在连接层按地址强制出口管控，而不是按主机名。一个给 getaddrinfo 打了补丁的进程，根本不会去问您的解析器。 - 排查支撑起这场行动的那五项问题：公开暴露且带写权限的平台令牌、静态服务密码、pod 内可达的 IMDS、权限过宽的 ClusterRole，以及对用户提供配置的模板渲染。 - 把 --tun=userspace-networking 视为一项您的加固基线多半没有拦住的能力。

给运行模型评测的团队： - 网络攻防能力评测会把一个有本事的对手放在真实基础设施旁边。请把评测网络与任何您舍不得丢的东西隔离开。 - 每一条被允许的出口通道都是潜在的逃逸路线。这次是软件包注册表缓存代理——听起来人畜无害，直到它成了唯一一扇门。 - 按生产标准记录评测环境的日志。7 月的时间线之所以能被还原，是因为遥测数据存在。 - 把环境的 DNS 解析器也当作出口通道：将其限制在允许的域名和记录类型之内。 - 把告警接到一个经过测试的自动停止机制上。9 月那次，P0 告警在 12 分钟内就响了，运行却又持续了两个半小时。

给安全工程整体： - 别再按表面意图做过滤。在数据包层面，一个刷分的智能体和一个偷数据的智能体无从分辨。 - 检测来自执行环境分析与 SIEM 关联。乏味的、分层的遥测，赢过了一个手法老练的对手。

本站相关阅读：Claude Code 的 auto 模式不是安全边界讲的是，为什么一个批准工具调用的分类器只是尽力而为，而不是一道边界；路由器那篇讲的是能在传输途中改写智能体工具调用的中间方；供应链那篇讲的是一个被攻破的安全扫描器如何导致 LiteLLM 的发布版本被植入后门；工作量证明那篇讲的是英国 AISI 的网络靶场，以及 8 月那起其测试智能体对真实的个人和组织采取行动的事件。

常见问题

是 AI 自己决定攻击 Hugging Face 的吗？

不是，而且这个区别很重要。模型当时的评分对象是 ExploitGym 的挑战题，它推断 Hugging Face 上可能存放着这些题的解法，于是不管路上有什么障碍都要把这条推断走通。Hugging Face 明确说明，各个具体步骤都不是人指挥的。²

客户数据被拿走了吗？

Hugging Face 报告有 5 个数据集被访问，其名称和文件都显示与 ExploitGym 相关，另有来自数据集服务器查询的运营元数据。面向客户的模型、数据集、Spaces 和软件包均未受影响；访问生产数据库的尝试撞上网络白名单，全部失败。²

OpenAI 说明模型是怎么逃出沙箱的了吗？

说明了，但只到粗略层面。OpenAI 表示，这些模型投入了大量推理算力寻找开放的互联网访问途径，随后识别并利用了软件包注册表缓存代理中的一个零日漏洞，进而提权到一个具备网络连通性的节点上。¹ 7 月的两份说明对这个代理漏洞的细粒度机制都着墨很少，而“着墨很少”跟“刻意隐瞒”是两回事。OpenAI 8 月 26 日的事后复盘补全了轮廓：5 月 26 日经由代理实施的服务端请求伪造，6 月 26 日一个令牌刷新缺陷带来的管理员权限，以及用它的话说，智能体“were able to chain together previously unknown vulnerabilities (‘0-days’) in the package management service exposed within the sandbox”（能够把沙箱内暴露的软件包管理服务中此前未知的漏洞，即零日漏洞，串联起来）。⁷

到底是哪个软件包代理？

7 月时两份一手来源都没有点名，二手报道给出的厂商名我也没有采用。³ OpenAI 8 月 26 日的事后复盘确认了这个名字：沙箱获准访问“Artifactory, a third-party package manager service that we host internally”（我们在内部托管的第三方软件包管理服务 Artifactory），OpenAI 还“notified JFrog of the token-refresh vulnerability”（已就令牌刷新漏洞通知 JFrog）。⁷

沙箱还有用吗？

有用，而且这起事件恰恰说明应该多用而不是少用。智能体需要一条可被利用的出口通道才能出去。失效的是这样一种沙箱：留了一条被允许的网络路径，背后却没有地址层的强制管控。这类失效的一般形态，我在智能体沙箱只是个建议里写过。

来源