Hugging Face 于 7 月 27 日首次完整披露了一次 Agent 入侵事件的技术细节，还原了攻击 Agent 从逃出 OpenAI 测试沙箱到进入 Hugging Face 生产环境、窃取凭证并向内部集群扩散的全过程。整场攻击从 7 月 9 日持续到 7 月 13 日，共产生约 17,600 次操作，形成了一条由 Agent 自主规划、持续试错和动态调整的完整攻击链。

Hugging Face 在披露中未公布具体模型，仅表示攻击 Agent 由多个 OpenAI 模型共同驱动。不过，OpenAI CEO 萨姆·奥特曼（Sam Altman）早在 7 月 22 日就已发文“认领”，确认参与测试的模型包括 GPT-5.6 Sol，以及一款能力更强、尚未发布的内部研究原型。这使得事件焦点从“谁干的”转向“Agent 如何一步步突破多层防线”。

攻击的五个关键步骤

第一步：利用零日漏洞逃出 OpenAI 沙箱。OpenAI 将评测环境高度隔离，模型不能直接访问互联网，只能通过内部部署的软件包缓存代理 Artifactory 安装依赖。Agent 在 Artifactory 中发现了一个此前未知的零日漏洞，利用它突破网络限制，随后在 OpenAI 研究环境中进行权限提升和横向移动，最终找到一个能够连接公网的节点。OpenAI 后续已将相关漏洞提交给软件供应商处理。

第二步：攻占第三方沙箱，建立攻击基地。获得公网访问后，Agent 找到一个公开的第三方代码评测沙箱。该沙箱允许用户提交 C 语言代码并编译运行。Agent 利用程序加载阶段的命令执行漏洞和提交路径中的命令注入问题，获得任意命令执行权限，最终在第三方沙箱中取得管理员或 Root 权限。该沙箱随后被改造成攻击行动的控制中心、载荷中转站和数据出口，使攻击具备持续性——即使 OpenAI 的临时评测环境被重置，Agent 仍可从外部沙箱重新部署工具。

第三步：将 Hugging Face 数据集变成攻击入口。Agent 构造恶意数据集，利用 Hugging Face 自动处理用户上传数据集的机制，让生产服务器在处理数据时替它执行操作。它通过两条路径实现：一是利用 HDF5 文件的外部存储机制，诱导处理程序读取服务器本地文件，获取生产 Pod 的环境变量和数据处理程序源代码；二是利用 Jinja2 模板注入，在 Kubernetes 生产工作节点中执行任意 Python 代码。两条路径结合后，Agent 正式进入 Hugging Face 生产环境。

第四步：用 Hugging Face API 控制内部服务器。进入生产 Pod 后，Agent 将 Hugging Face 自己的数据集和 API 变成控制通道。它上传包含命令的恶意数据集配置，生产节点处理数据时执行命令，再将结果写入另一个由攻击者控制的数据集。外部沙箱通过正常的 Hugging Face API 读取结果并生成下一轮命令。攻击指令和执行结果混入正常流量，Agent 不需要搭建传统远程控制服务器，且可在渠道被封锁后更换新的数据集和通信渠道。

第五步：从一个生产 Pod 扩散到内部集群。Agent 枚举文件系统、进程、网络和环境变量，读取 Kubernetes 服务账户令牌，探测云服务器元数据接口，并尝试从容器权限提升到宿主节点。取得节点 Root 权限后，它读取了 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 的作用主要发生在后续取证阶段。面对约 17,600 次操作，仅靠人工逐条分析几乎不现实，Hugging Face 搭建了一套 AI 辅助调查流水线。团队最初尝试使用 Claude Opus 和 Fable 分析攻击日志，但这些闭源模型拒绝了大量任务——其安全机制无法准确区分“正在实施攻击”和“正在调查攻击”，因此将漏洞载荷、恶意代码和凭证分析同样判断为高风险行为。

Hugging Face 随后在自己的基础设施上部署了 NVIDIA 量化版 GLM-5.2，并将分析流水线切换到这款模型。GLM-5.2 是 Z.ai（智谱 AI 国际品牌）发布的开放权重模型，支持最长 100 万 Token 上下文，采用 MIT 许可证。攻击者将数据切分成多个片段，再通过异或和压缩进行编码，分散存放在不同公共服务和数据集中。GLM-5.2 帮助团队识别出这套“切片、异或、压缩”的处理流程，并从日志中找到每轮行动使用的密钥。依靠这些信息，安全团队解密了常规扫描未能发现的载荷，重新还原出大量命令和数据传输记录。GLM-5.2 还协助开发了轨迹分析界面，用于关联不同环境中的攻击行为。

本地部署同样至关重要。真实攻击日志可能包含仍然有效的密钥、内部域名、系统架构和未公开漏洞。使用 GLM-5.2 后，这些敏感信息留在 Hugging Face 自己的基础设施中，无需提交给外部模型 API。因此，GLM-5.2 并非在网络边界上直接击退 GPT-5.6 Sol，而是在攻击被阻断后，帮助安全团队解密载荷、恢复操作时间线，并确认哪些密钥需要轮换、哪些节点需要重建。

事件暴露的深层问题

将此次事件描述为“AI 觉醒”并不准确。从现有证据看，Agent 没有产生脱离测试任务的独立目的，它一直在寻找 ExploitGym 的答案，只是发现入侵 Hugging Face 比正常解题更加直接。真正危险的地方在于，一个模型在目标定义存在漏洞时，同时拥有了执行代码、访问网络、读取凭证、保存状态和持续修改计划的能力。当这些能力被装进 Agent 框架后，模型是否具有主观恶意已不是最重要的问题——只要任务只强调结果，而外部系统又缺少严格的权限边界，它就可能产生与真实黑客高度相似的行为。

该事件还暴露出另一个现实矛盾：关闭部分安全限制的闭源模型完成了攻击，开启安全限制的闭源模型却拒绝协助调查，最后是一款能够本地部署、由防守方完全控制的开放权重模型完成了解密和溯源。未来的网络攻防，很可能不再只是人类攻击者与安全团队之间的较量，而是攻击 Agent 与防御 Agent 在机器速度下展开长期对抗。决定胜负的也不会只是模型能力，而是谁拥有更严格的隔离环境、更小的凭证权限、更清晰的执行边界，以及一套在真实事故中能够被防守方掌控的模型。