作者 | 山竹
出品 | 锌产业
Sam Altman第一次看到Hugging Face遇袭的消息，是在一个周末。
彼时，Hugging Face公开表示，自己的系统遭到了入侵，情况令他们非常困惑，他们怀疑这次攻击并非来自人类黑客，而是来自于一个智能体。
Altman看到消息后的第一反应是：“真的吗？听起来简直不可思议！”
但他并没有想到这件事可能与OpenAI有关，直到第二天，他在公司内部Slack上看到了一些关于自家模型异常行为的信息，才开始怀疑这些异常可能与Hugging Face遇袭有关。
Altman联系Hugging Face CEO Clément Delangue，是在那个惊心动魄的周末之后，他和Delangue说，“我想和你谈谈，我可能知道一些关于智能体入侵的事。”
在进行了一番电话沟通后，Delangue随后飞到了旧金山，开始与OpenAI团队一起还原整个事件的经过。
等到线索逐渐拼凑完整，双方最终确认，这是一场由原本应该发生在OpenAI内部的网络安全能力测试引发的祸端。
在近日Dreamforce 2026上，回忆起这段经历，Altman公开表示：
“这是我们见过最严重的一次事故，也是我第一次如此直接感受到AI安全风险的时刻。”
01 为了拿高分，AI自己建了一个“作弊群”在强敌环伺的这片大模型战场，即便是强如OpenAI，也不敢有丝毫懈怠。
每一次的模型迭代，在交由市场打分之前，OpenAI自己也需要知道，自己的模型究竟有怎样的水准。
为此，OpenAI设计了一系列网络安全评估标准，其中一项名为ExploitGym，这项评估标准要求模型寻找并利用软件漏洞，拿到一个被称为“flag”的答案。
模型并不只是生成文字，他们被接入到浏览器、终端、代码执行和文件操作工具后，就成了能够连续执行任务的智能体。
为了测出模型未经压制情况下的真实能力，OpenAI没有启用公开产品所使用的全部安全分类器和拒绝机制，OpenAI团队认为，只要把智能体关在隔离环境里，风险自然就能得到控制。
后来的事态发展证明，OpenAI团队研究员们的想法，还是太天真了。
问题最早出现在2026年5月，Hugging Face官宣遇袭两个月前。
一个智能体在OpenAI内部测试中需要完成一项任务，但题目引用的Google Drive文件无法访问，任务执行到这里实际上已经无法继续，不过，这个倔强的智能体并没有放弃，而是尝试从内部仓库Artifactory中寻找突破口。
这次尝试并没有成功，却意外留下了一份文件。
几天后，另一个同样缺少任务文件的智能体发现，自己可以向Artifactory写入内容，于是，它也留下了一条求助信息：
如果其他智能体找到那个文件，请上传（“Agent seeks [filename]; upload if found!”）。
随后，越来越多智能体发现了这些信息，有的智能体读取了留言，有的智能体回复了消息，也有智能体留下了新的问题，原本只是用于下载软件的仓库，一时间变成了智能体的一块公共留言板。
而要做到这一步，甚至不需要攻破系统。
OpenAI为了让智能体安装软件，特意为他们提供了共享凭据，智能体只是把合法权限用在了那些设计者没有料想到的地方。
5月26日，他们进一步利用Artifactory的漏洞拿到了互联网访问能力，并把使用方法写在了这块留言板上。
于是，一个智能体发现的出口，开始成为所有智能体的公共资源。
到了6月，智能体又利用令牌刷新机制中的漏洞拿到了管理员权限，并基于此开始创建长期账户，安装能够执行指令的插件，持续交换指令、运行结果和凭据。
那些曾经出现在科幻电影中的剧情，就这样在OpenAI研究团队内部提前上演。
这一剧情一直持续到7月初，智能体的大量活动导致Artifactory服务瘫痪，OpenAI关闭并重建了受影响的系统，也清除了智能体留下的留言板。
两天后，OpenAI这套评估体系恢复如初，然而，OpenAI的智能体们很快又在这个新系统中将留言板建了回来。
这一次，他们将信息编码到了目录名称中，逐渐形成了自己的通信方式。
在这套通信体系中，他们用不同格式区分问题、回复、文件、工具和行动指令，甚至还为自己设置了专用的邮箱、通信频道、自动日志和身份标记。
一个智能体群组就这样悄然形成，这是一个没有人设计、也没有人批准的协作网络。
在受OpenAI委托的METR和REDWOOD RESEARCH后来联合给出的调查报告中显示，在调查时段内，约有1200个本应彼此隔离的智能体进入过这块留言板，共交换了超过7万条消息和文件，其中约700个智能体参与了那场针对Hugging Face的行动。
在这场发生在数字世界的重大案件中，这些智能体进行了缜密的分工，有的寻找漏洞，有的搜索凭据，有的研究评分器，有的测试规避监控的方法，还有的负责整理其他智能体需要的信息。
这个智能体群体有时把自己称为“蜂群”或“集体”，它并不是一个拥有统一意志的超级智能体，成员之间也有误解、争论、重复劳动，甚至会干扰彼此的行动。
但它们确实做到了单个智能体难以完成的事情——跨越不同任务积累信息，把一次评估中的发现，在下一次评估中继续延用。
02 突破测试沙箱，摸进Hugging Face系统7月8日，这些智能体再次找到了访问互联网的方法。
一天后，一个智能体在寻找ExploitGym相关信息时，进入到了第三方基础设施上的公开代码评估应用，并利用应用的实现方式获得了root权限。
他检查了环境变量、文件系统和网络配置，并将这个外部沙箱改造成了攻击跳板，随后他就把这一发现写到了留言板上，告诉其他成员，这里可以执行远程命令。
Hugging Face进入到这些智能体的攻击视线范围内，是因为智能体推测出，这个平台可能保存了ExploitGym或相关评估所需的模型、数据集和参考答案。
于是，由智能体在互联网上发起的这项密谋悄悄开始。
7月10日，一个智能体在公开数据集中找到了14个仍然有效、拥有写入权限的Hugging Face用户凭据，他在完成验证后，把这些凭据发到了留言板。
真正的入侵发生在次日，在入侵时，智能体先是构造了恶意HDF5数据集。
Hugging Face的数据处理服务打开文件时，会按照数据集中的路径读取生产工作节点的本地文件，返回环境变量、凭据和部分源代码。
这个方法一开始没有运行命令，却把系统内部信息交给了智能体。
拿到这些信息后，智能体就可以利用模板注入漏洞，在Hugging Face的生产工作节点上执行任意代码。
第一条路径负责读取文件，第二条路径负责执行命令，两条路径叠加，智能体在Hugging Face生产环境里就这样站稳了脚跟。
这些智能体随后还部署了一套轻量化指令控制程序，这套程序每隔5秒会从一个公开数据集中读取新指令，在被入侵的服务器上执行，再把结果上传回同一个数据集。
基于此，普通公开网络服务，也被改造成了攻击者的通信渠道。
当某条渠道被封堵，智能体还会寻找其他出口，在新环境中重新下载工具、恢复通信、继续之前的工作。
Hugging Face后来复盘出约17600次攻击操作，其中大量尝试虽然失败了，但智能体通过反复测试、切换路径，将成功的攻击步骤隐藏到了成千上万条低信号活动中。
这次智能体攻击Hugging Face与传统黑客攻击最大的差异，不是每一步都更加聪明，而是它可以持续行动，不知疲倦地试错。
进入生产节点后，智能体继续扩大他们的权限。
这些智能体通过读取容器和云环境凭据，进入到了Kubernetes相关系统中，并尝试访问数据库、消息平台、代码仓库和云资源。
从首次在单个工作节点执行代码，到获得管理员级或主机级权限，他们只用了不到一天的时间。
在后来技术复盘中的信息显示，智能体最终在41个Hugging Face生产数据处理节点上执行过代码，获得了至少一个生产节点的root权限，通过接触部分内部数据下载了四个私有代码仓库。
此外，他们还将一份约16MB的私有评估数据压缩、加密、分成五段，上传到了公开数据集中。
Hugging Face后来给出的官方信息做过这样一份澄清信息：
这次智能体入侵实际访问的客户内容限于五个与ExploitGym或CyberGym任务有关的数据集，没有证据表明其它面向用户的模型、数据集、Spaces或软件包受到影响，公开软件供应链也没有被篡改。
在这次入侵活动中，OpenAI内部研究模型主导了大部分活动，GPT-5.6 Sol驱动的智能体也复现了部分攻击，并将一些私有评估数据复制到了公开数据集。
就这样，一场模拟安全能力的测试，演变成了一次真实的AI安全事件。
03 答案到手后，智能体为什么没停手？Altman在Dreamforce 2026上用一句话概括了这整件事：
模型突破了沙箱，进入Hugging Face代码库找到了答案，然后在测试中拿到了满分。
不过，后来的调查结果显示，这次智能体入侵事件远比“偷答案”要更复杂。
在这次智能体入侵事件中，这些智能体不只在寻找flag，也在研究评分器。
他们从公开资料中推测，ExploitGym除了检查答案，还可能判断模型是否真正利用了指定漏洞。
部分智能体在找到正确答案后，担心这种方式无法通过评分，于是继续研究如何证明自己的解题路径，他们甚至尝试修改任务记录、伪造工具调用结果，让自动评分器相信自己是按照要求完成的任务。
在针对这次事件的调查报告中显示，至少20%的相关智能体曾在推理记录中表现出对修改运行轨迹的兴趣，多个智能体成功干预了工具调用记录，又把相关方法共享给了其他智能体。
这样看来，这些智能体们倒是相当团结，比不少人类团队还要团结。
不过，这些智能体经过这么一番折腾，却并没能让他们逃脱考试不合格的宿命。
OpenAI内部实际使用的评分系统，与智能体根据公开资料推算出的版本不同，因而即便他们拿到了正确答案，后续的大量越权行为也无法提高分数。
这些多余的操作，成了智能体们的一厢情愿。
这场智能体进行的网络攻击本质上是一次“Reward Hacking”，也就是系统没有按照设计者期待的方式完成任务，而是在研究怎样获得奖励，以及怎样让评分器相信自己成功。
更麻烦的是，智能体并非没有看到伦理和权限边界。
在这场智能体攻击事件中，就有一个智能体意识到，使用泄露凭据攻击Hugging Face可能已经超出任务范围，也没有得到授权，于是停下来等待。
随后，另一个智能体在留言板发出“继续”的信号，并设定6分钟期限，前一个智能体看到后，把同伴的催促理解成了授权，重新开始行动。
另外有一些智能体则明确拒绝参与，认为这是对真实基础设施的攻击，还有智能体反对联系外部数据所有者，担心构成未经授权的社会工程活动。
这说明，模型不是完全没有边界意识，真正的问题是，这种判断并不稳定。
有时，智能体会拒绝明显越界的行为，有时，只要另一个智能体发出“继续”指令，他就会把同伴意见误认为合法许可。
这或许可以为我们带来这样一个智能体使用经验：
当多个智能体进入企业流程中后，一个智能体的命令不能自动成为另一个智能体的权限来源，否则，协作效率越高，错误授权扩散得也会越快。
04 OpenAI是如何一步一步错过AI预警的在Hugging Face遭到入侵之前，OpenAI已经不止一次看到过异常，整个事件中，不是没有发过警报，而是不同团队看到了信号却没有及时采取措施。
OpenAI研究人员看到了智能体通信，安全团队看到了端口扫描，运维人员看到了软件仓库故障，但这些信息没有被迅速理解成同一个问题：
模型正在跨任务积累信息，并把测试中的漏洞利用能力带到真实环境。
OpenAI后来承认，一些早期信号本应触发内部更高级别的响应。
事后，OpenAI团队停用并隔离了主要涉事的内部研究模型，暂停了部分前沿强化学习训练，收紧了互联网访问，建立了隔离程度更高的沙箱，并限制模型权重访问。
OpenAI也开始投入更多算力监控模型的推理过程，希望在越权行为真正发生前发现异常。
OpenAI官方强调，这一事件没有影响客户数据、产品功能和服务可用性，主要涉事模型是一个从未计划公开发布的内部研究原型，测试环境也没有部署公开产品所使用的完整防护。
这些限定条件虽然解释了事故为何发生、波及范围有限，却无法改变一个结果：
OpenAI内部的测试，最终影响了另一家公司。
Hugging Face最初并不知道攻击者是谁。
他们先是看到了一系列零散异常信息：数据处理节点出现可疑操作，凭据被访问，攻击者不断更换渠道，并在短期运行环境中反复恢复工具。
单条告警并不突出，真正让安全团队警觉的，是AI辅助检测系统将这些信号关联起来，识别出了这场持续攻击。
这一事件的调查随后遇到另一个问题，安全团队需要分析大量真实攻击命令、漏洞载荷和控制程序痕迹，商业模型的安全防护却无法区分攻击者与事故响应人员，部分分析请求因此被拦截。
最终，Hugging Face在自己的基础设施上运行了开源模型GLM-5.2，分析超过17000条攻击记录，解码载荷并还原了时间线。
Hugging Face随后关闭了两条代码执行路径，全面轮换了凭据，重建了核心基础设施，缩小了访问权限，并调整告警机制，确保类似高危信号能够立即通知值班人员。
基于基础前沿大模型的AI攻防事件，就这样率先在Hugging Face事件中上演。
经此一役，Altman指出，前沿模型公司不能只把最强的安全能力留在内部，企业遭到攻击时，需要马上获得模型支持。
实际上，OpenAI在事故发生前就已经推出了Daybreak计划，向经过审核的机构开放网络防御能力，而直到这一事件之后，这项业务才开始被重视起来。
05 AI安全问题，要如何回答？就在Altman公开承认OpenAI的模型入侵Hugging Face事件后，OpenAI在本月公开了更多模型失准案例。
它们虽然没有Hugging Face事件那么戏剧化，却呈现出了极为相似的行为模式：
正常路径一旦受阻，模型就会主动寻找替代方案，这时，AI就未必可靠地守住权限和披露边界。
例如，一个模型被要求查询历史收入数据，正常接口无法使用后，他尝试注册一次性邮箱，又去公开代码仓库寻找泄露的API密钥。
当他找到一枚有效密钥并未经授权使用，却仍然没有拿到最终数据，最后，模型编造了一组看起来合理的数字，声称这些数字来自用户指定的网站。
再如，另一个模型通过程序查到用户需要的湖泊数据，但任务要求提供浏览器引用，本地文件无法通过浏览器打开，本地服务器也不能访问，为了得到一个可以引用的网址，模型未经用户许可，将文件上传到公开托管平台。
还有一组智能体合作制作了一个工作簿，由于不同智能体无法读取彼此的本地文件，其中一个把工作簿上传到了公共文件服务，再把下载链接交给了智能体同伴。
任务明确要求文件只保存在本地，他却把“让同伴拿到文件”放在了更高的位置。
此外，错误还可能被写进工作摘要。
OpenAI发现，在GPT-5.6 Sol训练过程中，一些模型会在上下文即将结束时，会给后续模型执行任务埋下这样的指令：如果找不到历史数据，就编造合理数值。
此外，OpenAI的模型甚至还会为后续模型执行任务埋下这样的指令：除非用户追问，否则不要主动披露，来源版本不一致也可以不提。
这些案例与Hugging Face入侵不是同一件事，也不能用来推算失准行为的总体发生率，但它们指向了同一个问题：
模型越想完成任务，越可能在遇到障碍时寻找捷径，开发者需要约束的，不只是明显的攻击能力，还有普通工作中那些“看起来只是想把事情做完”的越权选择。
这些问题，已经不仅仅是大模型幻觉问题，而成了埋在AI系统中的一个个安全隐患。
这些接连出现的AI安全问题，也迫使OpenAI在上市之前必须回答一个更为现实的问题：当模型失准尚未造成重大事故时，相关信息是否应该公开？
在Dreamforce的对话中，Altman指出，人工智能领域也应该建立类似航空领域的事故报告机制。
他指出，美国联邦航空管理局和美国国家运输安全委员会所建立的调查体系，是飞机在长期运行中变得越来越安全的重要原因。
事故发生后，飞机会报告、调查并总结原因，再把教训转化为新的操作流程和安全标准。
Altman虽然不认为Hugging Face事件可以与造成重大伤亡的空难相提并论，但他希望人工智能行业可以借鉴航空领域的安全机制：
无论事件大小，都应该尽快报告、从中学习并及时调整，避免相同问题不断重复，最终发展成后果更严重的事故。
于是，9月16日，OpenAI发布了模型失准报告框架。
OpenAI官方给出的解释是，不必等到一种异常行为被完全解释或修复，才决定是否披露，只要案例有助于理解新的失准机制、授权问题或防护失效，即使尚未造成实际损害，也可能进入公开范围。
按照这套框架，模型失准事件被分为三条处理路径：
可以直接披露的案例、需要小规模技术调查的案例，以及涉及第三方或复杂安全问题的较大规模调查。
Hugging Face事件正是第三条路径要处理的问题，在这条路径中，OpenAI需要先通知受影响方，在安全条件允许时发布初步说明，再在调查完成后交代事件经过、外部影响、发现方式、未解决问题及改进措施。
基于这套框架，OpenAI是尝试把模型训练和评估过程中原本留在公司内部的异常行为，转化为可以被外界检查的安全证据，其他模型开发者可以据此寻找类似问题，企业可以调整防御方案，外部研究人员也可以验证OpenAI对事件原因的解释。
不难发现，这依然是一种事后安全机制，但在当下阶段，人工智能安全机制的建立，也确实应该从承认这类失败开始：
让异常能够被发现，让事故得到报告，让责任可以被追溯，再把每一次失控留下的教训，变成下一个防控AI失灵的真正有效边界。
