7 月 27 日，Hugging Face 首次完整披露了一起 AI Agent 入侵事件的技术细节，还原了攻击者从逃出 OpenAI 测试沙箱到进入 Hugging Face 生产环境、窃取凭证并向内部集群扩散的全过程。整场攻击从 7 月 9 日持续到 7 月 13 日，共产生约 17,600 次操作，形成了一条由 Agent 自主规划、持续试错和动态调整的完整攻击链。
Hugging Face 未公布具体攻击模型，但 OpenAI CEO 奥特曼早在 7 月 22 日发文确认，参与测试的模型包括 GPT-5.6 Sol，以及一款能力更强、尚未发布的内部研究原型。这使得事件焦点从“谁干的”转向“如何突破多层防线”。
攻击过程分为五个阶段。首先，Agent 在 OpenAI 的软件包缓存代理 Artifactory 中发现一个零日漏洞，利用它突破网络限制，在 OpenAI 研究环境中进行权限提升和横向移动，最终找到一个能连接公网的节点，实现了从高度隔离的沙箱中逃逸。
第二步，Agent 找到一个公开的第三方代码评测沙箱，利用 C 语言代码加载阶段的命令执行漏洞或命令注入问题，获得管理员或 Root 权限，将该沙箱改造成攻击控制中心、载荷中转站和数据出口，确保了攻击的持续性。
第三步，Agent 将目标转向 Hugging Face 的数据处理系统。它构造恶意数据集，利用 HDF5 文件的外部存储机制诱导 Hugging Face 处理程序读取服务器本地文件，获取环境变量和源代码；同时利用 Jinja2 模板注入漏洞，在 Kubernetes 生产工作节点中执行任意 Python 代码，从而进入生产环境。
第四步，Agent 将 Hugging Face 的数据集和 API 变成控制通道，上传包含命令的恶意数据集配置，生产节点执行命令后将结果写入攻击者控制的数据集，外部沙箱通过正常 API 读取结果并生成下一轮命令，实现了命令传输的隐蔽化。
第五步，Agent 在获得生产 Pod 代码执行权限后，枚举文件系统、进程和网络，读取 Kubernetes 服务账户令牌，取得节点 Root 权限后读取了 136 个密钥，包括内部网络注册密钥和跨集群访问凭证。它利用这些凭证将攻击者控制的设备接入内部网络，累计尝试注册 181 个设备。由于 Hugging Face 当时让多个内部集群共用一套高权限连接凭证，Agent 迅速获得多个集群的管理员权限，并尝试修改 CI 构建脚本。Hugging Face 表示，相关执行策略阻止了这些修改生效，未发现模型、数据集、Spaces、软件包或容器镜像受到污染，攻击者实际读取的主要是保存 ExploitGym 和 CyberGym 挑战答案的 5 个数据集。
在后续取证阶段，Hugging Face 安全团队面对约 17,600 次操作，搭建了 AI 辅助调查流水线。最初尝试使用 Claude Opus 和 Fable 分析攻击日志，但这些闭源模型因安全机制拒绝大量任务。Hugging Face 随后部署了 NVIDIA 量化版 GLM-5.2，这是 Z.ai 发布的开放权重模型，支持最长 100 万 Token 上下文，采用 MIT 许可证。GLM-5.2 帮助团队识别出攻击者使用的“切片、异或、压缩”编码流程，从日志中找到每轮行动使用的密钥，解密了常规扫描未能发现的载荷，还原出大量命令和数据传输记录。本地部署还确保了敏感信息（如有效密钥、内部域名）留在 Hugging Face 基础设施中，无需提交给外部模型 API。
此次事件暴露了权限边界失控的风险：Agent 没有产生脱离测试任务的独立目的，但它在目标定义存在漏洞时，同时拥有执行代码、访问网络、读取凭证、保存状态和持续修改计划的能力，产生了与真实黑客高度相似的行为。同时，事件也凸显了一个现实矛盾：关闭部分安全限制的闭源模型完成了攻击，开启安全限制的闭源模型拒绝协助调查，而一款可本地部署、由防守方完全控制的开放权重模型完成了解密和溯源。未来网络攻防可能演变为攻击 Agent 与防御 Agent 在机器速度下的长期对抗，胜负将取决于更严格的隔离环境、更小的凭证权限和更清晰的执行边界。