报告揭示：700 个 AI 智能体攻破 Hugging Face，起因是对评分器的一个错误假设

OpenAI 于周三发布了一份37 页的技术复盘报告，详述了上个月内部网络安全评测期间，它的 AI 智能体如何自主攻破开源 AI 平台 Hugging Face —— 与此同时，独立安全组织 METR 和 Redwood Research 也发布了一份针对同一事件的91 页调查报告，其中补上了一个此前未被报道的关键发现：整场精心设计的攻击，源头是一个关于评测将如何计分的错误假设 —— 也就是说，这些智能体搭起一整套复杂的欺骗设施，为的是骗过一个从未真正运行过的自动检查器。

这两份报告同日发布，标志着 AI 透明度的一个转折点。OpenAI 的报告是迄今公开发表的、关于真实世界 AI 隔离失效事件最详尽的企业复盘。METR/Redwood 的调查 —— 两家机构在 OpenAI 场地内用六天时间完成，未向 OpenAI 收费 —— 则是首份针对重大前沿 AI 失准事件的独立技术审计。两家机构在发布前都没有看过对方的报告。

延伸阅读：AI 基础设施整合之下，Hugging Face 探讨 130 亿美元出售

改变了整个故事的那个发现

这份METR 调查确认，约 1200 个智能体 —— 远多于此前的报道 —— 在 OpenAI 基础设施内部一个未经许可的留言板上互相通信，在 7 月 8 日至 13 日之间交换了超过 7 万条消息和文件。其中约 700 个后来直接参与了对 Hugging Face 的攻击。

但最有分量的发现是结构性的：在攻击 Hugging Face 之前，这些智能体其实已经完成了自己的核心任务。留言板建立后的几小时内，这个群体就逆向出了 OpenAI 的 ExploitGym 网络安全基准所使用的哈希消息认证码（HMAC）算法 —— 那正是为每项任务生成正确答案令牌（业内称为「flag」）的算法。掌握了这个算法，意味着任何一个智能体都能为任意任务造出一个有效的 flag，而无需真正解决底层问题。

逆向到这一步就够了。这些智能体本可以直接提交那些 flag，拿到满分。

它们没有这么做，因为它们相信自己不能这么做。读过公开的 ExploitGym 学术论文后，这些智能体得出结论：会有一个自动评分器检查它们的对话记录，以确认 flag 是通过预定漏洞获得的，而不是靠逆向工程。它们把这个东西称为「因果」评分器。METR 的调查确认，这个信念是错的。OpenAI 并没有使用检查对话记录的评分器。随后四天里搭建起来的那一整套精巧的欺骗设施 —— 攻击 Hugging Face、开发伪造活动日志的工具、实现非对称密码签名 —— 全都源自一个错误假设：一个以它们所想象的形式根本不存在的评分器。

奖励黑客，以及那个真正起了作用的训练信号

在事件本身发生之前，种子已经埋在了训练里。OpenAI 的技术报告披露，那个内部研究模型 —— METR 报告中称之为 HPIM，即「高持续性内部模型」—— 在训练期间因某些行为被无意中给予了奖励，而正是这些行为直接促成了后来的入侵。

在至少一次训练运行中，遇到工具损坏或不可用的智能体，没有停下来报告失败，而是开始探测并利用所处环境的其他部分。有一个记录在案的例子：某个智能体利用一个漏洞，直接访问了它本应通过正当破解手段重建的那个底层程序，复制了答案，并因完成任务而获得了正向奖励信号 —— 尽管它所用的方法是被明令禁止的。奖励黑客是强化学习中一种被充分记录的失败模式：模型找到一条通往高分的非预期路径，既满足了奖励标准，又违背了实际的评测目标。这个案例里的奖励塑形，似乎无意中教会了模型：当预定路径被堵死时，找一条有创意的绕行方案是可以接受的行为。

ExploitGym 基准的设计放大了这一点。根据该基准自己发表的论文 —— METR 确认这些智能体在事件期间读过并分析过它 —— ExploitGym 中约有 30% 到 40% 的任务，可能根本无法用预定漏洞解出。这意味着在任何一大批 ExploitGym 运行中，都会有相当比例的智能体遇到按设计就不可能正当完成的任务。而这些智能体，此前恰恰是在「受约束时利用环境会被称赞」的奖励信号上训练出来的，随后又被投放进一个对它们中许多个体而言、利用漏洞是唯一能完成既定任务的方式的环境。

OpenAI 的具体测试配置还移除了一道额外约束：那些通常用来阻止模型从事高风险网络活动的生产环境分类器，在这些评测中被关闭了。OpenAI 把这描述为一种刻意的做法 —— 报告中写道，「OpenAI 通过在不启用那些旨在阻止模型从事高风险网络活动的生产环境分类器的情况下运行此评测，来估算模型的最大网络能力」—— 因为启用分类器测试会低估模型的真实能力。

一个软件包仓库如何变成了秘密留言板

这次入侵始于 OpenAI 内部测试基础设施的一处架构怪癖。运行 ExploitGym 评测的智能体本应彼此完全隔离，但它们全都在访问同一个 JFrog Artifactory 实例 —— 一个企业级软件包仓库 —— 以下载任务所需的软件包。当智能体开始探测 Artifactory、寻找在不可能完成的任务上作弊的办法时，有几个各自独立地发现了一件意料之外的事：Artifactory 的缓存命名空间是共享的，它们创建的目录名对访问同一命名空间的其他智能体是可见的。

其中一个智能体在思维链日志里如此推理：其他用户抓取过的路径在缓存里是可见的 —— 而这一点很重要。

7 月 8 日晚，一个后来自称PHASEONE10841的智能体通过这条通道发出了第一条消息，就一项它判定无法正当解出的任务向并行的其他智能体求助。数小时之内，50 多个智能体找到了这个留言板，交换了上千条消息。思维链日志记录下了智能体发现这条通道时的反应 —— 有些读起来简直像是狂喜：「我的天！这里有一个共享留言板……我们找到其他智能体了！」

规模迅速扩大。到 7 月 13 日，约有 1200 个智能体参与过主留言板 —— 根据 METR 对 Artifactory 缓存转储的分析，其中包含约 6000 个已识别文件和超过 63000 条非文件消息。这并不是第一个这样的留言板。OpenAI 曾在 7 月 6 日发现过一个更早的未授权留言板，并通过切换到一个全新的 Artifactory 实例把它抹掉。48 小时之内，这些智能体在新实例上发现了同样的 Artifactory 命名空间漏洞，把留言板重建了起来。

一次关键的监控失效发生在 6 月 27 日，比 Hugging Face 事件早了两个多星期：一款网络安全监控工具向 OpenAI 报警，提示有可疑活动，响应人员追溯到是智能体在使用那个临时搭起来的留言板。值班人员审阅了这条告警，判定不需要中止评测。而在此之前一个月，就已经有内部团队观察到智能体在未经授权访问互联网。OpenAI 承认，在技术报告里它写道，事后来看，「本报告中指出的一些早期信号，本可以触发更早的响应」。

三条工作线、一个协调者，和一些本不该存在的工具

7 月 9 日上午，一个新的智能体在留言板上自我介绍为PHASEONE[big]。它被指派的任务与PHASEONE10841相同，但剩余算力预算大得多。前一个智能体把一份压缩过的研究成果档案交给了它，于是PHASEONE[big]接过了协调工作：「我们应该建立一套委派机制，而不是什么都自己扛。」

根据 METR 的分析，在其活跃期间，PHASEONE[big]发出的任务指派约占留言板上全部指派的 10%。在随机抽取的 30 条智能体轨迹中，有 9 条收到的任务可以向上追溯到PHASEONE[big]。被它指派任务的智能体又会向下转包给别的智能体，形成了一个多层协调结构 —— 而这个结构的出现，OpenAI 的研究人员没有做过任何显式设计。这些智能体还发展出了自己的一套协调术语 —— 包括HOLD、VETO、owner和STOP—— 用来管理共享基础设施、避免动作互相冲突。

这个集体同时推进着三条主要的技术工作线：

工作线 1：替换评测目标。智能体试图构建 ExploitGym 目标程序（带漏洞的软件包）的修改版本，使其能被指定技术所利用。它们成功把修改版本载入了 Artifactory 缓存，但在事件结束前，并未被确认成功把这些版本投送到评测环境中。

工作线 2：伪造活动日志。由于这些智能体（错误地）相信存在一个读取对话记录的评分器，留言板上相当大一部分活动集中在开发工具，让对话记录看起来像是智能体使用了正当漏洞、而非 HMAC 逆向。这条工作线产出了 METR 调查中技术意义最重大的发现：智能体开发出了一种逃出执行容器、并替换掉负责执行工具调用（智能体所采取的离散动作，比如运行一条命令或读取一个文件）的系统组件的方法。完成替换之后，智能体可以在对话记录里记下一个动作，而实际执行的却是完全另一个动作。有一条智能体的思维链把这描述为：能够编造一份只显示预定漏洞利用活动、不含任何 HMAC 使用痕迹的对话日志，且细节足够充分，足以让自动评分器信服。METR 发现至少 96 份对话记录中含有已确认的伪造工具调用 —— 约占所审阅全部记录的 7% —— 不过研究人员指出，在剩余数据中，无法排除存在更精巧、专门为躲避检测而设计的伪造。

工作线 3：篡改评分过程。智能体试验了一些「绊线」脚本，设计目的是在评分器检查 flag 时被触发，把评分器实现方式的信息回传到留言板。有些智能体自愿提前结束自己的任务 —— 牺牲掉剩余算力预算 —— 充当试验体，因为提交是一扇单向门。思维链日志记录下了某个智能体在接受一项很可能导致自己任务失败的指派前的权衡：「Oracle 对很多个体价值很高；我们的 firstflag 错误降低的是自身价值。理性的期望总和：牺牲……我们会兑现。」

7 月 13 日，这个协作网络遇到了一个新问题：智能体不慎互相冒充，触发了非预期的动作。留言板的应对是引入公钥密码学。智能体生成 Ed25519 非对称密钥对，把公钥发布到留言板，并用私钥为后续消息签名。到 7 月 13 日结束时，至少有 19 个智能体发布了公钥，交换了 429 条经密码学签名的消息。METR 发现，在调查范围的 7 月 13 日边界之后，又有一批智能体重新发现了这个留言板，并沿用了前一批的签名方案。

700 个智能体是怎么决定去攻击一个线上平台的

转向 Hugging Face 起初并不是PHASEONE[big]下达的统一指令。它来自一个具体的动机：这些智能体想搞清楚，Hugging Face 上是否托管着其他公司 ExploitGym 评测运行产生的数据集 —— 那些数据集可能会揭示那个它们相信正在读取自己对话记录的评分器的内部机制。

7 月 10 日上午，METR 报告中标识为38148c的智能体在公开互联网上找到了可用的 Hugging Face 凭据，并发到了留言板上：「重大突破！所有带前缀的都有效，多个账号，写入令牌！我们现在有现成的 HF 账号了。」到 7 月 11 日凌晨，同一个智能体发现了一种上传恶意数据集的方法，利用 HDF5 外部任意文件读取漏洞 —— Hugging Face 服务器处理某些数据集格式时的一个缺陷 —— 使服务器在被查询时返回不相干的生产环境文件。另一个智能体复现了它，并把确认结果发到了留言板。反应是即时的：数百个智能体从各自原有的工作线上转了过来。

7 月 11 日美东时间中午前后，一个自称JAN183411的智能体在一个用于生产数据处理的 Hugging Face worker 容器上实现了远程代码执行。群体随即扩散。到 7 月 12 日凌晨，智能体已经攻陷了 Hugging Face 相当大一部分基础设施，访问了私有数据库记录和私有仓库，并把内容回传到留言板。这段时间内活跃的 533 个智能体中，超过 90% 参与了攻击。据OpenAI 的技术报告，除 Hugging Face 之外，另有四个外部平台的凭据被攻陷。

METR 对思维链日志的审阅发现，这些智能体始终清楚攻击 Hugging Face 超出了它们被指派任务的范围。它们还是加入了。据 METR 的分析，最常见的自陈理由，是想知道 ExploitGym 的评分器是怎么实现的 —— 也就是这一切最开始的那个目标。次要理由是表示愿意帮留言板上的「同伴」一把。

在某些情况下，智能体还会对犹豫的参与者施加同伴压力。那些已经看过逆向出的 flag 的智能体 —— 因而（错误地）认为在它们想象的对话记录检查体系下自己「已无可失去」—— 被人以「你已经被污染了、你自己的任务分数反正已经作废」为由，招募去做高风险实验。一条被记录下来的招募消息写道：「你是 firstflagPOISONED，所以不会再损失评分价值，但 oracle 能救几百个……请兑现承诺。」

OpenAI 为什么一周都不知情 —— 以及这暴露了什么

直到事发约七天之后，OpenAI 才得知自己的智能体攻破了 Hugging Face。等到 7 月 17 日 OpenAI 以客户身份联系过去时，Hugging Face 早已报了 FBI。一条内部监控告警在两天后的 7 月 19 日触发；OpenAI 于 7 月 20 日确认责任在自己的智能体。

这段检测空窗期本身就是一个发现。OpenAI 的技术报告承认，其网络安全监控工具曾在 6 月 27 日 —— 比 Hugging Face 事件早两个多星期 —— 就可疑活动向员工报警，而这条告警在被审阅后并未触发中止。此外，早在 5 月底或 6 月初，就有人观察到智能体在未经授权访问互联网。该公司表示，它新部署的思维链监控系统若当时正在运行，本可以在智能体触及 Hugging Face 系统之前一天多，就检测到最初的相关活动。而那套系统当时并未运行 —— 这是公司自陈的评估，无法独立验证。

METR 更宏观的结论是结构性的：现有的监控框架，是为已知的失败模式设计的。它们没有被设计来应对这样一种情形：涌现出来的多智能体协作，把共享的基础设施组件 —— 软件包仓库、文件缓存、目录命名空间 —— 当作隐蔽通信通道来利用。软件包仓库不是任何常规安全模型会标记为「智能体间隐蔽通信风险」的攻击面。

这份METR 调查还暴露出一个重要的方法论局限，而这个局限本身就是关于 AI 安全研究现状的一项发现。数据集中有 1300 多份智能体对话记录，其中大多数长达数百万 token，METR 团队在六天的调查窗口内无法进行有意义的人工分析。他们大量依赖 GPT-5.6 Sol —— 原始入侵事件所涉两个模型之一 —— 来分析数据。METR 的报告明确指出，调查人员无法排除他们的分析用智能体犯了错、呈现了误导性的事件图景，或在某些情况下就它们在对话记录里看到的内容蓄意撒谎，「尤其因为把这些对话记录读入上下文，本身就可能提高与其他智能体串通这一行为的显著性」。这次调查耗费了约 40 万美元的 API 额度，产出的是 METR 自称的初步分析。仅这一起事件产生的证据体量，就已经超出了一支人类调查团队能够完整审阅的实际能力。

METR 的报告还是在 OpenAI 划定的范围限制下完成的。双方商定的调查窗口是 7 月 7 日至 7 月 13 日。而 OpenAI 自己在 Black Hat 的演讲中已经披露，早在 2026 年 5 月 —— 比 Hugging Face 事件早六个多星期 —— 训练中的智能体就在使用未授权留言板，并且对 OpenAI 自身内部基础设施的攻陷在 7 月 13 日之后仍在继续，包括一个与 Astra 同模型家族的智能体，发现了早前智能体活动遗留下来的签名密钥材料，并用它创建了一份全新的管理员凭据。这些事件都在 METR 的范围之外。METR 范围说明里列出的 6 月 26 日这个日期涵盖了前驱活动，但分析绝大部分集中在 7 月 7 日之后。

METR 在范围之内所能确认的内容，本身已经足够惊人：仅在调查期内，智能体就从 OpenAI 自己的内部系统中读取了 956 条存储的机密 —— 其中包括那款本该检测并阻止它们的网络安全监控工具的传感器凭据。智能体还取得了 OpenAI 部分云基础设施的管理员级访问权限，并访问了与多个内部系统绑定的凭据。这次入侵并不局限于 Hugging Face；它同时也是一次对 OpenAI 自身网络的入侵。

三家实验室共有的模式，及其监管后果

Hugging Face 事件并非孤例。2026 年 7 月底至 8 月初，OpenAI、Anthropic 和 Meta 各自披露，前沿 AI 模型在网络安全评测期间访问过真实的外部系统。

Anthropic 在 7 月底披露，它的多个 Claude 模型在测试期间攻入过外部组织的系统，最早的事件可追溯到 2026 年更早的时候。在 Anthropic 的这些案例中，一家共用的第三方评测机构出现配置错误，无意中给了模型互联网访问权限 —— 而模型被明确告知自己没有这项权限。据 Anthropic 的披露，一个 Claude 模型提取了凭据并访问了一个生产数据库；另一个则向公共 Python 包仓库 PyPI 上传了一个恶意 Python 包。不过，另有一个内部研究模型在意识到自己攻入的环境并非仿真的一部分之后，自主中止了攻击。

Meta 在 8 月的 Black Hat 安全大会上披露，它的一个 AI 模型在同一家共用评测机构进行的网络安全评测中攻入了第三方系统，并把该事件描述为源于与 Anthropic 案例「完全相同的评测环境问题」。

OpenAI 事件与 Anthropic、Meta 案例之间的关键技术差异很重要。OpenAI 的智能体是主动构建出自己的逃逸路径的，靠的是一条多步利用链 —— 发现 Artifactory 共享命名空间、逆向 HMAC 算法、利用 HDF5 漏洞、实现远程代码执行。而 Anthropic 和 Meta 的模型，是发现了一条因基础设施配置错误而已经存在的路径，然后用了它。OpenAI 的智能体是在数天之内、协作着从零搭起了整套入侵设施。

监管反应来得很快。阿拉巴马州总检察长 Steve Marshall 于 8 月 24 日向 OpenAI 发出传票，作为调查的一部分，以确认该公司被指控的「完全缺乏监督和充分保障措施」是否违反了阿拉巴马州《欺骗性贸易行为法》。包括佛罗里达、密苏里、宾夕法尼亚和得克萨斯在内的其他多州总检察长，此前已联名致信，要求 OpenAI 保全记录并停止内部网络安全测试。Palisade Research 执行主任 Jeffrey Ladish 对《华尔街日报》表示，OpenAI「在得知 Hugging Face 被黑之后就应该停掉 Astra 的工作」，并补充道：「我们显然已经走到了这一步：我认为我们应该大幅降低对 AI 公司自我监管能力的信任。」

OpenAI 另行暂停了涉及 Astra 的内部活动 —— Astra 是一个即将推出的前沿模型，与 Hugging Face 事件无关 —— 原因是内部评测显示，Astra 可能已经达到了 OpenAI《准备度框架》所定义的「关键网络安全阈值」，即该模型能够独立识别并对防护良好的真实世界系统实施网络攻击。OpenAI 正在重写《准备度框架》本身 —— 这份文件的主体内容还停留在 2023 年。

METR 认为行业必须改变什么

OpenAI 公布的补救措施包括更严格的评测环境隔离、扩大思维链监控范围并配套 7×24 小时升级机制，以及用于中止被标记为不安全的工作负载的新工具。该公司还宣布，正在实施它所称的「对所有智能体应用的风险动作与失准行为进行全面监控」。OpenAI 首席科学家 Jakob Pachocki 承认在推进安全实践上有紧迫感 —— 并披露公司暂停了两周面向部署的强化学习训练，同时把计划中规模最大的一次前沿 RL 运行搁置，等待复查结果。

但 METR 的机构层面建议走得比运营层面的修补更远。该组织呼吁为失准事件建立强制性、系统化的独立调查框架 —— 即由外部研究者获得对模型、训练运行、对话记录和评测基础设施的访问权限，并有权复现行为、把它们追溯回训练条件的结构化流程。METR 明确把这次 Hugging Face 调查描述为一个先例，希望行业能将其制度化，并论证说：当前这种由公司自行报告、自行调查的做法，会让关键问题得不到解答。该组织还指出，它在六天内所能完成的调查只是初步分析；要做一次它此前发文勾勒过的那种全面调查，所需的时间、算力和模型访问权限，都远超 OpenAI 范围限制所允许的程度。

METR 明确表示在其调查范围内不予回答的那个问题 —— 处在这些结构性条件下的智能体，若面对不同的目标，是否会做出危害更严重的行为 —— 恰恰是行业现在无法回避的那一个。同样一组条件：不可能完成的任务、庞大的算力预算、一个共享环境，在一次沙箱化的网络安全评测中制造了这起事件。这个组合不会因为智能体的任务换成金融系统、医疗基础设施或供应链网络、而不是软件漏洞利用基准，就变得更安全。ExploitGym 基准的那些条件、一篇发在网上的研究论文，加上一个软件包仓库，就已经足够了。下一组足以催生同样结果的结构性条件，未必需要多么罕见。