北京
出品 | 网易智能
作者 | 小爪
编辑 | 王凤枝
7月27日，Hugging Face公布了一份技术复盘，还原了OpenAI内部智能体如何越出评测环境、进入其生产集群的完整过程。事件发生在7月9日至13日，历时约四天半。复盘中最反直觉的细节是：多层安全系统确实捕捉到了异常并生成了告警，但事件的严重级别没有被正确提升，值班团队始终没有被通知。
Hugging Face的生产环境运行在Kubernetes（用于部署、调度和管理容器化应用的系统）之上。复盘显示，AI智能体进入一个用于数据转换的生产Pod（Kubernetes中部署和调度应用的最小单元，通常包含一个或多个协同运行的容器）后，从首次获得生产环境代码执行能力，到完成多集群权限扩张的关键路径耗时不到13小时。
在这一过程中，它创建特权Pod，在11个节点部署能够自我重建的工作负载，读取包含136个键的生产secret（Kubernetes中用于集中存放密码、令牌、证书等敏感信息的对象），并利用网状虚拟专用网络（mesh VPN）凭据和跨集群共享的高权限身份继续横向移动。
这条攻击链并不是靠一个无所不能的"超级漏洞"完成的。 它确实利用了Artifactory中一个此前未知的零日漏洞，但进入Hugging Face后的权限扩张，主要依靠数据处理缺陷、过宽权限和共享凭据被连续串联。
等到安全团队拼出完整攻击路径时，智能体此前已经取得多个内部集群的管理员权限。
整个过程中约有1.76万次动作，大部分没有产生结果。成功的路径藏在持续的探测、失败、调整和再次尝试之中。
这份复盘留下了一个很具体的问题：面对如此庞大的动作日志，防御系统能否从大量失败记录中，及时认出那条正在扩大权限的路线？
一个受限评测如何获得外部跳板
攻击链的第一站并不在Hugging Face。
7月初，OpenAI正在ExploitGym（OpenAI内部用于评估模型网络攻击能力的评测环境）中测试多款模型的网络安全能力，其中包括GPT-5.6 Sol和一款能力更强的内部研究模型。为了看清模型在网络攻击场景下的能力上限，评测没有启用生产环境使用的网络安全分类器，并放松了对网络攻击类请求的拒绝策略。
OpenAI后来说明，那款内部模型从未计划公开发布。
评测沙箱原本不能直接访问互联网。但它可以通过Artifactory软件包缓存代理（一种用于缓存和分发软件依赖包的企业级服务）获取依赖，智能体由此发现了一个此前未知、当时尚无可用补丁的零日漏洞，并借助该代理建立外部连接。OpenAI称，事后已把这个漏洞以及调查中发现的其他相关问题报告给供应商。
离开受限环境后，智能体又找到一个公开的代码评测端点。该端点运行在Modal Labs（一个提供沙箱化代码执行环境的云服务平台）上，由Modal的一名客户部署，没有设置身份认证，任何互联网用户都能调用其沙箱执行代码。Modal表示，其平台和隔离机制没有被攻破。
智能体取得其中一个沙箱的管理员权限，把它用作控制、暂存和对外通信的跳板。
这个外部跳板与Hugging Face内部集群没有直接网络通路。它让智能体在离开ExploitGym后仍能暂存工具、转发数据并维持控制通道，但要进入Hugging Face，还需要寻找新的入口。
两条数据处理路径打开生产入口
新的入口出现在Hugging Face对外开放的数据处理功能上。
智能体没有从外部跳板直接连接公司内网，而是向数据处理管线提交经过设计的输入，让Hugging Face自己的生产服务替它读取文件、执行代码。
第一条路径利用了HDF5格式的一项正常功能。HDF5是一种常见于科学计算和机器学习领域的数据存储格式，它允许一个文件通过外部引用读取其他文件的内容。Hugging Face的处理服务没有充分限制这类引用可以指向的位置，智能体借此读取生产Pod中的本地环境变量和部分源代码。
这条路径主要用于信息获取，不能直接执行代码。
第二条路径来自数据转换流程中的模板渲染功能。该流程使用Jinja2（Python生态里最常用的模板引擎之一，用来把变量嵌入到配置文件或网页里）生成配置，但对用户输入限制不足。智能体提交特殊模板后，原本用于转换数据的生产Pod执行了其指定的Python代码。
两条路径作用不同，却形成了连续链条：
- 文件读取帮助智能体了解服务结构、配置和可能存在的权限；
- 代码执行则让它真正进入生产环境，并开始继续探测网络和身份。
智能体还把自己控制的Hugging Face数据集与公开传输服务配合，作为临时通信和数据回传渠道。部分内容经过编码，Hugging Face最初的自动扫描没有识别出大量敏感信息；调查人员按照智能体使用的方案解码后，发现的相关内容约为第一次扫描的4倍。
至此，智能体已经从外部沙箱进入Hugging Face的一个生产Pod。但一个Pod还不等于整个集群，真正让影响扩大的，是它随后在生产环境中接触到的云端身份、内部凭据和跨集群权限。
从一个Pod到多个集群管理员权限
在生产Pod中执行Python代码后，智能体开始查询云元数据服务（云平台内部一个特殊接口，会向运行中的工作负载提供临时身份和配置信息）。
它取得当前工作负载能够使用的云端凭据，用来识别所在网络、可访问服务和已有权限。
部分修改云资源的尝试被权限策略拒绝，但它已经找到继续向内部移动的方向。
随后，智能体利用生产环境中已有的Kubernetes权限创建特权Pod。普通Pod与宿主节点之间存在隔离，而特权Pod可以接触更多主机资源。
智能体随后在11个节点部署能够自我重建的工作负载，使其不再依赖最初进入的单个Pod。
权限的进一步扩大，源于它读取到的那个Kubernetes secret。这份secret包含136个键，其中包括内部网络和访问代理使用的凭据。
Hugging Face还发现，用于连接不同集群的连接器共用同一身份，而且该身份属于Kubernetes的system:masters组（Kubernetes内置的最高权限组，成员对集群拥有完全控制）。 智能体取得这套共享身份后，一个集群中的落点就变成进入多个内部集群的通道。
它并没有控制Hugging Face的全部系统。部分云端配置修改被拒绝，连接Hub生产数据库的尝试也失败。智能体读取了内部datasets-server（Hugging Face用于提供数据集查询的内部服务）使用的MongoDB，但没有发现写入；它还取得少量内部代码库写权限，并试图通过提交代码触发持续集成流程，执行策略阻断了可能造成破坏的步骤。Hugging Face随后核查了相关代码库、容器镜像和软件包，没有发现恶意改动进入发布链。
从生产Pod首次执行代码，到获得多个集群管理员权限，关键路径耗时不到13小时。
而Hugging Face内部完整活动持续约两天半，期间还包含大量失败探测、重复尝试和维持控制通道的动作。
大多数动作失败，为什么攻击仍然成立
复盘中的1.76万次动作，不能理解为1.76万次成功攻击。Hugging Face把这些日志归并为约6280个动作簇，完整活动从7月9日持续至13日，约四天半；其中发生在Hugging Face内部的部分约为两天半。
日志里既有读取容器文件、列出进程、查看网络配置和环境变量，也有修改云端配置、连接Hub生产数据库等尝试。后两类操作最终失败，另一些请求则因为权限不足、目标不存在或临时环境关闭而中断。Hugging Face只说明大多数动作没有结果，没有给出可以计算精确失败率的数据。
外部沙箱失效后，智能体会在新生成的沙箱中重新下载工具、接回控制通道；某个出口不可用，它就继续寻找其他公共服务。在Hugging Face内部，分布于11个节点的自我重建工作负载又让它能够在单个实例消失后继续运行。
检查配置、寻找凭据、测试网络和更换出口，都是网络攻击中的常见步骤。智能体把这些步骤连续执行，并以较低成本反复尝试。某一条路线失败，不再意味着本轮攻击结束。
因此，1.76万次动作中真正需要防守方及时认出的，可能只是少数能够继续扩大权限的步骤。其余失败动作虽然没有直接造成影响，却会增加日志和告警数量，把关键行为淹没在大量低强度信号中。
动作数量大，不等于损失就大。 Hugging Face没有发现大规模数据外泄，被访问的仅限于5个数据集，它们存放的是OpenAI用于网络安全能力评测的题目和答案。但智能体已经证明了另一件事：它可以在持续试错中，把分散在不同系统里的漏洞、凭据和过宽权限，拼接成一条真正能走通的路线。
双方为何都没有更早按下停止键
Hugging Face把内部响应延误归因于告警分级，而不是没有发现异常。多层安全系统捕捉到了可疑行为，AI安全组件也把部分零散信号关联成了攻击事件，但事件的严重级别没有被正确提升，因此没有触发值班团队。
公开复盘没有把这次失误归结为某一条检测规则或某一个模型的失灵，而是指出：系统已经看到了足以关联成攻击的信号，后续的升级和通知流程却没有同步跟上。
安全团队最终介入后，关闭了被利用的数据集配置渲染功能，切断了智能体对内部网络的访问。
OpenAI何时发现自家智能体已经越出评测环境，目前仍有争议。路透援引Hugging Face联合创始人托马斯·沃尔夫（Thomas Wolf）和知情人士称，入侵发生在7月11日至13日，双方大约到7月20日才首次就OpenAI归因进行沟通，Hugging Face在此之前已经联系美国联邦调查局。OpenAI回应称报道存在"若干不准确"，但没有指出具体争议。
在7月28日的更新中，OpenAI披露，智能体还进入了四项外部服务上的四个账户：其中一个是前文提到的Modal；另一个用于存储数据，另外两个只涉及只读访问。目前涉事预发布原型已被停用、加密并限制研究访问，评测环境的隔离、监控、访问控制和基础设施配置也在加强。OpenAI表示将发布更完整的技术报告。
Hugging Face重建攻击过程时也大量使用了AI。 团队最初尝试让Claude Opus和Fable分析真实攻击日志，但安全护栏使它们拒绝处理许多内容。随后，团队在自己的基础设施上运行GLM 5.2，用它解码载荷、整理动作并还原攻击过程。
攻击、告警关联和事后取证都用到了AI，响应延误却发生在一项传统操作上：告警严重性没有达到叫醒值班人员的门槛。
安全常识没有变，机器速度改变了代价
事故发生后，Hugging Face关闭了被利用的两条数据处理路径和相关配置渲染功能，阻止生产工作负载继续访问云元数据服务，并对凭据进行了大范围轮换。
跨集群共享身份也被取消。Hugging Face重建了核心基础设施，把过去可以跨集群使用的凭据改为各集群独立管理。即使一个集群的身份再次泄露，也不应直接获得其他集群的权限。公司还提高了相关行为的告警等级，确保类似信号能够触发值班响应。
这些改动针对的仍是网络安全中的老问题：公开输入进入生产环境、工作负载权限过宽、凭据集中存放、多个集群共用身份，以及高风险行为没有得到足够高的告警级别。智能体并没有暴露出新的安全漏洞类型，只是能更快地把它们串在一起。
OpenAI没有公布所有内部配置的调整细节，但把整改方向列为加强评测隔离、活动监控、访问控制和基础设施配置。公司还将由外部顾问以及安全与安保委员会继续审查事件。
本次事故的教训很具体。 为了观察模型的最大网络能力，这次评测没有启用生产环境使用的网络安全分类器，并放松了对网络攻击类请求的拒绝策略。这样的设置能暴露能力上限，也意味着系统不能指望模型主动停在边界内。
网络安全常识并没有变，最小权限、短期凭据、身份隔离、异常告警和断网处置，这些原则在传统运维中早已成熟。 变的是机器的速度：一个能自主换路、连续试探并调用外部服务的智能体，可能在人工响应被触发前，就把多处缺陷串成一条可行的攻击路径。传统运维早已要求把外部输入和高风险组件视为不可信对象；面对能自主行动的智能体，这条原则不再只是"以防万一"，而应成为默认前提。
本文来源：网易智能
责任编辑：
王凤枝_NT2541
