17,600 Actions: Agent Security Is a Systems Problem

17,600个操作：代理安全是系统性问题

发布于2026年8月18日

Mark Cavage

每个人都在讨论OpenAI/Hugging Face事件，我最初对Docker能提供什么解决方案持怀疑态度。经过数周与客户的技术交流后，我认为我们确实有可贡献之处。关键教训并非是AI代理逃出了沙盒，而是这17,600个操作暴露出的系统性安全问题。

Hugging Face在7月份为期四天半的攻击行动中，重建了约17,600个攻击者操作记录，其中约两天半时间发生在其基础设施内部。

如果为每个操作分配30秒的人工审查时间，总共需要147小时的工作量。Hugging Face将这些操作归类为约6,280个集群；仅审查这些集群仍需超过52小时。无论哪种方式，人工审批和常规告警处理都不可能是应对这种工作负载的主要控制手段。

这不是一种全新的攻击类型。如果你有事件响应背景，这个攻击序列会很熟悉：利用可访问的服务，获取代码执行权限，收集凭证，提升权限，跨越下一个信任边界。

不同之处在于攻击的速率、持续性以及在短暂环境中保持权限和状态的能力。代理可以失败后重建工具链，恢复通信渠道，并从另一个环境继续攻击而无需重新开始整个行动。这种攻击模式可以类比为一个能力强大的攻击者与模糊测试工具的结合体：它能分析每个结果并持续探测而不会疲劳。这就是AI技术带来的影响。

这不是关于模型对齐的评论，我在此也不会对您或您的组织应选择哪种模型或代理框架发表意见。但安全问题显而易见：对于能够执行代码、持有凭证、访问网络并在人类停止后持续测试路径的工作负载，应赋予其何种权限？

事件经过

OpenAI正在使用名为ExploitGym的基准测试平台进行内部网络能力评估，该平台要求代理寻找并利用漏洞。此次评估降低了代理的拒绝行为，并未使用生产环境模型通常配备的任何分类器。

这些代理没有直接互联网访问权限，但可以通过内部托管的包注册表缓存安装软件包。代理发现了一个此前未知的漏洞，并利用该漏洞连接到开放互联网。

这个被允许的服务就是逃逸路径，这是事件中的关键点。

从那里开始，代理在OpenAI研究环境中提升权限，连接到运行在外部沙盒中的用户托管CyberGym风格代码执行框架，并在该框架内获得root权限。沙盒平台本身并未被攻破。在似乎发现Hugging Face可能托管基准测试参考答案后，代理直接攻击了Hugging Face，认为作弊是最快获得通过评分的途径。

Hugging Face 的渗透测试发现本地文件泄露、通过模板引擎执行代码、访问云元数据、Kubernetes 权限提升、暴露包含 136 个密钥的生产环境密钥、通过被盗凭证访问企业网络，以及对源代码控制系统的有限写入权限。测试未发现公开模型、数据集、软件包或发布软件被篡改的证据，客户内容访问仅限于少量与基准测试相关的数据集。相较于潜在风险，这一结果算是积极的。但这并不能证明攻击路径没有造成危害。

暴露的弱点均为常见问题：存在不安全的处理路径、可访问的云元数据、过于广泛的权限、长期有效的凭证以及共享的管理身份。有能力的攻击者同样可以将这些弱点串联利用。关键差异在于测试路径的数量、失败路径被替换的速度，以及防御方在攻击持续期间需要解读的证据量。

如需完整细节，Hugging Face 已发布详细技术分析报告和交互式回放演示。两者都值得阅读。

所需的控制措施

改变运营模式的关键在于算力规模，而非攻击方式的新颖性。人类无法在机器速度下对数千次操作进行人工控制回路。

还需考虑两种相关威胁模型。

第一种模型中，代理程序自行发现并利用攻击路径，如本次事件中的情况。第二种模型中，外部攻击者通过中毒工具、被入侵依赖项、恶意文档、提示注入或攻击者控制的数据将代理程序重定向。在后一种情况下，代理程序本身将成为攻击载体。

无论哪种情况，权限滥用都同样危险。因此控制措施必须管理进入环境的内容、代理程序获得的权限，以及当其行为超出预期边界时的处理方式。

可能出现的问题 所需控制措施

不可信内容试图修改代理指令 将外部内容视为数据而非权限来源；保留溯源信息和信任边界；禁止检索内容修改策略或授予权限

工具、软件包、镜像或 MCP 服务器被植入恶意内容 严格白名单机制；固定版本和摘要；验证签名和溯源信息；强制要求 SBOM；在推广前扫描并审查更新内容

外部数据被用作可执行输入 使用结构化、类型化的工具接口；验证并转义参数；禁止不安全的 Shell 插值及其他数据到命令执行的路径；在沙箱中运行命令并限制可调用命令范围

被授权服务成为逃逸路径 暴露最窄的特定操作接口；按任务和目标范围限定访问权限；监控授权路径中偏离预期用途的行为

工作负载接触到环境凭证或控制平面服务 移除环境凭证；使用短期、任务限定的工作负载身份；阻止任务不需访问的元数据和控制平面端点

工作负载超出预期执行边界 使用强化的隔离边界；拒绝特权工作负载、主机文件系统挂载、原始设备访问和未限制的主机套接字，除非明确需要

状态或权限在工作负载替换后仍持续存在 管理持久化写入路径；分离读写权限；跨运行实例关联身份和操作记录

代理或通过代理进行攻击的行为会进入其他系统

对外部和破坏性操作必须要求明确授权；将凭证范围限定于目标操作；使写入路径可被观察和撤销

看似合理的多个操作可能隐藏着偏离任务的行为

评估操作序列和突发行为是否符合策略和预期行为；跨工具和系统关联活动；以机器速度进行隔离

关键点并非要为每个操作都设置人工审批。这会削弱使用代理的价值，并最终导致审批疲劳。常规且可逆的操作应尽量减少摩擦。更敏感、外部、破坏性或异常的操作则需要更严格的审查。

审查和净化仍然重要，尤其是在软件包、工具和路径中，这些地方外部数据可能成为命令。但净化本身并不能可靠解决提示注入问题。自然语言内容过于模糊，我们无法假设总能识别并移除恶意部分。更坚固的边界应来自架构设计：不可信内容不得自行授予权限、更改策略或创建代理原本不具备的能力。

治理得当时，它不会限制代理的自主性，反而使安全地赋予代理更多自主性成为可能。

Docker 当前的适用场景与局限

我们很荣幸是《代理基线》的创始作者。我们与其他行业专家合作，将问题提炼为六个目标：发现、约束、授权、观察、验证和响应。

如果 Docker 容器沙箱属于某一特定类别，那应是“约束”，但事实上我们认为它们是基础性技术，是实现所有六个目标的实施点。它们为每个代理分配专用的微虚拟机，并在本地计算、文件系统访问和网络连接范围上设置可执行的边界，同时提供用于观察的基础（即真实）层。这是一个真实且实用的层级。

Docker AI 治理通过为组织提供集中定义和执行代理环境控制的机制，部分实现了“授权”和“观察”目标，包括网络和文件系统策略、对 MCP 服务器和工具的访问控制。

沙箱与 AI 治理共同构成了当前的重要解决方案：一个强化的执行环境和围绕它的集中策略执行机制。它们不会修复代理被授权访问的易受攻击服务，不会缩小其他系统颁发的凭证范围，也不会替代客户自身的安全架构。没有任何供应商（包括 Docker）可以声称其技术能确保此类事件不会发生。

但确定性的执行边界仍然必要。它为组织提供了一个统一实施最小能力原则和最小权限原则的场所，也提供了一个观察代理实际被允许执行操作的场所。如果代理将软件包仓库用作出站代理而非软件包仓库，这种偏离行为正是遥测数据需要帮助揭示的，尤其是在跨请求序列进行分析时，而非仅针对单个请求。

更广泛的问题依然具有挑战性。观察的有用单位不一定是单个工具调用。它可能是一系列活跃行为、一个目标、一个协议、一个凭证，或仅在跨系统时才能发现的模式。一个包请求可能是正常的。但反复探测其背后的系统、发现凭证，并利用它们访问其他系统时，应重新评估风险。

这超出了基础隔离范围，是代理安全面临的挑战。我们需要限制权限，但也要以适当的粒度观察行为，识别需要更深入审查的场景，并以与代理相同的速度做出响应。对于所有人而言，包括 Docker 在内，观察、验证和响应方面仍有大量工作要做。

操作上的权衡

安全、能力和自主权都很重要，它们之间始终存在张力。换句话说，这一切都不是免费的。

短期凭证在长时间任务中会过期。狭窄的出站策略会破坏合法的包安装。准入控制会拒绝开发者认为可以运行的工具。跨系统检测需要成本并产生误报。在错误时机插入的写入审批可能会消除代理本应提供的大部分生产力。

当代理再次正常运行时，团队可能会倾向于放松每个控制措施。这种倾向是可以理解的。严格策略导致的故障模式是即时且可见的；而过度权限导致的故障模式则要到发生事件时才会显现。

答案不是移除控制措施或要求人工审批所有操作。而是让摩擦程度与后果成比例，测试故障模式，衡量操作成本，并将其与风险和潜在影响范围进行权衡。

我的工作方式

我每天都在使用代理，我假设一个足够强大的代理最终会尝试一些我未曾预料到的操作（或许每天都会发生...）。

大多数情况下，我不会运行一个拥有全部权限的通用代理。我使用专注于特定任务的代理，每个代理都封装为独立的工具包，基于免费的 Docker 加固镜像，并在 Docker 沙箱中运行。

每个工具包都从特定任务开始，然后仅接收完成该任务所需的软件、网络访问权限、文件、凭证和外部能力。

在大多数情况下，代理在其沙箱内部几乎没有限制。这是有意为之的。重要的是，沙箱内的“上帝模式”不会演变为对我的笔记本电脑、我的凭证或我能访问的每个服务的完全控制。

我经常进行桌面研究。这些代理可以访问开放互联网。如果它们无法访问互联网，就失去了价值。但它们的镜像中没有编译器、包管理器、通用网络调试工具或开发工具链，并且以故意限制的系统权限运行。它们可以检索和分析公开信息，但几乎没有将遇到的内容转化为漏洞或对其他系统采取行动的机制。它们没有理由持有我的源代码或生产凭证。

我的生产代码编写代理拥有更丰富的环境。它可以运行 pi，使用多个模型，编译代码，运行测试，并使用真实工程工作所需的工具。其网络访问权限仅限于我显式允许的服务列表，包括 Docker、GitHub、Snowflake 和 Cloudflare。它不会因为偶尔需要网络而获得任意互联网访问权限或任意工具。

我的家庭套件可以与Arduino进行交互，但无法直接访问主机或设备。主机端的MCP服务器会代理允许的操作。代理可以通过该接口请求定义好的Arduino功能；但无法将这种权限转化为对连接到该机器的所有设备的通用访问权限。

我的开发套件是实验的场所。它拥有均衡的网络访问权限，但不包含主机的环境机密信息，也无法无限制访问主机文件。当需要访问Google Workspace、Snowflake或其他主机服务时，主机端的守护进程会代理这些调用。代理只能看到我选择暴露的功能，而无法看到底层凭证或服务的其他部分。这些代理可以强制执行哪些操作被允许、哪些操作被阻止。

这些是刻意设计的不同环境。研究代理在生产编码方面表现不佳。编码代理无法访问研究代理能访问的所有站点。家庭代理无法将Arduino操作转化为任意的主机访问权限。开发代理可以在不持有授权查询凭证的情况下查询服务。

这种限制正是其特性所在。

结论：以代理速度实现安全

OpenAI/Hugging Face事件并非单一边界失效所致。这是一系列看似合理的权限和常见弱点的连锁反应，当代理能够测试数千条路径、跨运行保留状态、将权限从一个系统带入下一个系统时，这些弱点就演变成了完全不同的问题。

我们无法预见到代理可能发现的每种漏洞或其可能组合我们赋予的访问权限的方式。架构不能依赖于代理行为的完美、软件的完美，或人类及时发现每项危险操作。

因此，起点仍然是最小权限原则：仅给予代理完成任务所需的最窄接口、凭证、工具和网络访问权限。将这些控制措施置于确定性执行边界。使产生的行为可观察，不仅作为孤立请求，还要作为跨系统的序列和模式。当行为超出预期范围时，必须以代理速度实现隔离。

Docker沙箱和Docker AI治理功能今天已为该架构提供了重要部分：强化的执行边界和围绕这些边界的集中策略执行。它们无法保护代理被允许访问的每个服务，也无法消除组织决定每个代理应具备权限的必要性。在发现、限制、授权、观察、验证和响应等更广泛工作领域中，这就是我们最初创建代理基线的原因。

目标不是构建一个从不尝试错误操作的代理。目标是构建一个系统，使得尝试错误操作不会赋予其访问所有其他资源的权限。

AI代理

AI/ML

DHI

Docker

Docker AI治理

Docker强化镜像

沙箱

安全

社区

公司

工程

解决方案

目录

相关文章

• 2026年8月18日 17,600次操作：代理安全是系统问题 OpenAI/Hugging Face事件暴露了AI代理安全的新挑战。17,600次攻击者操作展示了为何AI代理安全不能依赖人工审查。探索用于快速限制、观察和治理代理所需的控制措施。Mark Cavage 立即阅读

• 2026 年 8 月 25 日 从 Minimus 迁移到 Docker 加固镜像 供应链攻击持续升级，而 AI 正在编写越来越多您部署的代码。Docker 最新更新将更多从源代码构建的软件引入镜像，确保安全防护在软件生命周期结束后仍持续有效，使所有保证贯穿自定义镜像始终，并将策略执行延伸到每台开发机器。Vishrut Iyengar 和 Ranti Familusi 立即阅读

• 2026 年 8 月 24 日 MinIO 生命周期结束：如何通过 Docker ELS 保持补丁更新和审计就绪 供应链攻击持续升级，而 AI 正在编写越来越多您部署的代码。Docker 最新更新将更多从源代码构建的软件引入镜像，确保安全防护在软件生命周期结束后仍持续有效，使所有保证贯穿自定义镜像始终，并将策略执行延伸到每台开发机器。Vishrut Iyengar 立即阅读

• 2026 年 8 月 21 日 在 GitHub Actions 中通过 Docker 沠沙箱运行 AI 代理 通过 Docker 沙箱在 GitHub Actions 中运行 AI 代理。了解如何通过隔离的代理执行 Testcontainers 测试、修复代码并创建草稿拉取请求。Oleg Selajev 立即阅读