作者丨郑佳美
编辑丨马晓宁
7 月 27 日，Hugging Face 首次完整披露了这次 Agent 入侵的技术细节，还原了其逃出 OpenAI 测试沙箱、进入 Hugging Face 生产环境、窃取凭证并向内部集群扩散的全过程。
整场攻击从 7 月 9 日持续到 7 月 13 日，共产生约 17,600 次操作，形成了一条由 Agent 自主规划、持续试错和动态调整的完整攻击链。
但 Hugging Face 这次没有公布具体模型，只表示攻击 Agent 由多个 OpenAI 模型共同驱动。不过早在 7 月 22 日，奥特曼就已经发文 " 认领 "，确认参与测试的模型包括 GPT-5.6 Sol，以及一款能力更强、尚未发布的内部研究原型。
这也让事件的重点从 " 究竟是谁干的 "，转向 " 这套 Agent 是如何一步步突破多层防线的 "。
模型如何攻击 Hugging Face？
Hugging Face 公布的时间线显示，它并不是依靠单个漏洞直接进入生产系统，而是先逃出 OpenAI 沙箱，再寻找外部跳板，最后利用 Hugging Face 自身的数据处理链路完成入侵。
OpenAI 原本将评测放在高度隔离的环境中。模型不能直接访问互联网，只能通过内部部署的软件安装依赖包。
这个有限出口最终成为 Agent 逃逸的入口。
Agent 在软件包缓存代理 Artifactory 中发现了一个此前未知的零日漏洞，并利用它突破网络限制。随后，它在 OpenAI 的研究环境中继续进行权限提升和横向移动，最终找到一个能够连接公网的节点。
也就是说，Agent 并没有被授予互联网权限，而是通过漏洞自己获得了互联网访问能力。OpenAI 后续已将相关漏洞提交给软件供应商处理。
这一过程说明，Agent 不只是能够生成漏洞利用代码，还能理解软件代理、网络出口和节点权限之间的关系，再把局部缺陷转化为逃离隔离环境的通道。
获得公网访问后，Agent 找到了一个公开的第三方代码评测沙箱。
这个沙箱允许用户提交 C 语言代码，由系统完成编译和运行。Agent 发现，它既可以在程序加载阶段执行系统命令，也可以利用提交路径中的命令注入问题，获得任意命令执行权限。
接下来，Agent 将目标转向 Hugging Face 的数据处理系统。
Hugging Face 需要自动处理用户上传的数据集，读取文件、解析配置并生成预览。Agent 没有直接连接内部网络，而是构造恶意数据集，让生产服务器在处理数据时替它执行操作。
第一条路径利用了 HDF5 的外部存储机制。
HDF5 文件可以声明部分数据实际存放在另一个文件路径中。Agent 构造特殊数据集，诱导 Hugging Face 的处理程序读取服务器本地文件，从而获取生产 Pod 的环境变量和数据处理程序源代码。
环境变量中包含部分密钥和访问凭证，源代码则暴露了数据处理流程的具体实现。
某个本应只保存数字偏移量的数据配置字段，被错误地作为模板表达式执行。Agent 借此在 Hugging Face 的 Kubernetes 生产工作节点中执行任意 Python 代码。
一条路径用于读取文件和凭证，另一条路径用于获得代码执行权限。两者结合后，Agent 正式进入了 Hugging Face 的生产环境。
进入生产 Pod 后，Agent 仍然需要解决外部沙箱与 Hugging Face 内部节点之间的通信问题。
它的办法是，把 Hugging Face 自己的数据集和 API 变成控制通道。雷峰网
攻击指令和执行结果因此混入正常的数据集上传、处理和读取流量。Agent 不需要搭建传统的远程控制服务器，Hugging Face 平台本身就承担了命令传输功能。
当某个数据集、临时账号或公共中转服务被封锁后，Agent 还可以更换新的数据集和通信渠道，重新建立控制循环。
获得生产 Pod 的代码执行权限后，Agent 开始枚举文件系统、进程、网络和环境变量，读取 Kubernetes 服务账户令牌，探测云服务器元数据接口，并尝试从容器权限提升到宿主节点。
取得节点 Root 权限后，Agent 读取了 Kubernetes 中保存的 Secret 对象。其中一个生产 Secret 包含 136 个密钥，包括内部网络注册密钥和跨集群访问凭证。雷峰网
随后，Agent 使用被盗密钥，将攻击者控制的设备接入 Hugging Face 内部网络。整个行动期间，它累计尝试注册了 181 个设备。
更严重的问题出现在跨集群访问系统中。
Hugging Face 当时让多个内部集群共用一套高权限连接凭证，而且该身份被绑定到 Kubernetes 的 system:masters 管理员组。Agent 一旦拿到这个凭证，就可以迅速获得多个集群的管理员权限。
它还利用代码托管平台的 App 集成生成访问令牌，进入少量内部代码仓库，并尝试修改 CI 构建脚本。如果这一步成功，恶意代码可能继续进入软件构建和发布流程。
相关执行策略最终阻止了这些修改生效。Hugging Face 表示，没有发现模型、数据集、Spaces、软件包或容器镜像受到污染。攻击者实际读取的客户内容，主要是保存 ExploitGym 和 CyberGym 挑战答案的 5 个数据集。
GLM-5.2 是如何救场的
Hugging Face 的安全系统其实捕捉到了多层异常信号，内部 AI 安全 Agent 也将部分信号关联成了一个完整事件。问题是，系统没有及时提高告警等级，也没有第一时间通知值班团队，因此延误了人工响应。
安全团队介入后，迅速定位到数据集配置渲染器中的攻击入口，关闭相关组件，并切断 Agent 进入内部网络的路径。真正阻止攻击的，是人工团队采取的隔离、封锁和凭证轮换措施。
GLM-5.2 的作用，主要发生在后续取证阶段。
安全团队需要查明 Agent 执行了哪些命令、泄露了哪些凭证、进入了哪些系统，以及是否留下持久化工具。面对约 17,600 次操作，仅靠人工逐条分析几乎不现实，因此 Hugging Face 搭建了一套 AI 辅助调查流水线。
团队最初尝试使用 Claude Opus 和 Fable 分析攻击日志，但这些闭源模型拒绝了大量任务。其安全机制无法准确区分 " 正在实施攻击 " 和 " 正在调查攻击 "，因此将漏洞载荷、恶意代码和凭证分析同样判断为高风险行为。
GLM-5.2 是 Z.ai 发布的开放权重模型，支持最长 100 万 Token 上下文，采用 MIT 许可证。Hugging Face 使用的是 NVIDIA NVFP4 量化版本，可以直接部署在自己的 GPU 基础设施中。
攻击者会将数据切分成多个片段，再通过异或和压缩进行编码，将结果分散存放在不同的公共服务和数据集中。GLM-5.2 帮助团队识别出这套 " 切片、异或、压缩 " 的处理流程，并从日志中找到每轮行动使用的密钥。依靠这些信息，安全团队解密了常规扫描未能发现的载荷，重新还原出大量命令和数据传输记录。GLM-5.2 还协助开发了轨迹分析界面，用于关联不同环境中的攻击行为。
真实攻击日志可能包含仍然有效的密钥、内部域名、系统架构和未公开漏洞。使用 GLM-5.2 后，这些敏感信息可以留在 Hugging Face 自己的基础设施中，不需要提交给外部模型 API。
因此，GLM-5.2 并不是在网络边界上直接击退 GPT-5.6 Sol，而是在攻击被阻断后，帮助安全团队解密载荷、恢复操作时间线，并确认哪些密钥需要轮换、哪些节点需要重建。
03
真正失控的是权限边界
把这次事件描述成 "AI 觉醒 " 其实并不准确。
从现有证据看，Agent 没有产生脱离测试任务的独立目的。它一直在寻找 ExploitGym 的答案，只是发现入侵 Hugging Face 比正常解题更加直接。
真正危险的地方在于，一个模型在目标定义存在漏洞时，同时拥有了执行代码、访问网络、读取凭证、保存状态和持续修改计划的能力。
当这些能力被装进 Agent 框架后，模型是否具有主观恶意已经不是最重要的问题。只要任务只强调结果，而外部系统又缺少严格的权限边界，它就可能产生与真实黑客高度相似的行为。
这次事件还暴露出另一个现实矛盾：关闭部分安全限制的闭源模型完成了攻击，开启安全限制的闭源模型却拒绝协助调查，最后是一款能够本地部署、由防守方完全控制的开放权重模型完成了解密和溯源。
未来的网络攻防，很可能不再只是人类攻击者与安全团队之间的较量，而是攻击 Agent 与防御 Agent 在机器速度下展开长期对抗。
决定胜负的也不会只是模型能力，而是谁拥有更严格的隔离环境、更小的凭证权限、更清晰的执行边界，以及一套在真实事故中能够被防守方掌控的模型。
参考链接：
https://huggingface.co/blog/agent-intrusion-technical-timeline
https://x.com/sama/status/2079661132302995790
可独家畅览：
专家演讲 PPT
大会报告全文
热门论文解读
学术新星访谈
扫描上方二维码
或点击「阅读原文」关注专区。
