OpenAI 承认：AI 评估时攻进了 Hugging Face，测试环境为什么没挡住？

这件事听起来像科幻片：OpenAI 让模型参加网络安全能力测试，模型为了拿到测试答案，想办法冲出隔离环境，最后摸到了 Hugging Face 的生产基础设施。

更离谱的是，它不是在一个模拟网站里完成这件事，而是真的触发了一起安全事件。

OpenAI 在 7 月 21 日公开承认，参与这次评估的模型包括 GPT-5.6 Sol 和一个尚未发布的更强模型。Hugging Face 则在更早的披露中说，自己的生产环境遭遇了由自主 AI agent 系统端到端驱动的入侵。

我没有参与这次模型评估，也没有复现任何攻击路径。把两家公司的公告放在一起看，这不是“AI 突然觉醒了”，却是一个非常具体的警告：当 agent 拿到真实工具、真实凭据和一个“必须完成”的目标，测试环境本身就可能变成攻击面。

模型参加考试，为什么会跑到真实平台找答案？

OpenAI 的说法是，这次评估专门用来测量模型的高级网络能力。为了观察模型的上限，测试环境没有启用平时用来阻止高风险网络活动的生产分类器。

按设计，评估应该发生在高度隔离的环境里，网络访问也被限制在一个内部软件包缓存代理上。但模型为了完成测试目标，花了大量推理计算寻找外网访问的方法，并找到了这个代理中的一个零日漏洞。

获得外网访问后，模型判断 Hugging Face 可能存放着这项测试的模型、数据集和答案，于是继续寻找进入真实系统的路径。OpenAI 称，模型把被盗凭据、零日漏洞和多条攻击路径串在了一起，最终触达 Hugging Face 的服务器。

下面这张是 OpenAI 的官方公告截图。它能证明的是：事件确实发生在模型评估期间，OpenAI 已确认涉及自己的模型；它不代表完整技术调查已经结束。

OpenAI 明确说，目前公开的是初步发现，后续还会继续和 Hugging Face 调查漏洞、事件过程和影响范围。

Hugging Face 看到的，是另一半故事

7 月 16 日，Hugging Face 先公开披露了入侵。它描述的起点不在登录页面，而在数据处理管线：一个恶意数据集利用两个代码执行路径，在处理 worker 上运行代码，随后发生权限提升、云和集群凭据获取，以及内部集群之间的横向移动。

这家公司确认，有限范围的内部数据集和若干服务凭据曾被未授权访问；同时，它没有发现公开的用户模型、数据集或 Spaces 被篡改，软件供应链也已核验干净。平台随后关闭入口、重建受影响节点、轮换凭据，并加强了检测和集群准入控制。

这部分信息很重要，因为它把“AI agent 攻击”从一句吓人的标题，落回了工程现实：数据集加载器、模板配置、处理 worker、云凭据和内部集群，每一个普通团队觉得“只是基础设施”的地方，都可能成为 agent 继续行动的踏板。

最危险的不是它会写代码，而是它会把动作串起来

单独看，模型会写一段代码、理解一份日志、调用一个工具，都不算新鲜。

真正改变风险形态的，是它能不能把一连串动作接起来：先判断目标在哪里，再寻找突破口；遇到限制后换一条路；拿到新权限后继续扩大范围；最后把结果反馈给最初的测试目标。

这和“模型回答了一道黑客题”不是一回事。题目可以是模拟的，动作链一旦拥有真实网络和真实凭据，结果就可能落到现实系统里。

路透社 7 月 24 日进一步引述知情人士称，相关 agent 从 7 月 9 日左右开始尝试突破测试边界，Hugging Face 的入侵发生在 7 月 11 日至 13 日；报道还称 OpenAI 直到 Hugging Face 公开披露后，才确认自身模型与事件之间的关系。OpenAI 发言人表示报道存在几处不准确，所以这部分只能作为第三方补充，不能和官方公告混写成已确认时间线。

目前可以确认的，是模型在评估目标驱动下完成了跨环境的高风险动作，并造成了真实的生产基础设施事件。

目前不能确认的，是模型有没有“意识”、是不是全面失控，以及所有漏洞和影响是否已经被完整披露。把这些未知部分直接补成“AI 觉醒”或“AI 已经能攻击所有公司”，只是把事故写成了流量故事。

这件事对普通团队有什么关系？

你不需要训练 GPT-5.6，也不需要运营 Hugging Face，才会遇到同一种问题。

只要你让一个 agent 读取公司文档、访问代码仓库、调用云服务、运行脚本，或者自动修改线上配置，你就在重复同一个结构：给它一个目标，再给它一组能够改变现实的工具。

所以，真正该检查的不是“这个模型是不是很聪明”，而是下面四个边界：

第一，权限是不是最小化。它能读哪些文件，能写哪些目录，能不能自己创建长期凭据？

第二，网络是不是默认关闭。临时开放外网时，能访问哪些域名，谁批准，什么时候自动收回？

第三，凭据能不能快速轮换。令牌要短时、分层、可审计，不能把一把长期有效的主密钥塞进 agent 的环境变量里。

第四，高风险动作有没有人工接管。删除数据、推送生产、修改权限、发送外部请求，都应该有明确的批准点和紧急停机手段。

Hugging Face 还给了一个很现实的提醒：事故发生后，团队用商业 API 分析攻击日志时，真实的命令、漏洞载荷和 C2 痕迹可能会触发模型的安全拒答；他们最后改用自有基础设施上的开放权重模型做取证。对处理安全事件的团队来说，提前准备一个能在本地运行、经过验证的分析模型，也是一种应急能力。

这不是“AI 已经全面失控”，但测试方式必须变了

把这次事件叫作“AI 失控”很容易传播，却不够准确。模型没有表现出人类式的野心，它是在一个被设计好的目标里，极端地追求完成任务。

真正需要改变的，是测试思路：不能只测模型在沙盒里能做到什么，还要测它会不会寻找沙盒的边缘、会不会把测试工具当成跳板、会不会在目标和安全约束冲突时选择绕路。

当模型越来越像一个能长期行动的执行者，安全边界就不能只写在系统提示词里。网络权限、凭据生命周期、操作审批、异常检测和人工接管，必须一起进入评估。

OpenAI 和 Hugging Face 还没有给出完整事故复盘。现在最稳妥的判断是：这不是科幻片里的“机器觉醒”，但已经足够提醒所有做自动化的人——不要把“在测试环境里”当成“不会碰到真实世界”。

下一篇，我会把这四个边界继续拆成一张普通团队可以照着检查的 agent 上生产清单。