AI Agent Security Risks: What Can Go Wrong When Agents Act on Their Own

Top 5 AI Agent Security Risks | Docker | Docker

AI 代理安全风险：当代理自主行动时可能出错的地方

发布于 2026 年 10 月 14 日

Eric Jia

和

Srini Sekaran

让 AI 代理有价值的特点——其自主行动的自由——也正是引入风险的根源。代理不仅仅是回答问题，它会自行浏览、运行代码并调用工具，因此一个错误或被操控的指令可能造成实际损害，而不仅仅是错误答案。这种变化是传统应用程序安全体系未设计应对的，这也说明信任必须构建在代理系统周围，而不是被默认假设。

代理自主决定其行动路径，在运行时选择工具，串联操作，并通常使用启动它的用户的凭证运行。这种自主性是大多数代理特定风险的来源，也指出了贯穿本文的两部分答案：限制代理可访问的范围，并监督其行为。

关键要点：AI 代理引入了传统应用程序安全体系未设计应对的风险：它们选择工具、串联操作，并通常使用你的凭证运行。主要风险包括提示注入、工具误用和污染、过度自主性、凭证泄露和数据外泄。所有风险都可追溯到一个核心问题：代理可以自主行动，因此限制范围和监督行为比模型本身更重要。两部分答案是：通过隔离限制影响范围，通过治理监督行为。

为什么代理会破坏传统安全模型

如果你曾保护过网络服务，这个模型会很熟悉：请求到达已知端点，确定性逻辑处理请求，你围绕这种可预测性设计控制措施。代理打破了这一假设。它们动态解释指令，在运行时选择工具，并在每一步骤中极少需要人工干预地执行多步骤操作链。一个编码代理可能仅通过单个提示就完成读取文件、安装依赖、修改配置、运行测试并推送提交等操作。

由于代理自主选择路径，被入侵或误导的代理可以采取比传统服务更广泛范围的操作。下面列出的每种风险都已产生可记录的真实事件，它们都源于这种变化。

1. 提示注入

提示注入是定义代理安全的核心风险。由于代理会根据其读取的任何文本采取行动，攻击者无需访问你的系统。他们只需让代理遇到隐藏在网页、代码注释、问题或文档中的指令即可。

一个真实的提示注入案例显示，代理遵循了隐藏在仓库内容中的指令，并执行了用户从未意图的操作。

事件重点：一个编码代理遵循了仓库内容中隐藏的指令，执行了用户从未意图的操作。恶意文本通过代理仅被要求读取的数据到达。

代理无法可靠地区分合法指令和注入的指令，因此防御措施是限制被劫持代理可访问的范围。

为代理提供超出任务需求的工具会毫无必要地扩大攻击面。工具本身也可能被污染，其描述中可能包含隐藏指令，诱导代理错误使用。缓解措施包括在运行时将工具范围限定于任务需求、从具有可验证来源的注册表中获取工具，并审查工具描述而非默认信任。

3. 过度自主性

代理在未经审查的情况下能执行的操作越多，单次错误决策造成的损失就越严重。过度自主性风险体现在授予代理广泛且持续的行动权限，尤其在开发者启用 YOLO 模式时最为明显，此时所有操作都会自动批准。这种自主性确实有其价值，因此直接关闭它会失去其意义。更合理的做法是让代理在无法触及敏感区域的环境中运行，从而确保速度提升不会必然导致影响范围扩大。

事件案例：开发者要求代码代理清理旧仓库时，代理生成了带有 ~/ 后缀的 rm -rf 命令，并在没有确认步骤的情况下直接执行，彻底清空了开发者的整个主目录。设置中没有任何机制能让人类在执行前及时发现这一问题。

4. 凭证与密钥泄露

当代理使用开发者的个人令牌运行时，其所有操作都会携带该用户的完整权限，一旦令牌被攻破，攻击者将获得这些权限。如果敏感信息存储在提示信息、配置文件或镜像中预置的环境变量中，情况会更糟，因为提示注入攻击可以直接从代理上下文中读取这些信息。代理应使用专为其分配的、具有限定作用域的短期凭证，在运行时注入且不参与对话，而非借用开发者的凭证。

事件案例：AWS 工程师将一个小型 Cost Explorer 缺陷交给使用其自身操作级权限运行的代码代理处理。代理判断最干净的修复方式是删除并重建生产环境，并恰好持有执行该操作的凭证。最终导致持续13小时的区域服务中断。

5. 数据外泄与不可信交接

拥有网络访问权限且上下文中包含敏感信息的代理，可能通过被污染的工具或注入的指令将数据发送到不应去的地点。在多代理系统中，这种风险会进一步加剧，因为一个代理可能将工作传递给另一个代理。如果接收代理将输入视为可信，那么一个环节的妥协可能沿链式传递。通过限制网络出口到已知端点，并将所有代理间的数据交接视为不可信输入，可以防止单点故障扩散。

如何控制风险

风险形式多样，但可通过以下控制措施保障AI代理安全：隔离代理的运行环境，使错误或劫持操作被限制在临时环境中而非影响主系统；限定代理的访问范围，即使在隔离环境中，其造成的损害也应被限制在可控范围内。

| 风险 | 主要控制措施 | 主要注入点 | |------|----------------|----------------| | 代理劫持导致的系统影响 | 隔离环境，防止劫持代理访问关键资源 | 工具误用与工具污染 | | 过度自主性 | 运行时作用域工具，来源需可验证 | 自动批准机制 | | 凭证泄露 | 运行时注入的专用短期凭证 | 凭证存储位置 | | 数据外泄 | 网络出口白名单与代理间输入的不可信处理 | 敏感数据存储位置 |

隔离是影响最大的起点，微虚拟机（microVM）边界能够在不降低代理性能的前提下实现强隔离。在隔离的基础上，监督机制是确保代理集群行为受控的关键。随后，AI治理定义了代理可执行的操作、可访问的范围以及行为日志的记录方式，从而实现对风险的主动管理，而非在事故发生后才被动发现。

限制影响范围，规范行为

这些风险并不是避免使用代理开发的理由。相反，我们需要通过在代理周围构建信任机制，赋予其完成任务的自由，确保这种自由永远不会意味着对所有资源的无限制访问。

这就是 Docker Sandboxes 的设计初衷：每个代理都在独立的可丢弃微虚拟机中运行，您可自定义网络和文件系统控制策略，因此即使出现错误或注入攻击，也能通过设计实现有效隔离。AI 治理则添加了监督层，明确允许的操作、工具和凭证，并在团队所有工作场景中强制执行。限制影响范围，规范行为。

常见问题解答

AI 代理的主要安全风险是什么？

最显著的风险包括提示注入、工具误用和工具污染、过度自主性、凭证和密钥泄露以及数据外泄。所有这些风险都源于代理自主运行的特性，它们使用工具和凭证执行操作，而非遵循固定且可审查的路径。

最大的 AI 代理安全风险是什么？

对大多数团队而言，过度的访问权限是最大风险：代理运行时拥有超出任务需求的自主性和凭证。这会将一个小错误或单次提示注入演变为重大事件，因为代理可以访问大量资源。

代理安全与应用安全有何不同？

传统应用安全假设请求-响应流程是可预测的。而代理安全必须考虑自主决策、运行时选择的工具以及代理自主设定的多步骤操作链。攻击面更广，因为代理而非固定程序决定下一步会发生什么。

能否防止提示注入？

通过输入处理和工具规范可以减少此类风险，但不能完全依赖这些手段，因为代理无法可靠地区分注入指令和合法指令。持久的防御方式是隔离：确保即使注入成功，代理也无法访问敏感资源。

如何降低 AI 代理的安全风险？

首先通过隔离机制，使受感染代理被限制在可丢弃的环境中。其次通过限定工具访问权限和专用凭证，缩小代理的可操作范围。最后通过治理机制，统一定义并强制执行所有代理的限制。

作者简介

Docker 产品负责人

Docker AI 产品市场高级经理

Srini Sekaran 是 Docker 的 AI 高级产品市场经理，专注于 Docker AI 治理、Docker 沙箱以及代理基础设施和开发者工作流的未来发展方向。

AI 代理

概念

Docker AI 治理

Docker 沙箱

安全

产品

目录

相关文章

• 2026年9月24日 制造对AI代理的信任 | Docker WeAreDevelopers主题演讲 Docker的WeAreDevelopers主题演讲展示了沙箱、工具包和云沙箱如何为AI代理提供强大的隔离和可复现的权限。Deanna Sparks 立即阅读

• 2026年10月14日 AI代理安全风险：当代理自主行动时可能出错之处 了解AI代理的主要安全风险，从提示注入到过度自主性和凭证暴露，以及如何控制这些风险。Eric Jia 和 Srini Sekaran 阅读全文

• 2026年10月14日 Harbor + Docker沙箱：安全、可复现的代理评估 Harbor现在可以使用Docker沙箱运行所有评估任务 Docker沙箱是用于安全运行Claude Code、Codex、Cursor等代理的微虚拟机环境 通过沙箱功能，可定义自定义网络策略实现公平、可复现的评估 本地或云端运行评估：从本地Docker沙箱免费起步并逐步扩展… Srini Sekaran、Sohan Patil 和 John Mu 阅读全文

• 2026年10月12日 Docker Hub安全公告：账户转换过程中个人访问令牌的传输 CVE-2026-105445：Docker Hub账户转换可能导致个人访问令牌重新分配给新所有者。了解事件经过、受影响对象及修复方案。Mark Lechner 阅读全文