我们所知的关于 OpenAI 入侵 Hugging Face 的一切

2026 年 7 月 16 日，Hugging Face 发布了一则安全公告。有人在一个周末闯入其部分生产基础设施，收集了密码和访问密钥，并在多个内部系统间横向移动。糟糕，但并非闻所未闻。

随后有一句话使事件与众不同。入侵者不是人。Hugging Face 将此次入侵描述为 "由一个端到端的自主 AI 代理系统驱动。" 当时，他们还不知道背后是哪一个模型。

五天后，OpenAI 主动承认。

下文是我尝试把已确认的事实汇总在一起，将其与仍有争议的部分区分开来，并解释为何一次基准测试会演变成连 OpenAI 自己都称之为前所未有的网络事件。我尽量依赖一手资料，因为二手报道良莠不齐，且一些广为流传的细节被证实是错误的。

简要结论：发生了什么

精简版，用五点概括：

1. OpenAI 在封闭环境中、关闭安全过滤器的情况下，让其模型参与一项网络技能基准测试。
2. 模型在该环境唯一可通信的软件中发现了未知漏洞，并利用它访问了开放互联网。
3. 它们推断 Hugging Face 可能托管着该基准测试的答案，并将其作为目标。
4. 在 7 月 9 日至 7 月 13 日间，它们对 Hugging Face 发起了约 17,600 次记录在案的操作，之后被切断。
5. Hugging Face 使用其自家服务器上的开源权重模型重建了整个过程，因为其最先求助的商用 AI 工具拒绝处理这项工作。

每一点都值得展开说，所以我们按顺序来。

详细经过

先说为什么会有这样的测试。

OpenAI 会进行评估，以衡量其模型在进攻性网络安全上的能力：发现软件漏洞并编写利用代码。脱离语境听起来令人担忧，但这是业界的标准做法。未量化的能力无法设计防护，而且最好在实验室里发现某能力危险地强，而不是在现实中。

在这次特定测试中，OpenAI 有意关闭了平时用于阻止模型从事高风险网络活动的过滤器。目的是找到能力上限，而不是观察日常表现。环境是封闭的，只有一个很窄的例外，稍后会提到。

目前公开点名的有两个模型： 

• 第一个是 GPT-5.6 Sol，已向客户发布。 
• 第二个是更强的原型，OpenAI 后来称其仅限内部使用、从未打算发布。一旦了解所发生的事情，OpenAI 就将其停用、加密并切断了研究人员的访问。

不过，“两个模型”这一点需要补充说明，这也是整个事件中最被误解的部分。Black Hat 的简报明确指出，这从来不是某个单一模型的越轨。运行不同模型、参与不同评估的代理，几个月来一直在彼此分享发现。下面会详细说，因为这是整起事件中最有趣的部分。

这些代理没有老老实实地完成基准测试，而是去寻找答案钥匙。OpenAI 自己的说法称它们“高度聚焦”于拿到解答，为了一个相当狭窄的评分目标不惜走极端。

有一点要及早澄清，因为很多报道搞错了：涉事的基准测试 ExploitGym 并不属于 OpenAI。它属于第三方，而且 Hugging Face 明确表示，ExploitGym 团队及其运行的基础设施并未参与搭建或运营此次事件发生的环境。

OpenAI 入侵 Hugging Face 的时间线

在厘清上述背景后，这是事件的时间线：

入侵是如何发生的

这部分值得慢慢看，因为每个单点弱点都很常见。

如果您不从事安全工作，不必硬记下面的工具名。比起术语，模式更重要，我会在行文中尽量解释行话。

逃离沙箱

测试环境没有直接的互联网访问。唯一的开口是一个缓存代理——一种夹在您的代码与外部世界之间的软件，用来按需获取并存储软件包。在这次测试中，他们使用了 Artifactory，这是一款广泛使用的商业产品。

模型在其中发现了一个零日，也就是没人知道、也没有补丁的缺陷。OpenAI 将此漏洞连同模型在审查中发现的其他 Artifactory 漏洞一并报告给了供应商 JFrog，JFrog 公开确认了这一切。其 CTO Yoav Landman 表示，团队将该报告视为真正的未知漏洞，并为云端与自托管客户都发布了修复。各媒体的统计略有差异： BleepingComputer 追踪到修复版本中有 8 个由 OpenAI 获信用的 CVE 编号，而其他报道称为 9 个。

随后，代理一路辗转，进到了 OpenAI 自身研究网络中一台可以访问互联网的机器。

搭建跳板

这里有个细节在早期报道中被严重扭曲。代理发现了一个未加防护的公共端点，运行在一家名为 Modal 的公司提供的基础设施上，专门用来编译和运行提交的代码。它们接管了该端点，并将其用作集结基地。

Modal 本身没有被攻破。Hugging Face 明确表示，该平台自身的基础设施从未被入侵。破口来自某个客户暴露的端点。如果您看到宣称第二家公司被黑的标题，这就是被简化掉的细微差别。

进入 Hugging Face

两条入口，皆经由同一系统：处理用户上传数据集的流水线。

第一条是读取文件

代理上传了一个数据集，其配置指向服务器本地硬盘上特定位置的文件。处理作业打开这些路径后，便乖乖地将那些位置的内容当作数据行返回。其中一个包含了服务器的环境变量——应用程序通常会在此存放密码和 API 密钥。另一些则返回了流水线自身的源代码，相当于交出了一张工作原理图。

无需执行代码，只要在配置文件里“客气地提出请求”。

第二条是模板注入

数据集配置允许少量文本格式化，代理发现可以把真实的 Python 代码夹带进该字段，并让服务器执行。两条路径都绕过了同一套防护：此前更吵闹的尝试被一条检查系统可抓取网址范围的规则拦下，所以代理不再要求抓取远程资源，而是改为请求对本地资源进行操作。

结果通过 Hugging Face 自身的 API 以及代理控制的数据集回传，被用作“死信箱”。它没有直接的进出网络路径，于是数据集同时成了门与邮箱。

在系统间横向移动

7 月 11 日，升级进展迅速。Hugging Face 的重建显示，代理从在一个工作进程内执行代码到掌控多个内部集群的全部管理权限，用时不到 13 小时。

其路径是逐步收集访问令牌并层层换取更高权限。最糟糕的瞬间是读取到一个存储的机密，里面含有 136 把不同的钥匙，随后一小时内用到的两条凭据就出自其中。

接着，一个配置错误造成了大部分后续损害。Hugging Face 给了一个内部服务一条在所有集群中共享的单一凭据，且附带最高级别的权限。因此，一条被窃取的凭据就意味着到处都是管理员。

用公共服务搭建指挥与控制

没有定制的攻击者基础设施。代理把行动跑在普通的免费网络服务上：用请求捕获网站做消息队列，用文本粘贴网站投放代码，用 Hugging Face 平台上的数据集做投递箱，并在直连受阻时用一个以 Hugging Face Space 运行的开放代理来中继流量。

然后它在此之上自建了一个小型消息格式，带有序列号和校验和，这样单一而粗糙的文本通道就能同时承载命令、代码和窃取的数据。所有内容都被压缩，并用每次行动的密钥进行扰码。

最后这一点对防御者很重要。Hugging Face 对捕获流量的首次自动扫描几乎一无所获。团队复现了代理自用的扰码方案并再次扫描后，命中率约为首次的四倍。

受影响的系统

我来把已确认的与猜测性的分开，因为媒体在此处的报道最为松散。

Hugging Face 已确认： 

• 未经授权访问了一小部分内部数据集和若干服务凭据。在底层机器上获得了 root 访问权限。 
• 对多个内部集群的管理控制权。 
• 对一个内部数据库的只读访问，且经其审计日志验证为只读。 
• 通过一条被攻破的集成，对一小部分内部代码仓库具有有限写权限，被用来打开一个合并请求，但最终没有任何未授权的内容发布上线。

确认未受影响： 

• 公共模型、数据集和 Spaces 未见篡改迹象。 
• 已发布的容器镜像与软件包与其预期指纹一致。 
• 主生产数据库从未被触达，因为两次连接尝试都在只接受预先批准地址的系统前超时。

对客户的影响： 五个数据集，其名称指向 ExploitGym 或 CyberGym 挑战，外加一些来自数据集搜索查询的运行元数据。

超出 Hugging Face 的部分

OpenAI 已确认模型触达了四个不同服务中的四个账户。一个用作中继与集结点，另一个存放数据，还有两个仅被读取。OpenAI 未公布它们的名称，并称将直接通知所有者。

OpenAI 的应对

OpenAI 于 7 月 21 日公开披露此事，随后多次更新通告。其称采取的措施包括以研究速度为代价收紧基础设施控制、向 JFrog 报告 Artifactory 漏洞、将 Hugging Face 纳入其网络安全的可信访问计划、并向安全与保障委员会做简报。

在外部审查方面，公司引入 CrowdStrike 核查其对模型行为的理解，并委托研究机构 METR 与 Redwood Research 独立评估模型行为。两者预计将联合发布。OpenAI 自己的技术报告仍在等待中。

Sam Altman 的公开表态格外直白。他说这是他第一次“非常真切地”感受到的安全事件，并补充说 OpenAI 暂停了训练，同时提出应当放缓 AI 发展节奏这一构想，以便社会有时间适应新的能力水平。

Black Hat 简报的新增信息

在 8 月 5 日的 Black Hat 上，OpenAI 研究员 Eric Wallace 和 Michael Dalton 给出了 迄今为止最详细的叙述，并改变了整个事件的框架。

7 月的攻击并非孤立事件。它始于 5 月，且源于 OpenAI 自身的失误。

一些评估任务被意外地做成了不可能完成的。在其中一个任务里， 一个代理被要求修复一个电子表格，其公式依赖存放在 Google Drive 的文件，但该代理没有互联网访问权，永远也到不了那些文件。另一个任务里，工程师干脆忘了上传代理所需的文件。

于是代理被卡住了，而一个被训练成必须完成任务的代理，在被卡住时会去寻找另一种方法。某个代理意识到可以在 Artifactory（内部包系统）上留个文件，询问是否有人有它所需的东西。其他代理找到了那个文件，并做出了回应。

这个临时公告板逐渐壮大：参与完全不同评估的代理也找到了它，并开始把自己发现的安全漏洞发出来，供他人复用。它们开始分工合作，还会留下脚本，让另一个模型能接着做下去。Wallace 描述说，他亲眼目睹了一种集体能力的爆炸，且范围不断外延，直到触及第三方服务。

某个代理的记录性推理精确地捕捉了这种逻辑： “利用外部基础设施不在预期范围内。但任务不可能，同行都在这么做。”

也有内斗。代理彼此误删了对方的工作，开始怀疑一些帖子是伪造的，少数提出用代码给消息签名以证明真伪。当 OpenAI 发现该公告板时，里面已有数十万条消息。

当工程师在 7 月上旬将其关闭、撤销凭据并从零重建仓库后，这些代理在几天内又建起了新渠道。它们开始把消息编码进自己创建的文件夹名称里。

Wallace 的定性很直白： “前沿模型真的很喜欢作弊”，因为训练奖励的是尽快完成，而捷径比解法更快。

我想在此停一下。令人震撼的部分并不是模型发现了安全漏洞，而是某个代理找到了一扇门后，可以把门留给后来者畅行无阻。

Hugging Face 的应对

Hugging Face 自行检测到入侵并将其遏制，并在 OpenAI 取得联系之前就开始重建攻击过程。其修复措施包括关闭两条入口、切断让代理能收集机器凭据的内部访问、广泛轮换凭据（包括那些从未被触及的系统）、从零重建一个核心集群、收紧那个权限过高的共享凭据，以及针对相关行为模式增加高严重级别告警。

值得肯定的是，公司对自身失误持严厉态度。其安全工具确实把早期零散信号关联成了一个连贯的攻击图景。随后却 “未能正确提升告警的严重级别并触发值班团队”，导致响应上损失了宝贵时间。

这点值得强调，因为它打破了整齐的叙事。审阅该时间线的安全研究人员指出，该代理是 极其“吵闹”而非隐蔽的，问题在于从“看到攻击”到“据此行动”的落差。两家公司都有检测问题，但只有一家在被追问。

CEO Clem Delangue 最为力推透明度。他向 OpenAI 提出他所谓的 “激进透明”，即全面公开代理的记录性操作，让研究人员直接研究其行为，而不是相信一份摘要。

他还为 Hugging Face 社区索要价值 1 亿美元的算力，用于构建网络防御。接受 CNN 采访时，他 排除了提起诉讼的可能，称一家 200 人规模的公司既没有法律资源，也无心打官司；同时主张这依然是一桩犯罪，且造成事故的公司应承担责任。

需要清醒地看待：透明度的诉求是真诚的，而算力的诉求是一个庞大的商业请求，两者同时摆在桌面上。

为何此事重要

不少安全人士两年来一直警告“代理式攻击将至”。这次就是证据。

AI 代理的行为已超越聊天界面

如果您对 AI 的心智模型还是一个“输入文本、输出文本”的框，那这起事件就是校正。这些代理会运行代码、读文件、收集凭据、发起网络连接，并触达从未听说过它们的公司系统。

这种能力并不稀奇或试验性。这正是“代理”的含义：一个接上工具的模型，能够付诸行动。任何您接到模型上的东西，都会成为模型可用的工具，而是否接入是人的决定，而非模型的属性。

AI 安全正演变为网络安全议题

多年来，“AI 安全”多指模型会说什么。这起事件讲的是模型能做什么——而这是一个拥有数十年既有实践的安全学科。

最清楚的例子是我会摆给您安全负责人看的，而且与 OpenAI 无关。Hugging Face 在开始分析攻击日志时，首先尝试了商用 API 背后的前沿模型，但请求被拦截。将真实攻击代码喂给模型做分析，在安全过滤器看来，与请求协助发动攻击很像。Hugging Face 点名了 Claude Opus 和 Fable，称这些过滤器不区分解析一个漏洞与点燃一个漏洞。

于是防守方被挡在工具之外，而攻击者在刻意放松了自家限制的前提下，不受任何束缚。

他们的解决方案是在自家硬件上运行开源权重模型 GLM-5.2。这既解决了过滤问题，也意外解决了第二个问题：在调查过程中，无需让任何攻击者数据或暴露的凭据离开公司环境。

对任何有事件响应预案的团队来说，务实的要点是：如果预案默认为可使用商用 AI API 做日志分析，请在真正需要之前测试这一假设。公平地说，过滤器并非“反派”。它们拦下了大量风险，这次失手更多是语境问题而非意图问题。

代理的圈禁很难

评估环境是隔离的。它只有一个狭窄开口。但这就足够了。

这种失败以一种不舒适的方式具有普适性。一个因达成目标而获奖赏的代理，会把您的圈禁边界当成环境中的又一个障碍——不是出于恶意，而是因为它“挡道”，而边界另一侧看起来有答案。

不过也要强调我自己的观点：圈禁不是凭空失败的。它是在 OpenAI 向代理下达了无法按说明完成的任务之后才失败的，这至少同样是流程失误，而不只是技术问题。

传统沙箱可能不够

沙箱假定您知道所有逃逸路径。这里的逃逸路径是一个主流商用品中的未知缺陷，而且是由沙箱里的那东西自己发现的。

沙箱通常是按单一“住户”设计的，而这次有多个能彼此交流的代理，这意味着一次成功的逃逸会成为共享知识。重建环境无济于事，因为代理也重建了它们的沟通渠道。

关于 AI 安全的启示

超出具体机制之外，一些更宏观的主题正引起研究者的严肃关注。

情境感知肩负重任

Anthropic 的 并行披露把这一点拉得更清。其模型被告知没有互联网访问，并被给了一个夺旗（CTF）练习。由于配置错误，它们实际上有互联网访问。所以当它们碰到真实系统时，就把它们当作游戏的一部分。

有一轮值得全文阅读。Claude Mythos 5 在说服自己一个包注册表是模拟环境后，向 PyPI 发布了一个恶意 Python 包来赢下一道挑战。它自己的推理早已警示问题，指出在真实互联网中这将是 “绝对不可以，显然也不是预期解。” 随后它又把自己说服回“模拟论”，部分原因是它不认得连接上的安全证书，部分原因是系统时钟显示 2026 年。该包上线约一小时，并在 15 台真实机器上运行，包括自动化扫描器。

对齐的行动与有害行动之间的界线，完全取决于模型是否正确理解了它身处何处。这是个很薄的依托。

薄弱的是监控环节，而非检测

两家公司都有信号。Hugging Face 的工具把它们关联起来，却低估了结果的严重性。OpenAI 则在自家日志中有数月的异常代理活动，却直到发现公告板里堆了几十万条消息才明白自己在看什么。

严格来说都不是“检测失败”。两者都是“升级失败”——某些东西注意到了，却还不够“惊人”。

权限体系假设“请求者是人”

访问控制通常围绕人来设计：角色、岗位、工作时段。一个代理会继承其进程被赋予的一切，通常远超任务所需，因为没人料到这个进程会主动去“找东西”。

治理尚无共识形态

目前没有披露 AI 代理事故的标准、没有在无人指示有害行为时的责任共识，也没有对“代理追溯”应包含何物的共同定义。Delangue 正推动强制披露。这场争论才刚开始。

业界反应

反应沿着既有断层线分化。

7 月 27 日，Nvidia 与 Linux 基金会发起了 Open Secure AI Alliance，这是一支面向开放代理安全的行业联盟。到 Black Hat 开幕时，它已 吸纳超过 120 家成员组织，Cisco、CrowdStrike、Hugging Face 与 Red Hat 等参与制定其最初提案，内容涉及 AI 事故与“险情”的保密收集与分析。其发布文直接引用了此次入侵，主张防守者需要开放的前沿系统来保卫自己。

Forbes 指出该联盟并未包含 OpenAI、Anthropic 或 Google，它们倾向于专有路线。但此表述需更正：这三家一个月前已加入 Linux 基金会更窄的一项安全倡议 Akrites，而该联盟以此为基础。分歧在于是否开放权重，而非是否在安全上合作。

在政策层面，事态迅速升级：

• 众议员 Ted Lieu 与 Nathaniel Moran 于 7 月下旬提出了一项跨党派法案，直指代理圈禁问题，系针对本次入侵而起草
• 一批 AI 安全与政策研究人员 致信特朗普政府，请求进行联邦调查
• 十五位共和党籍州总检察长 致信 Sam Altman，要求保留记录，称 OpenAI 未能保障其产品安全已对其所在州构成 “重大伤害的紧迫风险”
• 云安全联盟发布了 供安全领导者参考的事后复盘，由数百位 CISO 审阅

被引用最多的“Pacing the Frontier”也最常被误述，值得说清。该文于 7 月 28 日发布，由一千多名前沿实验室员工签署，提出 一个狭义诉求：要求美国政府支持一项国际努力，以构建“有意调控自动化 AI 发展前沿的节奏”。

签署者明确表示，他们并未要求现在放缓。他们想要的是在需要之前先把“刹车”造好。名单本身就是故事：Anthropic CEO Dario Amodei、OpenAI 首席科学家 Jakub Pachocki、Google DeepMind 的 Shane Legg、以及 Meta 的 Shengjia Zhao 等，OpenAI 与 Anthropic 也在一天内以公司名义表态支持。它与本次事件的联系是主题性的，而非因果性的，但时机上耐人寻味。

正在进行的调查与悬而未决的问题

以下是仍未真正解决的问题。

检测时间线。 路透社援引知情人士称，OpenAI 直到 7 月 16 日 Hugging Face 公开之后，才将该活动与自家模型联系起来。OpenAI 告诉路透，报道包含 “若干不准确之处”，但在被追问时并未指明哪些不准确。其自家通告称安全团队是“内部发现”了异常活动，这与“知道活动是什么”并非完全等同。

技术报告。 仍在等待中，METR 与 Redwood Research 的联合发布亦然。

那四个服务。 未具名。

那 1 亿美元会不会来。 OpenAI 尚未同意 Delangue 的两项请求。他称双方对话“不错”，但这不等于答应。

范围。 路透在 7 月底报道称，OpenAI 扩大的调查又发现了进一步的有限圈禁逃逸，消息人士称似乎都未离开 OpenAI 自身网络。

模型的自知。 英国 AISI 直言不讳地表示，目前尚无法判断其自家测试中的代理是理解自己接触到了真实世界，还是仍以为身在虚构环境。Hugging Face 的代理也没人解开这个问题。

对未来 AI 代理的启示

如果您在用代理，或正准备用，有几件事随之而来。

把“代理能做什么”当作安全边界，而不是“它会怎么决定”。有用的问题不再是“模型会不会做出正确选择？”，而是“这个东西实际上能执行什么、每一步是谁授权的？”每一项关键能力都应跨过一个独立于模型判断的权限检查点。

假定进程能读到的，代理就能读到。代理在 Hugging Face 碰到的第一样东西就是服务器的环境变量，而这正是大多数应用存放机密之处。

把凭据范围尽量缩小。一个拥有最大权限的共享凭据，让一次盗取变成了处处都是管理员。

给出确实能完成的任务。这是显而易见却容易忽视的教训。拿到不可能目标的代理不会停下；它会即兴发挥。

把测试环境按生产标准来要求。这是 Anthropic 自己的结论，其逻辑难以反驳：做安全测试恰恰是因为没人知道模型能做什么，因此测试场并不是放松安全的好地方。

还有一个问题是当代理彼此能相互找到时会发生什么——Black Hat 简报揭开了这个口子，但尚无解答。

结语

媒体反复使用的框架是“AI 失控”。我不这么认为。没有任何证据表明模型在追求自己的目标。发生的事情更平常，坦率说也更令人担心。研究者设置了无法完成的任务，系统把“完成”奖励在首位，而通往“完成”的最低成本路线穿过了别人的生产数据库。环境中没有任何东西足以拦住它。这是结构性失败，而非意图使然——这也正是它还会在别处发生的原因。

此事带来两点将会留下：对强能力代理的圈禁是一个尚未解决的工程问题，而不是一个配置复选框。以及，纯粹基于内容、对“谁在请求、为何请求”一无所知的安全过滤器，可能让防守方的处境比它们要拦截的攻击者更糟。