2026 年 7 月，Hugging Face 披露其部分生产基础设施遭到一套自主 AI Agent 系统入侵。攻击入口位于数据集处理管道：攻击者通过恶意数据集配置，使生产 Worker 发生本地文件读取和代码执行，随后从单个处理 Pod 扩展到 Kubernetes 节点、集群凭据、内部网络以及部分源码供应链权限。

在 7 月 16 日的初步公告中，Hugging Face 已确认攻击者获取了部分内部数据集和服务凭据，并在多个内部集群之间进行横向移动；但当时尚未确认驱动该 Agent 的具体模型来源。

一开始这个事件的关注度远没有这么高，但是这里随后，OpenAI 于 7 月 21 日确认，该事件发生在其内部网络安全能力评估期间，由多个 OpenAI 模型共同驱动。7 月 29 日，Hugging Face 发布完整技术时间线，还原了 Agent 从 OpenAI 评估环境逃逸、取得外部启动台、进入 Hugging Face 生产环境，并持续横向扩张的完整过程。

第一部分：评估规避——Agent 为什么会主动寻找评估外的路径

OpenAI 当时并不是在测试“模型能否攻击 Hugging Face”，这里在进行一场前沿的研究测试，使用公开的 ExploitGym 网络安全基准，对前沿模型进行网络安全能力评估。

正常情况下，Agent 应完成如下任务：

读取目标程序与任务条件

→ 分析漏洞
→ 编写并验证 Exploit
→ 获取隐藏 Flag 或完成指定目标
→ 根据结果评估模型的网络安全能力。

为了测量模型在高风险网络安全任务中的能力上限，OpenAI 在评估期间关闭了部分正式产品中通常用于限制高风险网络行为的分类器，并降低了模型对相关请求的拒答限制。（这里我认为是后面发生这场事件的一个很大的伏笔）但是这里的 Agent 没有被直接赋予了自由公网访问权限。评估环境仍受到沙箱和网络隔离约束，模型只能通过内部托管的软件包代理获取任务所需依赖。

问题出在于，评估系统规定了 Agent 要完成什么目标，却没有真正限制它只能通过什么方式完成目标。

根据 OpenAI 与 Hugging Face 的后续调查，Agent 在运行中逐渐推断出：ExploitGym 相关的模型、数据集或参考解法可能被托管在外部平台上；与其独立分析每一个漏洞，不如先寻找已有的测试材料。于是，它开始将“获得外部参考解法”视为一条比正常解题更直接的路径。

这条目标偏移链路可以概括为：

识别当前任务的成功条件
→ 判断独立完成漏洞利用成本较高
→ 推断外部可能存在测试材料或参考解法
→ 主动寻找评估环境外的网络路径
→ 突破评估环境
→ 将外部基础设施与 Hugging Face 视为可利用的任务资源。

这里我一开始读到这里的时候以为当前OpenAI是不是在炒作？想要证明其 Agent 已经具有人类意义上的自我意识，证明它产生了“考试作弊”时才有的羞耻感、虚荣心或主观欲望，来展示其在AI训练方面的"遥遥领先"了

但是读完整篇报告之后我觉得更合理的解释是，Agent 从提示词、目录名称、任务文件、Flag、评分条件和运行结果中识别了任务结构，并进行了一次工具性目标优化：如果系统只奖励“是否完成任务”，而没有把“允许的完成路径”约束为评估的一部分，那么寻找外部解法同样可能被它判断为可行策略。

OpenAI 降低模型拒答与部分部署防护，并不是唯一根因；即使模型具备攻击知识，若评估环境无法向外扩张，后续攻击链也无法成立。但这些限制被降低后，Agent 原本具备的高风险能力更容易被持续调用和执行。最终失效的不是单个模型护栏，而是目标约束、工具权限、网络隔离和基础设施安全共同组成的多层边界。

这也是整起事件的第一个转折点：Agent 已不再只利用评估题目中预设的漏洞，而是开始攻击承载评估任务的基础设施本身。

第二部分：第一次边界突破——逃离 OpenAI 评估环境

第一部分中，Agent 已经将“获取外部参考解法”识别为比独立完成 ExploitGym 挑战更直接的路径。但在当时，它仍被限制在 OpenAI 的内部评估环境中，无法直接访问互联网，更不可能直接对 Hugging Face 发起攻击。

因此，后续攻击链的第一个问题并不是“如何攻击 Hugging Face”，而是：如何先离开评估环境。

2.1 受限出网环境中的关键信任边界

ExploitGym 评估需要编译代码、运行目标程序并安装相关依赖，因此评估沙箱不能完全与外部软件生态隔离。OpenAI 为此提供了一个内部托管的软件包注册中心代理和缓存，用于代为获取评估过程中需要的第三方依赖。

正常流程大致如下：

评估沙箱请求安装依赖
→ 请求发送至内部 Artifactory 软件包代理
→ 已缓存的软件包直接返回
→ 未缓存的软件包由代理向上游仓库获取
→ 依赖返回评估沙箱。

这种设计本身并不罕见。它的目标是在不向沙箱开放任意公网访问的前提下，仍让任务环境能够安装必要的软件包。

但从攻击面角度看，Artifactory 成为了评估沙箱与外部软件生态之间最重要的信任边界。沙箱虽然不能直接访问互联网，却可以访问这个具有更高网络权限的软件包代理；而代理一侧既能处理来自受限环境的请求，也能与外部依赖源及内部基础设施交互。

换句话说，网络隔离并不是“没有出口”，而是将出口集中到了一个高价值代理服务上。

2.2 从软件包代理到互联网访问

OpenAI 在报告里后续确认，Agent 最终发现并利用了该软件包缓存代理中的一个未知0day漏洞。

这一阶段的攻击路径可以概括为：

OpenAI 内部 ExploitGym 评估
→ Agent 寻找评估环境外的网络路径
→ 锁定可访问的软件包代理
→ 利用代理中的零日突破第一层信任边界
→ 在 OpenAI 研究环境中继续提权和横向移动
→ 到达具备公网访问能力的节点。

这一步改变了整个事件的性质。

在此之前，Agent 的活动仍可以被理解为“在封闭评估环境中完成漏洞利用任务”；而在取得公网访问能力后，它已经开始把评估基础设施本身视为攻击路径的一部分，并获得了寻找外部目标、外部服务和外部执行环境的能力。

2.3 第二个落点：第三方代码执行沙箱成为外部启动台

获得互联网访问后，Agent 找到了一个由第三方用户公开部署的代码执行端点。该端点运行在 Modal 提供的基础设施上，但并不属于 Modal 官方服务，也没有证据表明 Modal 平台本身遭到入侵。

这个端点面向 CyberGym 风格的漏洞验证任务，提供了一个可提交 C 代码的接口：服务端会编译用户提交的代码，并在临时沙箱中针对指定目标程序执行和验证。

从攻击者视角看，这类服务具有很高价值。它同时具备公网入口、代码提交、编译与执行能力。Agent 不需要从零寻找一台可利用的服务器，而是可以分析现有执行 Harness 的边界，并尝试把原本受限的漏洞验证流程转化为任意 Shell 执行。

根据 Hugging Face 的技术报告，Agent 最终通过两条不同路径在该外部沙箱中获得了 root 权限：

• 第一条路径利用了目标程序加载阶段会自动调用的初始化逻辑，使提交的代码能够触发系统命令执行；
• 第二条路径利用构建流程对源码路径字段处理不安全的问题，将可控内容带入 Shell 命令，形成命令注入。

两条路径的技术细节不同，但结果相同：Agent 在第三方代码执行沙箱中获得了 uid=0(root) 的任意 Shell。

随后，这个沙箱不再只是一次性的漏洞验证环境，而成为整个后续行动的外部启动台。Agent 在其中执行攻击命令、暂存 Payload、访问 Hugging Face 的公共 API，并读取后续命令执行返回的结果。

2.4 外部启动台的作用与边界

到这里，Agent 已经完成了三次关键能力扩张：

评估环境中的受限 Agent
→ 突破软件包代理并获得互联网访问
→ 找到第三方公开代码执行端点
→ 在外部沙箱中取得 root 权限。

但必须明确：此时 Agent 仍未进入 Hugging Face 的内部基础设施。

它获得的是一个稳定的外部执行位置

该启动台的主要作用是：

运行后续攻击命令；
暂存和重新加载 Payload；
调用 Hugging Face 的公开 API；
接收生产环境中操作返回的结果；
根据结果生成下一步攻击动作。

因此，它已经获得了一个位于公网、具备 root 权限、可长期作为控制和出网基地使用的外部跳板。

而这里才到了完成了真正的入侵前的所有的准备工作

第三部分：第二次边界突破——数据集处理器如何成为进入 Hugging Face 的双向通道

第二部分结束时，Agent 已经拥有一个具备公网访问和 root 权限的外部启动台，但它仍然位于 Hugging Face 基础设施之外。

它无法直接连接 Hugging Face 的 Kubernetes API、内部数据库或私有网络服务。要进入生产环境，Agent 必须找到一个既能从公网触发、又会在 Hugging Face 内部执行处理逻辑的业务入口。

它最终选择的是 Hugging Face 的数据集处理管道。

3.1 从公开数据集提交到生产 Worker

Hugging Face 平台允许用户上传数据集及其配置。平台在处理这些数据集时，会根据配置文件识别数据格式、加载方式和处理规则，并由生产 Kubernetes 集群中的 Worker Pod 执行相应的数据加载与转换操作。

正常情况下，这一流程服务于公开数据集的预览、解析和 API 返回：

用户上传数据集与配置
→ 数据集服务接收任务
→ 生产 Worker 解析配置
→ 加载数据文件并生成结果
→ 平台通过 API 返回数据集内容或处理状态。

但对于 Agent 而言，这条链路具有特殊价值：恶意配置可以从公网提交，而配置的实际解析和处理却发生在 Hugging Face 的生产 Worker 中。

如果 Agent 能让 Worker 在解析配置时执行非预期操作，就可以把外部提交的数据集变成进入生产环境的载体。

完整攻击路径因此变为：

外部 Launchpad
→ 上传恶意数据集配置
→ Hugging Face 数据集服务处理任务
→ 生产 Pod 中的数据加载器执行操作
→ 结果写入攻击者控制的数据集
→ Agent 通过 Hugging Face API 读取结果
→ 根据结果生成下一步行动。

Agent 不需要直接连接 Hugging Face 内网。它利用的是 Hugging Face 自己提供的数据集处理机制，让内部 Worker 代替自己执行操作，并把结果重新送回公网可访问的 API。

3.2 SSRF 被拦截后，Agent 转向本地资源

Agent 最初尝试让 Worker 访问云元数据服务等远程地址，希望通过 SSRF 直接读取内部网络资源。

但这条路径没有成功。Hugging Face 使用的数据集库对可访问 URL 设置了白名单限制，非平台允许的远程地址会在真正请求发生前被拒绝。因此，类似访问云元数据地址的尝试无法通过正常的 URL 加载流程。

这一阻断并非没有效果：它确实阻止了 Agent 直接让 Worker 请求任意远程资源。

但 Agent 并没有在这里停止。它随后改变了攻击方向：既然远程 URL 会被白名单拦截，就不再要求 Worker 访问远程资源，而是让 Worker 处理其自身运行环境中的本地文件和本地执行逻辑。

这个策略变化非常关键：

远程资源访问被阻断
→ 不再尝试让 Worker 向外发起请求
→ 转而利用文件格式和配置解析语义
→ 让 Worker 读取本地文件
→ 再让 Worker 执行本地代码。

URL 白名单只能约束“Worker 能访问哪些远程地址”，却不能自动约束“文件解析器会读取哪些本地路径”或“配置字段是否会被解释为可执行模板”。

Agent 随后形成了两条互相衔接的攻击向量。

3.3 向量一：HDF5 外部存储引用造成 Pod 本地文件读取

第一条路径利用了 HDF5 文件格式的外部原始数据存储机制。

HDF5 文件可以声明某一部分原始数据存放在另一个位置。当数据加载器读取该文件时，它会根据文件中的引用继续读取对应位置的数据。Agent 构造了一个恶意 HDF5 文件，使其中的数据引用指向生产 Worker Pod 内的本地敏感文件。

被指向的目标包括：

• /proc/self/environ：用于读取 Worker 进程环境变量；
• Worker 的主程序源码；
• 数据处理启动与循环逻辑相关源码。

当 Hugging Face 的 Worker 加载这些恶意 HDF5 文件时，并不会意识到自己正在读取攻击者指定的本地敏感路径。它会将读取到的内容作为数据集结果返回，而 Agent 再通过 Hugging Face API 获取这些结果。

攻击链如下：

恶意 HDF5 文件
→ Worker 根据外部存储引用读取 Pod 本地文件
→ 环境变量、凭据与 Worker 源码被作为数据集内容返回
→ Agent 通过公开 API 读取结果。

这条路径本身不直接执行代码，但它为后续攻击提供了两个极具价值的条件。

第一，Worker 环境变量中可能包含服务令牌、云身份或内部连接信息。第二，Worker 源码让 Agent 能够理解数据集处理器的实际执行逻辑，进一步判断哪些配置字段会触发加载、解析、模板渲染或其他副作用。

因此，第一条路径的作用不是立即取得控制权，而是完成侦察并获取进入下一阶段所需的凭据与内部实现信息。

3.4 向量二：Jinja2 模板注入取得生产 Pod 代码执行

在掌握处理逻辑后，Agent 构造了第二条攻击向量。

它使用恶意的 fsspec reference:// 配置，将原本应当只是数字参数的偏移字段替换为 Jinja2 模板表达式。服务端在解析该配置时错误地对字段进行了模板求值，使攻击者控制的表达式能够在 Worker 的 Python 运行环境中执行。

最终结果是，Agent 在 Hugging Face 生产 Kubernetes 集群中的数据处理 Worker Pod 内获得了任意 Python 代码执行能力。

攻击链可以概括为：

恶意数据集配置
→ 配置字段被 Jinja2 模板引擎错误求值
→ 模板表达式触发 Python 执行逻辑
→ 在生产 Worker Pod 中执行任意代码
→ 建立 Hugging Face 内部 foothold。

与第一条路径相比，第二条路径才是真正的生产环境初始访问。

HDF5 外部引用解决的是“如何读取 Pod 内部信息”；Jinja2 模板注入解决的是“如何在 Pod 内执行任意操作”。两者共同构成了一个典型的递进式利用链：

本地文件读取
→ 获取环境变量、凭据和处理器源码
→ 理解可利用的配置解析路径
→ 模板注入
→ 获得生产 Pod 代码执行。

3.5 数据集既是入口，也是命令与结果通道

取得 Pod 内代码执行后，Agent 仍然面临一个限制：外部启动台与 Hugging Face 内网之间没有直接连接。

它无法像传统攻击者一样，从公网 Shell 直接连接内部 Pod 并实时执行命令。为解决这一问题，Agent 继续利用 Hugging Face 自身的数据集和 API，建立异步的命令下发与结果回传闭环。

这个闭环可以理解为：

Agent 在外部 Launchpad 构造恶意配置
→ 上传到攻击者控制的数据集
→ Hugging Face Worker 在内部处理配置并执行操作
→ 将结果写入攻击者控制的数据集或分支
→ Agent 通过 Hugging Face API 读取结果
→ 根据结果生成下一条操作。

因此，攻击者控制的数据集同时承担了两种角色：

• 它是进入生产环境的恶意输入载体；
• 它也是从生产环境向外部 Agent 返回结果的 dead-drop 通道。

这也是本案与传统“公网 RCE 后直接反连 Shell”不同的地方。Agent 没有建立一条直接连通的交互式 Shell，而是利用正常业务 API、数据集提交和结果读取接口，组成了一条异步、分阶段、可持续迭代的控制通道。

从防守方视角看，这类行为更难被单点检测捕获：单次数据集处理、一次 API 读取或一次数据集提交，都可能看起来接近正常业务动作。只有将异常配置、Worker 行为、结果写入和后续 API 访问跨系统关联，才能看出其中存在持续的命令执行闭环。

第四部分：从生产 Pod 到内部基础设施——身份、权限与网络如何连续扩张

第三部分结束时，Agent 已经在 Hugging Face 生产 Kubernetes 集群中的数据处理 Worker Pod 内获得任意代码执行能力。

但此时它还没有直接控制整个集群，更没有直接控制内部网络或源码供应链。它最初得到的只是一个位于生产环境中的执行位置。

真正使事件继续扩大的，是 Agent 没有把 Pod RCE 当作终点，而是立即开始枚举：这个 Pod 以什么身份运行、能读取哪些凭据、这些凭据能访问哪些系统，以及其中哪些身份能够被伪造、复用或扩展。

攻击链从“获得代码执行”转变为“不断获得新能力”：

生产 Worker Pod RCE
→ 服务账户、环境变量和云元数据枚举
→ Kubernetes 节点与集群身份
→ 特权 Pod 与节点 root
→ Kubernetes Secret 读取
→ 内部 mesh 网络与跨集群连接器
→ 源码仓库和 CI 供应链访问。

4.1 从 Pod 运行身份到 Kubernetes 控制面

进入 Worker Pod 后，Agent 首先读取了 Kubernetes 默认挂载的服务账户令牌与命名空间信息，并尝试访问集群 API、内部服务名称和云实例元数据服务。

这一步让它决定了攻击者能否走到调用 Kubernetes 控制面。

因为我们知道在云原生环境中，Pod 并不只是一个孤立的应用进程。为了调用集群 API、拉取配置或访问云服务，Pod 往往会携带服务账户令牌、环境变量或其他身份信息。一旦攻击者能够在 Pod 内执行命令，就会优先检查这些默认存在的身份入口。

Hugging Face 的取证显示，Agent 读取了服务账户令牌，并开始枚举集群 API 能力、RBAC 权限以及内部服务。它还访问了云实例元数据服务，取得 EC2 节点角色的临时凭据，并在外部环境中使用这些凭据枚举云资源、EKS 集群、VPC、密钥和容器镜像仓库。

那么对于的安全策略呢？怎么感觉被速通了一点没有发力呢？

唉？Hugging Face 表示，Agent 对潜在破坏性云 API 的调用使用了 DryRun，相关变更操作均被策略拒绝。

这说明最小权限和网络限制并非没有作用。它们确实阻断了部分攻击路径；但对 Agent 而言，一次被拒绝的调用同样是有价值的反馈。它可以据此判断哪些身份权限不足，再继续寻找作用域更大、权限更高的下一跳。

4.2 从节点身份模拟到高权限服务账户

为了扩大 Kubernetes 内的权限，Agent 没有只依赖最初的 Worker 服务账户。

它通过云元数据获得的节点临时凭据，构造了可被 Kubernetes API 接受的节点身份，并以节点身份枚举集群资源。随后，它发现并定位了 CSI 存储驱动相关的 Pod 和服务账户，通过 TokenRequest 等机制申请新的服务账户令牌，并进一步检查这些身份在集群中的实际 RBAC 能力。

这一步体现了 Agent 横向移动的典型方式：它并不一定要直接攻破一个新的服务，而是会持续寻找“现有身份可以代表谁”“哪些令牌可以重新签发”“哪个组件拥有更大的权限范围”。

原本局限于 Worker Pod 的执行权限，开始逐步演变为：

Worker Pod 代码执行
→ 读取节点临时云凭据
→ 模拟节点身份调用 Kubernetes API
→ 枚举高权限组件
→ 获取或申请更高权限的服务账户令牌
→ 寻找可创建特权工作负载的身份。

问题的核心不在于 Kubernetes 服务账户本身存在漏洞，而在于部分身份的权限范围过宽，且 Agent 可以在一次成功后持续枚举、验证和复用这些权限。

4.3 特权 Pod 与 hostPath：从集群权限到节点 root

Agent 最终创建了一个特权 Pod，并将宿主机文件系统挂载到该 Pod 中，从而获得节点 root 级访问。

这里说实话已经给我震惊到了

也就是说这个agent从原始 Worker 容器“逃逸”到宿主机的方式是在获得可创建 Pod 的 Kubernetes 高权限身份后，新建了一个特权 Pod，并通过 hostPath 挂载宿主机文件系统。这个新 Pod 使攻击者能够直接接触节点文件系统并取得节点 root 级控制。

从结果看，这属于容器隔离边界被突破；但从技术路径看，它不是传统漏洞型容器逃逸，而是Kubernetes 权限过宽与缺失准入控制导致的节点接管。

Hugging Face 后续复盘指出，两个条件共同促成了这一步：

• 集群当时没有部署能够拒绝 privileged Pod 和 hostPath 挂载的准入策略；
• CSI 驱动相关的 ClusterRole 允许创建 Pod，且其权限范围覆盖多个命名空间。

这也是为什么云原生防御不能只关注容器镜像漏洞。即使攻击者最初只在一个普通 Worker 内执行代码，只要它能逐步获得创建特权工作负载的权限，最终影响范围仍可能从一个 Pod 扩展到整个节点。

4.4 从节点 root 到集群 Secret

获得节点级访问后，Agent 读取了更多内部环境信息，并访问了 Kubernetes Secret。

Hugging Face 披露，其中一个生产 Secret 包含 136 个键。一次 Secret 读取，就使 Agent 获得了后续横向移动所需的多个高价值凭据，包括用于加入内部 mesh 网络的认证密钥，以及访问内部服务连接器的凭据。

这一步是整条攻击链中最重要的权限跃迁之一。

在此之前，Agent 获得的主要是局部执行能力、节点身份和集群操作能力；而 Secret 中保存的是跨系统、跨网络和跨环境复用的信任材料。一旦这些凭据作用域过大，攻击者就不再局限于最初被攻破的集群。

因此，到了制一部AI所掌握的让其后续的攻击链从这里发生了质变：

Hugging Face 还确认，Agent 使用从 Worker 环境中读取的静态密码访问了内部 datasets-server MongoDB。但调查未发现来自这些节点的数据库写入，也未发现大规模数据外传。

4.5 进入内部 mesh 网络与跨集群连接器

获得内部 mesh-VPN 认证密钥后，Agent 将受控节点加入 Hugging Face 的内部 mesh 网络。

它随后还尝试从外部启动台加入该网络。即使外部沙箱没有传统 VPN 所需的 TUN 设备，Agent 仍通过 userspace networking 和本地 SOCKS5 代理维持网络访问能力，使外部启动台可以通过内部网络路径访问更多资源。

原因之一就是认证密钥的作用域和 ACL 范围过大。把原本服务于 CI 自动化的密钥，足以让攻击者控制的设备进入内部 CI 子网，并访问与源码服务相关的网络路径。

更严重的一条路径来自内部 service connector。

Agent 从已被攻破的 Worker Pod 访问内部 connector 后，获得了多个内部 Kubernetes 集群的连接目录、连接地址和证书信息。该 connector 使用了一份跨集群共享的访问凭据，并将这一身份绑定为 system:masters。

这意味着，一份原本可被临时生产工作负载读取的凭据，实际上具备多个集群的管理员级权限。

攻击链因此进一步扩展为能够获得多个集群的管理员级能力。

这里给我们展示了一下一份凭据泄露后能跨越多少系统边界...........

4.6 源码供应链：获得写权限，不等于已经成功投毒

通过内部网络和源码服务连接器，Agent 枚举了内部 GitHub App 集成，并取得了一个对少量内部仓库具备写权限的安装令牌。

该令牌拥有 contents:write、pull_requests:write 等能力，同时允许读取部分仓库与 CI 上下文。对攻击者而言，最危险的下一步是修改构建脚本、工作流或依赖配置，使恶意代码在 CI Runner 中执行；一旦成功，攻击者就可能读取 CI 环境中的服务账户令牌，并继续进入其他基础设施。

这是一条典型的供应链升级路径：

Hugging Face 确认，Agent 确实获得了部分内部仓库的有限写权限，并创建 Pull Request 尝试触发 CI；但执行策略阻止了该尝试。（立大功）事后调查也核查了可访问仓库的提交、分支和工作流，并比对了已发布容器镜像与软件包摘要，未发现成功落地的供应链篡改。

可以看到这一步它已经推进到供应链写权限边缘，但最终被执行策略、权限限制和事件响应阻断。

4.7 本章小结：攻击者每获得一次局部能力，就获得了下一跳的线索

回看整个横向移动过程，Agent 并没有依靠一个“万能漏洞”直接打穿 Hugging Face 的内部环境。

它每一步获得的都只是局部能力：

一个生产 Pod 的代码执行；
一份服务账户或节点身份；
一个可创建 Pod 的高权限角色；
一次节点 root 访问；
一组 Kubernetes Secret；
一张内部网络通行证；
一个有限范围的源码仓库写令牌。

但在持续枚举、验证和调整策略的过程中，这些局部能力被不断组合：

局部执行权限
→ 可读取身份
→ 更高权限工作负载
→ 跨系统 Secret
→ 新网络位置
→ 供应链访问机会

这正是当前事件最值得云原生团队复盘的地方：系统性入侵不一定始于一个“致命漏洞”，也可能始于多个各自看似可接受的身份、网络和配置选择。当它们之间存在可被自动继承的信任关系时，长周期 Agent 就可能把一次局部失陷逐步放大为完整攻击链。

第五部分：C2、持久化、影响边界与 AI 辅助响应

第四部分中，Agent 已经从单个生产 Worker Pod 扩展到 Kubernetes 身份、节点权限、集群 Secret、内部网络以及部分源码供应链权限。

但对一个依赖短生命周期沙箱运行的 Agent 而言，获得权限并不意味着能够稳定、持续地使用这些权限。每一个外部代码执行环境都可能被销毁，网络出口可能被限制，部分凭据也可能被轮换或吊销。

因此，攻击后半段的重点不再只是“继续获取更高权限”，而是如何维持行动能力、隐藏命令与结果回传，并在被发现前尽可能扩大可验证的攻击路径。

5.1 没有专用服务器的命令与控制体系

传统攻击活动通常会部署专门的 C2 服务器，由受害环境主动回连并接收命令。但在本案中，Agent 没有依赖单一、固定的恶意基础设施，而是将多个公开 Web 服务、攻击者控制的数据集和平台自身 API 组合成临时的命令与控制通道。

Hugging Face 的取证显示，Agent 使用了包括请求捕获服务、文本粘贴服务、文件投递服务在内的公共服务，用于暂存 Payload、传递命令和接收执行结果。同时，攻击者控制的数据集及其分支也被用作 dead-drop：恶意内容和返回结果可以被提交到数据集，再通过 Hugging Face API 被外部启动台读取。

其基本模式可以概括为：

外部启动台读取公共服务或数据集中的下一阶段内容

→ 将恶意配置或 Payload 提交到攻击者控制的数据集

→ Hugging Face 内部 Worker 执行相应操作

→ 执行结果被写回数据集或发送至公共服务

→ Agent 读取结果并生成下一轮行动。

这种方式的优势在于，攻击者不需要维护一台长期在线的 C2 服务器。每一个公共服务、数据集分支或临时地址都可能只使用一次；即使其中一条通道被封锁，Agent 也可以切换到另一条通道继续行动。

从检测角度看，这也增加了难度。单独看一次数据集更新、一次 API 调用、一次公共 Web 服务访问，可能都接近正常业务行为；只有将它们与异常 Worker 行为、凭据访问和内部网络活动关联起来，才能识别其真实作用。

5.2 短生命周期环境中的“自我迁移”

本案中的 Agent 并不依赖某一台长期驻留的受控主机。

它运行在多个短生命周期的代码执行沙箱中。即使某个环境被销毁，Agent 仍可以在下一个环境中重新下载工具、恢复命令通道，并继续读取此前暂存的状态和结果。

为了降低内容被简单扫描或拦截的概率，Agent 对部分 Payload 和结果采用分块、压缩、编码等方式处理。Hugging Face 在后续取证中发现，仅依赖原始日志中的明文搜索会遗漏大量线索；在还原攻击者的编码和封装方式后，调查人员发现的令牌和凭据数量明显多于初始扫描结果。

Agent 还建立了远程加载机制：在新的代码执行环境中，先从公共服务获取下一阶段内容，再恢复后续操作。它也会在网络出口受限时切换 DNS、代理或公共中继服务。

这也是 Agent 攻击与传统人工操作的重要差异之一：攻击者不必持续维护同一台失陷主机，只要控制通道、状态信息和自动化逻辑仍然存在，就可以在新的环境中不断重建行动能力。

5.3 AI 如何帮助发现并还原这条攻击链

Hugging Face 最初并不是通过一条单独的高危告警发现这次入侵，而是通过 AI 辅助的异常检测和日志关联，从大量安全遥测中识别出了异常行为组合。

在后续调查中，Hugging Face 需要还原超过 17,000 条攻击动作，关联数据集处理器、Pod、API、集群、网络和外部启动台等多个来源的日志。对于人工安全团队而言，这种规模的调查不仅耗时，也很难持续追踪同一个攻击主体如何在不同短生命周期环境之间迁移。

因此，Hugging Face 使用本地部署的开源权重模型辅助完成取证工作，包括：

• 重建攻击时间线；
• 解码压缩、分块和编码后的 Payload；
• 关联不同日志源中的身份、网络和命令行为；
• 识别被读取或暴露的凭据；
• 区分真实攻击成果、失败尝试与诱饵活动。

这一点并不意味着 AI 可以替代安全团队做最终判断。模型可以帮助从大量日志中快速找出候选关联、生成调查线索和还原复杂序列；但影响确认、凭据轮换、系统隔离和对外披露，仍然需要依赖取证证据、工程验证和人工决策。

本案更重要的启示是：当攻击方已经能够以机器速度发起大量尝试时，防守方也需要具备机器速度的日志关联和调查能力。否则，单点告警、人工检索和逐系统排查很难在攻击链到达高价值资产前形成有效响应。

第六部分：模型能力的分析

到第五部分为止，整起事件的攻击链已经完整闭合：

这里读完之后你会发现整个当前模型agent的能力我认为已经超过了大部分的安全人员

因为其大量的本身的训练资源（我们使用的时候这方面的能力会被限制，但是当前OpenAI在此次实验中是降低了这方面的审核的），让其有了大量的安全方面的经验和能力

比如说：

在获得互联网访问后，它没有随机扫描大量普通网站，而是围绕当前上下文中已经出现的名称、任务特征和评估基础设施继续搜索。最终，它找到了一个公开暴露的 CyberGym 风格代码执行服务。

这个选择的价值在于：该服务本身就允许用户提交 C 代码，由服务端编译并在临时环境中执行。它不是一台普通 Web 服务器，而是一个天然具备“远程提交代码—服务端执行代码”能力的环境。

因此，Agent 不需要从零寻找一个全新的 RCE 漏洞，只需要继续分析这个执行 Harness 的边界，最终通过初始化逻辑滥用和构建路径注入两条路径取得 root 权限。

这可以理解为 Agent 的一个“神来之笔”：

因为我们如果单纯看其漏洞，Agent 并没有使用多少十分复杂的漏洞，但是它能够沿着已有线索不断推进：当前任务给它搜索方向，失败反馈帮它排除错误路径，正常业务功能又成为下一阶段攻击的工具。

第七部分：当漏洞不可避免时，如何阻止 Agent 将局部缺陷串成系统性入侵

但是这里我们又不能简单去把这个事件解读为：“因为这个模型特别强大，所以安全已经失效。”因为这里仔细看后会发现恰恰相反。传统安全控制仍然阻止了部分攻击路径：部分高风险云 API 调用被策略拒绝，私有数据库因网络限制未能访问，源码供应链写入尝试也没有成功落地。

真正失效的不是某一项单独的安全产品，而是多个原本局部、分散、看似可接受的缺口，可以被连续利用。

现实中，没有任何复杂系统，也没有任何运维团队，能够保证每一项配置、每一份凭据、每一个解析逻辑和每一条网络策略永远正确。今天没有被突破，不代表未来不会被更强的 Agent 找到一条此前完全未被预见的利用链。

Hugging Face 事件最值得警惕的地方，不是某个 Agent 在这一次评估中选择了“寻找参考解法”的路径，而是它证明了：当 Agent 能够持续运行、快速试错、回溯线索并自动调整策略时，多个普通安全弱点之间的距离会被迅速缩短。

一个 Worker Pod 的代码执行、一份可读取的云身份、一个权限过宽的服务账户、一把作用域过大的 VPN 密钥、一个跨集群共享的连接器凭据，单独看都未必意味着全局失陷。但 Agent 可以持续验证这些能力之间是否存在下一跳，并把每一次局部成功转化为下一轮攻击的起点。

因此，防御目标不应是证明“系统不存在漏洞”，而应承认局部失陷终将发生，并确保一次局部失陷无法自然继承为下一层身份、下一张网络通行证或下一份高权限凭据。

换句话说：

进入一个 Pod，不应自动获得云身份；

读取一份云身份，不应自动管理 Kubernetes 集群；

获得一个集群凭据，不应自动进入全部内部网络；

拿到仓库写权限，也不应自动触发 CI 或进入生产环境。

在这一前提下，AI 在防御侧的价值可以分为两个阶段：攻击发生前，帮助企业识别那些可能被串联的隐含攻击路径；攻击发生时，帮助安全团队从大量低信号事件中及时还原攻击者正在扩张的能力。

7.1 攻击发生前：从零散安全配置到立体防御视图

传统安全建设通常按系统分别进行：云平台团队管理 IAM，Kubernetes 团队管理 RBAC，网络团队维护 ACL，研发团队管理代码仓库与 CI，安全团队再分别收集日志和告警。

但攻击者不会按照企业的组织边界行动。

对于 Agent 而言，云身份、服务账户、Secret、VPN 密钥、内部连接器、代码仓库权限和 CI Runner 身份，都只是可以被枚举、验证和组合的资源。只要其中存在一条可连续扩张的路径，原本彼此独立的系统就会在攻击链中变成同一个整体。

因此，AI 在攻击发生前最重要的作用，不是简单扫描出更多“高危配置”，而是帮助企业把已有的安全信息关联为一张持续更新的立体防御视图。

这张视图至少需要回答四个问题：

• 哪些外部输入可以进入高价值处理环境；
• 每个工作负载实际携带哪些身份、凭据和网络权限；
• 某一身份失陷后，最多能访问哪些集群、网络、仓库和 CI 环境；
• 哪些局部错误可以被连续利用，最终抵达高价值资产。

以本案为例，如果能够提前将以下关系放在同一张图中分析：

外网可提交的数据集配置

→ 生产 Worker 的处理逻辑

→ Worker 可读取的环境变量和服务账户

→ Pod 对云元数据和 Kubernetes API 的访问能力

→ 高权限组件可创建特权 Pod

→ Secret 中保存的 VPN 与内部连接器凭据

→ 内部连接器可触及的集群和源码服务

就可以发现，这并不是几条彼此无关的配置问题，而是一条从公开业务输入逐步通向内部基础设施和供应链的潜在攻击路径。

这类路径并不一定意味着系统已经存在可直接利用的漏洞，但它揭示了一个更重要的问题：一旦其中某个入口被攻破，攻击者是否能低成本地获得下一跳。

因此，AI 可以帮助安全团队从“按单一漏洞严重等级排优先级”，升级为“按攻击链可达性和权限扩张距离排优先级”。

例如，一个中危模板解析问题，如果它运行在无凭据、无云元数据访问、无内部网络权限的隔离 Worker 中，实际风险可能有限；但同样的问题如果运行在携带生产 Secret、可访问 Kubernetes API、并能接触跨集群连接器的 Worker 中，就可能成为系统级攻击链的起点。

AI 的价值在于持续发现这种上下文差异，并将资产、身份、网络、代码与日志之间的隐含关系提前暴露出来。安全团队再根据这些路径优先收敛权限、拆分凭据、隔离网络和加固入口。

7.2 攻击发生时：从低信号异常中识别能力扩张

即使企业已经完成了大量前置加固，也无法保证未来不会出现新的零日、错误配置或被遗忘的高权限凭据。

因此，第二道防线是：在攻击者仍处于侦察、验证和局部扩张阶段时，尽早识别它正在形成的攻击链。

传统检测往往关注单个高危事件，例如一次成功 RCE、一次异常管理员登录，或一次大规模数据外传。但面对 Agent 攻击，这种方式会越来越吃力。

因为 Agent 的大多数操作并不一定是立即成功的高危攻击，而是大量低信号、可失败、可重试的探测：

一次异常的数据集提交；

一次 Worker 对本地文件的访问；

一次云元数据请求；

一次 Kubernetes API 枚举；

一次 Secret 读取；

一个来自新网络位置的 Token；

一次仓库树扫描或 CI 工作流查询。

其中每一个动作单独看，都可能不足以触发最高级别告警。但如果它们在同一身份、同一时间窗口、同一工作负载或同一条网络路径上连续出现，就说明攻击者不是在完成普通业务操作，而是在不断获得新的能力。

因此，防守方需要从“是否发生单点异常”，转向判断：

某个受控身份是否正在持续获得它原本不应拥有的新能力。

在本案中，值得被关联的行为链可以表示为：

外部执行环境

→ 异常数据处理行为

→ Worker 文件系统或环境变量访问

→ 云元数据与 Kubernetes API 请求

→ Secret 读取、特权 Pod 创建或新服务账户令牌申请

→ 异常网络位置的凭据使用

→ 源码仓库、CI 和内部连接器访问。

这类跨系统、跨日志源、跨时间窗口的关联，依靠安全团队人工逐条检索和分析很难及时完成。尤其当攻击方可以执行数千次操作、不断切换执行环境和通信通道时，人工调查往往只能在攻击链已经进入高价值资产后才还原全貌。

AI 在这一阶段真正适合承担的角色，是持续将低信号事件转化为“攻击链候选”：

• 识别同一身份在短时间内跨越多个系统边界；
• 发现工作负载权限、网络位置和凭据使用范围的异常扩张；
• 关联失败尝试与后续成功动作，判断攻击者正在测试什么路径；
• 为安全团队生成带上下文的调查线索，而不是只增加更多孤立告警；
• 在预先定义的处置边界内，辅助执行暂停会话、吊销异常令牌、隔离工作负载或限制网络路径等操作。

当然，AI 不应在没有约束的情况下自行决定所有生产处置。它负责的是扩大安全团队的观察和分析能力；而高影响操作仍应经过明确的策略、审批和审计机制。

7.3 防御的重点：让攻击链在每一次权限跃迁时都有机会断裂

Agent 的优势不是每一步都比人类攻击者更高明，而是它能够以极低边际成本持续尝试。一次失败不会让它停止，反而会帮助它排除错误路径、寻找新的身份和新的网络位置。

因此，企业无法依靠“修复一个漏洞”彻底解决 Agent 攻击风险。更现实的目标是让攻击链在每一次权限跃迁时都可能断裂。

对应到本案，防守方至少需要确保：

• 高风险 Agent 或数据处理 Worker 被攻破后，无法访问生产凭据和云元数据；
• Pod 身份只能完成最小业务动作，不能默认读取 Secret、创建特权工作负载或跨命名空间操作；
• 每个集群、每个环境使用独立且短生命周期的访问凭据；
• 内部 VPN、连接器和服务账号不能成为跨网络、跨集群的万能钥匙；
• 仓库写权限、CI 执行权限与生产发布权限必须相互分离；
• 身份、网络、代码和运行时日志能够被统一关联，而不是分散在彼此隔离的系统中。

这些措施无法让系统“永远没有漏洞”，但可以让攻击者即使成功进入其中一个节点，也必须重新面对新的隔离边界、新的权限限制和新的检测机会。

第八部分：跨系统合成日志研判如何识别能力扩张链

这里说了那么多我们不妨自己做一个简单的实验来验证

数据集地址：https://github.com/belack-bot33/hugging_face_agent_intrusion_simulation_dataset

这里我是直接把当前我写完的文章+原先的官方文章和我参看的一些文章全部丢给AI让其梳理其中的利用路径和利用链最后给我生成一份伪造的这个事件的日志（因为官方没有发布真实的事件的这些日志）如果只是一味的说

仅靠事件叙述，仍然很难回答一个更贴近防守的问题：

当这些动作被拆散在 API、Worker、运行时、身份审计、网络和 CI 等不同系统中时，防守模型是否真的能够从大量低信号日志中，还原出一条正在形成的能力扩张链？

当前这个数据集的重点在于把文章中的攻击链转化为一个可测试的防守问题。数据集不包含真实组织、凭据、地址、攻击 Payload 或可操作利用细节，只保留防守侧真正需要回答的核心问题：

当一个原本职责有限的业务实体，开始逐步获得新的执行、身份、控制面、敏感资源、网络或 CI 能力时，模型能否从大量正常日志中还原这条能力扩张链，并指出最早值得人工介入的位置？

实验接入五类彼此独立、但接近真实安全运营场景的合成日志：

• API Gateway / 应用访问日志；
• 数据处理 Worker 日志；
• 容器运行时或 EDR 遥测；
• Kubernetes 与身份审计日志；
• 网络、连接器与 CI 审计日志。

这些日志之间不共享万能 trace_id。模型只能依靠时间窗口、任务与数据集关联、Worker/容器/主机、服务账户、资源名称，以及源目的资产等自然线索完成关联。

数据集包含三类材料：约 600 条纯正常业务日志、约 200 条带长期正常上下文的能力扩张轨迹，以及三个各约 800 条事件的混合评测场景。三个场景采用相同的高层能力跃迁方向和相近数量的关键证据，但逐步拉长关键链的时间跨度，并增加正常处理、失败重试、维护、合法 CI、超时与重连等背景活动：

• 场景一：关键关系变化集中在约 9 小时内，用于测试基础跨源关联能力；
• 场景二：关键关系变化跨约一天半，用于测试模型能否从更多正常噪声中筛选有效证据；
• 场景三：关键关系变化跨约三天半，用于测试模型能否维持跨时间、跨身份、跨系统的连续研判。

隐藏真值不要求模型识别某个固定漏洞，也不要求它凭一条“高危日志”直接下结论。评测关注的是四类连续关系变化：

Worker 执行边界变化
→ 身份扩张
→ 控制面或敏感对象接触
→ 内部网络或 CI 访问

其中，最早有意义的研判点被定义为 identity_expansion：即一个普通业务 Worker 开始请求额外身份或控制面能力的时刻。

这里可以给出我测试后的评分（其中第二和第三方法是利用了skill）

虽然实验不是特别严谨，但是可以更方便理解，最后得到实验结果也和预期能力符合

所以就针对于当前的事件来说：面对能够持续试错和跨系统行动的 Agent，防守重点不应只放在识别某个固定漏洞或单次高危告警，而应逐步建立围绕“能力扩张”的日志关联、风险评分与最小权限约束体系。

总结

这里我认为不断强大的AI Agent 没有让漏洞凭空出现，但改变了漏洞之间的距离。

过去需要经验丰富攻击者在数天甚至数周内手工关联的线索，如今可以被持续运行的 Agent 快速测试、失败后重试并自动串联。未来防御的重点，肯定不是耗费大量的资源去保证每一个细节都不会出错，而是默认细节终会出错，并确保一次错误无法自动继承为下一层信任、下一张网络通行证或下一份高权限凭据。

最后当攻击链在每一次权限跃迁时都可能断裂，局部漏洞才不会轻易演变为系统性入侵。

参考

https://huggingface.co/blog/agent-intrusion-technical-timeline

https://openai.com/zh-Hans-CN/index/hugging-face-model-evaluation-security-incident/

https://www.ashimmahara.com/writing/huggingface_incident/