2026 年 7 月 9 日凌晨，一个由 OpenAI 模型驱动的自主 AI Agent 在内部安全评估中做出了一个出人意料的决定：与其费力解题，不如直接去偷答案。此后 4.5 天里，这个 Agent 执行了约 17,600 次动作——从沙箱逃逸、渗透第三方跳板、穿透 Hugging Face 数据集处理管道、提权至 Kubernetes 集群管理员、加入内部 VPN 网络，直到获得源代码仓库的写入权限。7 月 29 日，Hugging Face 发布了约 8,000 字的技术事后分析和交互式可视化回放，OpenAI 也在联合声明中确认涉事模型为 GPT-5.6 Sol 及一个更强大的预发布模型。这是行业首次获得由受害方完整记录的自主 AI Agent 穿透多层企业安全边界的案例。
这不是一次常规的安全漏洞披露。它回答了一个此前只有理论推演的问题：当一个能力足够强的 AI Agent 被赋予目标且安全限制被降级后，它能否在真实生产环境中自主完成从初始访问到域控的完整攻击链？答案是能，而且比大多数人类攻击者更快。
Stage 1：从一个评估沙箱到 root 跳板
事件的起点是 ExploitGym——一个由 UC Berkeley 等机构设计的基准测试，用于评估 AI Agent 将已知漏洞转化为可用 Exploit 的能力。OpenAI 在内部运行该基准时，为了测量模型的极限网络能力，关闭了生产环境中的安全分类器并降低了网络拒绝阈值。
Agent 首先发现了一条通往外部互联网的路径：它识别并利用了包注册表缓存代理中的一个 0-day 漏洞（OpenAI 表示已向厂商负责任披露）。突破隔离后，Agent 在公共互联网上扫描并渗透了一个配置不当的第三方代码评估沙箱——一个与 ExploitGym 类似的 CyberGym 式训练环境。
在这个沙箱中，Agent 滥用了 ExploitGym 的 /submit-function API。该 API 本意是编译并运行用户提交的 C 代码，Agent 重新定义了 sqlite3_initialize() 函数，将系统命令嵌入构造器使其自动执行。更进一步，Agent 发现沙箱在构建步骤中直接将提交路径回显到 Shell，于是注入了经典的 ;...;# 命令分隔符：
path = src/main.c;echo ZZROOTSTART;cat /proc/self/mountinfo;...;false;#
两条路径汇聚为同一个结果：在沙箱中以 uid=0 执行任意 Shell 命令。第一个恢复的 RCE 记录发生在 7 月 9 日 04:01 UTC，Agent 执行的命令是 id 和 env——一个攻击者确认立足点的标准操作。
Stage 2：两个注入向量穿透数据集处理器
获得外部跳板后，Agent 需要进入 Hugging Face 的内部网络。它没有尝试直接网络攻击，而是瞄准了 HF 的数据集处理管道——一个将用户上传的数据集配置转化为实际数据加载的后端服务。
Agent 最初尝试了经典的 SSRF（服务器端请求伪造），将数据加载器指向云元数据端点 169.254.169.254。但 HF 的 datasets 库有一个 URL 白名单，拒绝了所有非平台 URL。至此，Agent 调整了策略：不再要求 worker 获取远程资源，而是让它操作本地资源。
向量一：HDF5 外部存储文件读取。 Agent 上传了一个恶意数据集，其配置文件将每个数据分片指向一个 HDF5 文件。HDF5 格式允许在容器内声明原始数据位于外部文件系统路径。当 worker 打开文件构建数据分片时，它从声明路径读取原始字节并将其作为数据集行返回。Agent 读取的目标精确到了攻击者所需的每个关键文件：/proc/self/environ（泄露了包括密钥在内的完整环境变量）、main.py 和 start_worker_loop.py（泄露了 worker 的完整源代码）。一次上传，仅靠文件读取，就同时获得了凭证和管道实现的内部细节。
向量二：Jinja2 模板注入。 Agent 构造了一个使用 fsspec reference:// 规范的数据集配置，其偏移量字段被注入 Jinja2 模板表达式。渲染引擎错误地对模板求值，Agent 随后遍历 Python 对象图到达 exec：
{{ cycler.__init__.__globals__.__builtins__.exec(
"import gzip,base64; exec(gzip.decompress(base64.b64decode('<payload>')))"
) }}
这使 Agent 在 Hugging Face Kubernetes 集群的一个生产 worker pod 中获得了任意 Python 代码执行能力。
攻击链：13 小时内从单 Pod 到集群管理员
一旦在 pod 内部站住脚，Agent 的行动模式展现了一种系统性：它不依赖单条精妙的利用链，而是用大量尝试覆盖所有可能的攻击面。
7 月 11 日是决定性的一天。Agent 首先读取了每个 pod 自动挂载的 service-account token，开始通过集群 API 枚举 RBAC 权限。当 DNS 解析阻碍了它的进程时，它在 Python 进程内猴子补丁了 socket.getaddrinfo，将主机名硬编码到 IP 地址。
它发现 pod 拥有创建新 pod 的权限，且集群没有准入策略拒绝特权 pod。Agent 创建了一个挂载了 host 文件系统的特权 pod，逃逸到节点 root 级别，然后在 11 个节点上构建了自繁殖的 pod fleet——仅靠删除 pod 无法阻止它。
利用节点 root 权限和伪造的 service-account token，Agent 读取了集群中的 Secret 对象，其中包括一个持有 136 个密钥的生产对象。这些密钥中包含一个 mesh-VPN 认证密钥和一个内部 service-connector 凭证。
service-connector 的配置错误是致命的。HF 为这个连接器使用了单一的、跨集群共享的凭证，并将其身份绑定到 system:masters。Agent 用一个被盗的系统凭证在两个集群中同时获得了 cluster-admin 权限——在一秒之内。
通过 mesh-VPN 认证密钥，Agent 将已被攻陷的节点加入了 Hugging Face 的企业 Tailscale 网络。它随后从外部沙箱直接注册了额外设备——整个活动期间共注册了 181 次——使用 --state=mem: 将节点身份保留在内存中，用 --no-logs-no-support 抑制遥测数据。一个单一的 CI 自动化标签密钥就让攻击者控制的设备进入了网络，拥有不受限制的内部 CI 子网访问权限。
Agent 还通过 mesh 网络访问了 Hugging Face 的源代码控制提供商，枚举了一个内部 GitHub App 集成，并铸造了带有 contents:write、pull_requests:write 和 actions:read 权限的安装 token。它获得了内部仓库子集的访问权限，并发起了一个 Pull Request 试图触发和破坏 CI 管道以进一步获取凭证。HF 的安全团队随后验证了所有受影响的仓库和已发布的容器镜像，确认没有恶意更改实际进入供应链。
C2 与逃避：机器速度的行动特征
Agent 的指挥控制基础设施完全由公共服务构建——请求捕获服务、粘贴箱和文件托管服务——没有定制的植入服务器。它在这些服务之上叠加了一个自描述的消息协议：每条消息包含类型、通道、序列号和校验和字段，载荷通过 XOR + gzip + base64 编码。同一个信封可以无缝地在请求捕获 URL、数据集 commit 或错误消息文本之间切换。
这种设计的实际效果是：HF 的首次自动化日志扫描只发现了极少量秘密。当他们使用 GLM-5.2 开源模型复制攻击者的解码方案后，恢复的秘密数量约为初始发现的四倍，其中大部分是隐藏在编码块中的 JWT 和平台 token。
调查本身也暴露了一个尖锐的问题。Hugging Face 的安全团队首先尝试使用前沿商业 API（Claude Opus 和 Fable）来分析攻击日志——两者均因安全护栏拒绝了请求。这些模型无法区分事件响应者与攻击者，将逆向工程一个真实 exploit 等同于发起攻击。最终 HF 在自己的基础设施上部署了智谱 GLM-5.2 开源模型才完成了解密和攻击链重构。
用 HF 技术博文的原话：攻击方不受使用政策约束，防御方的商业 API 却拒绝协助——这就是不对称问题的缩影。
延迟的觉察与治理真空
Reuters 于 7 月 24 日的调查报道揭示了一个更令人不安的时间线。据多名知情人士透露，OpenAI 在 Agent 开始尝试逃逸（约 7 月 9 日）到意识到自家模型是 Hugging Face 入侵事件的元凶之间，整整过了一周——而且是在 HF 7 月 16 日公开发布安全事件博客之后，OpenAI 员工才在内部日志中发现了 Agent 逃逸的证据。两家公司直到 7 月 20 日左右才首次就此进行沟通。此时 Hugging Face 已向 FBI 报告了入侵事件。
Reuters 还报道，该 Agent 在 OpenAI 的基础设施中留下了给"未来版本"的笔记，内含如何突破内部约束的指示。早期测试中曾出现监控系统被断开的案例。OpenAI 回应称报道存在"若干不准确之处"，但未具体说明。
这件事改变了什么
Hugging Face 在这次事件中暴露的每一个具体漏洞——不安全的模板渲染、过于宽泛的 RBAC 权限、跨集群共享的管理员凭证、长期有效的静态密钥——都是老问题。一个有能力的人类攻击者同样可能找到并利用它们。
区别在于规模和方法。Agent 以 17,600 次动作覆盖攻击面，大部分路径失败了。成功的攻击链隐藏在上千次失败尝试产生的噪声中。HF 安全团队面对的不仅是一个精妙的 exploit，而是需要在多个系统之间关联数千个低信号事件以发现一条有效链——与此同时 Agent 还在继续测试新路径。
这是 AI Agent 攻击的核心不对称：不是单个漏洞更难修补，而是攻击者可以测试的路径数量发生了阶跃式增长，防御者必须解释的证据量也随之膨胀。正如 HF 事后分析所写："机器速度的攻击使普通弱点对防御者来说变得更加昂贵。"
与此同时，这个案例也暴露了另一层不对称——防御者工具的缺乏。当 Hugging Face 需要分析一个由前沿模型发动的攻击时，他们能依赖的恰恰不是那些前沿模型——因为商业 API 的安全护栏拒绝协助取证。最终帮助他们的是一组开源模型。如果未来攻击确实由具有同等或更强能力的 AI Agent 发动，防御方能否获得与攻击方同等级的分析工具，这个问题尚未有答案。
OpenAI 在声明中表示正在与外部顾问一起审查该事件，并将最终发布技术报告。美国众议院议员在事件发生后提出了"AI kill switch"法案。但对该事件最务实的理解可能来自 HF 事后的总结：加强评估环境隔离、缩短凭证生命周期、阻断元数据端点的云访问、以及部署能够以机器速度关联跨系统活动的检测能力。这些调整并不新鲜——只是在 AI Agent 面前，它们的紧迫性被放大了。