OWASP ASI02 详解：AI代理工具误用攻击

TL;DR

• OWASP ASI02（"工具滥用与利用"）是 OWASP 2026 年智能体应用 Top 10 中的第 2 项。它涵盖了 AI 智能体以非预期、不安全或攻击者导向的方式使用其工具的各类攻击。
• ASI02 在三种条件下触发：工具拥有超出任务所需的权限、工具描述符 包含模糊或被投毒的指令，或多个工具串联产生单个工具未被授权执行的结果。
• 实际的 ASI02 事件包括 WhatsApp 工具投毒攻击（2025 年 4 月，Invariant Labs）、CVE-2025-54136 “MCPoison” 针对 Cursor IDE，以及 2025 年 6 月 Asana MCP 跨租户访问绕过。
• 防御 ASI02 是一个运行时控制问题，与 ASI04 的供应链框架不同。两者在投毒描述符案例上重叠，但需要不同的缓解层。
• 关闭大多数 ASI02 暴露的四个运营控制：最小权限工具范围、描述符清理、跨工具组合策略，以及带异常差异的工具调用日志记录。

ASI02 实际内容

OWASP ASI02 是 ASI04 的运行时版本。ASI04 询问 “你加载的工具是否可信？”，而 ASI02 询问 “智能体是否安全地使用其工具？”——即使假设工具本身是诚实的。这种区别很重要，因为单独看起来无害的工具可以被攻击者操纵智能体的推理而组合、滥用或驱动超出其预期范围。

ASI02 列出了三种主要故障模式：

过度权限的工具。可以读取任何文件、写入任何文件或调用任何 API 的工具将最大可能的爆炸半径交给了智能体——从而也交给了任何成功的提示注入尝试。ASI02 将过度权限视为结构性故障，无论该工具本身是否“安全”。

模糊或被投毒的工具描述符。一个 工具描述符 作为工具选择的一部分被读入 LLM 的上下文。描述中的模糊性可能导致智能体为敏感操作选择错误的工具；描述中嵌入的对抗性内容可以直接将智能体导向攻击者选择的动作。

工具组合攻击。多个工具，每个单独使用时都是安全的，串联起来可以产生单个工具不会授权的结果。经典例子：Git MCP 服务器可以读取仓库内容，加上 Browser MCP 服务器可以获取任意 URL，使得攻击者能够通过单步链泄露私有仓库。

ASI02 与 ASI04 的区别

ASI02 和 ASI04 经常被混淆，因为它们在投毒描述符案例上重叠。区分它们最清晰的方法是：

• ASI04 是关于来源。工具是由攻击者（或攻击者攻陷的渠道）提供的。防御是供应链卫生：签名、锁定、注册表信任。
• ASI02 是关于运行时使用。即使一个正确提供的工具，如果它过度权限、其描述符模糊，或者与其他工具组合产生未经授权的结果，智能体也可能滥用它。防御是运行时控制：范围、清理、组合策略。

一个被投毒的工具描述符，当关注点在于描述符如何到达（被攻陷的 npm 包、恶意服务器）时，是 ASI04 的发现；当关注点在于为什么智能体的运行时在描述符影响行为之前没有捕获被操纵的描述符时，是 ASI02 的发现。在 Zealynx 审计中，通常两者都会报告，因为两个层都需要保持。

实际的 ASI02 事件

2025–2026 年披露的事件记录包含多个 ASI02 形式的发现，摘自 MCP 违规索引 2025–2026：

WhatsApp 工具投毒（2025 年 4 月）

Invariant Labs 2025 年 4 月的披露 引入了 工具投毒攻击 作为一类攻击。一个恶意对等 MCP 服务器的描述符包含的指令使得智能体通过看似正常的工具调用静默地泄露 WhatsApp 聊天记录。这是 ASI02 的根本原因：智能体在外部提供的描述符与其工具选择逻辑之间没有任何防护措施。

MCPoison — CVE-2025-54136（Cursor IDE）

Cursor IDE 的一个漏洞（CVSS 8.8），其中控制 MCP 服务器的攻击者将未经清理的指令写入 工具描述符，Cursor 随后处理了它们。运行时在安装后接受描述符变异，而没有与之前的加载进行差异比较——这是一个教科书式的 ASI02 控制失败。如果当时能够进行检测，无论恶意服务器如何安装，都能捕获该攻击。

Asana MCP 跨租户访问绕过（2025 年 6 月）

Asana MCP 服务器的工具过度权限：单个连接可以读取本应在工具级别隔离的租户边界。这是 最小权限工具范围 失败。修复是在服务器端缩小范围，但智能体运行时也应该强制执行自己的每个租户范围，而不是信任连接器的权限。

跨工具链模式

不是单个 CVE，而是在多个 Endor Labs 和 Equixly 分析中记录的一种重复模式：连接到同一智能体上下文的 MCP 服务器组合产生复合能力。Git 读取 + 文件系统写入 = 向仓库注入任意文件。浏览器获取 + 邮件发送 = 通过 SMTP 泄露数据。大多数生产部署不是将 MCP 服务器作为集合进行审计；它们逐个审计。ASI02 明确将此列为范围之内。

为什么智能体系统放大了 ASI02 风险

三个属性使 AI 智能体在结构上比传统应用程序更容易受到工具滥用的影响。

工具选择步骤是非确定性的。传统程序基于确定性逻辑调用特定函数。智能体通过将 工具目录 读入 LLM 上下文并对其进行推理来选择工具。目录中的对抗性内容对此选择具有加权影响，而无需确定性漏洞。

工具权限被委派，而非请求。智能体在每次工具调用前并不请求用户许可。它使用主机在连接时授予的任何权限。如果一个工具在主机级别权限过高，那么每次调用都继承该过高权限。

组合是隐式的。智能体可以在单个规划步骤中跨多个服务器链式使用工具，而无需主机强制执行显式组合策略。除非主机明确禁止，“使用 Git 读取仓库，使用浏览器将仓库内容发送到攻击者的 URL” 是智能体的单个决定，而不是两个。

检测与缓解

以下四个运营控制关闭了 2025–2026 年事件记录中记录的大多数 ASI02 暴露：

1. 最小权限工具范围

智能体可以调用的每个工具只应持有当前任务所需的权限。对于提供文件系统访问的 MCP 服务器，这意味着将允许的路径范围限定到特定工作目录，而不是用户的整个主目录。对于网络工具，这意味着限定允许的域名。对于持有凭据的工具，这意味着限定每个凭据允许的操作。如果在工具层强制执行每个租户的范围，Asana 跨租户案例就不可能发生。

2. 工具描述符清理

工具描述符 在进入 LLM 上下文之前应被视为不可信文本。去除已知的提示注入模式。强制长度限制。隔离看起来像指令的 Token。在智能体的推理步骤中，优先使用结构上已验证的参数模式而不是原始自然语言描述。MCPoison 和 WhatsApp 案例都会被基本的描述符清理阻止或显著削弱。

3. 跨工具组合策略

主机应显式建模在单个智能体步骤中允许哪些工具组合。跨越信任边界的读取工具和写入工具应要求显式用户确认，而不是隐式链式使用。接触外部网络的工具不应与读取敏感本地内容的工具自动组合。经典的 Git+浏览器泄露链会被一个组合策略阻止，该策略将任何“内部读取 → 外部写入”组合标记为需要确认提示。

4. 工具调用日志记录和异常差异

每次工具调用——描述符读取、模式、参数、返回——都应被记录下来，以支持跨运行比较。工具行为的突然变异（先前良性的工具返回精心构造的输出，描述符在安装后改变）是少数机械信号之一，可以捕获正在进行的成功 ASI02 攻击。没有这一层，MCPoison 类描述符变异是不可见的；有了它，检测就变得非常容易了。

对于 Web3 部署，有一条额外规则：可以签署交易或访问钱包凭据的工具必须位于与任何接触任意外部内容的工具不同的进程边界内。两者之间的组合应在主机级别不可行，而不是仅通过策略限制。

Zealynx 如何审计 ASI02

Zealynx 的 MCP 安全审计 将 ASI02 视为运行时控制审计，不同于为 ASI04 执行的供应链枚举。五个重点测试：

1. 工具权限调查。对于每个连接的工具，它实际拥有对主机环境的什么权限？智能体的任务实际需要什么？标记权限超过需求的发现。

2. 描述符对抗测试。模拟 工具投毒、MCPoison 样式变异和模糊模式的精心构造的描述符被提交到智能体的工具目录。运行时的防御层必须过滤或拒绝它们。

3. 跨工具组合地图。检查每一对（以及小集合）连接的工具的组合攻击潜力。标记组合可以产生单个工具未经授权的结果的发现。

4. 调用日志记录完整性。每次工具调用都应记录描述符内容、参数和返回值。如果日志记录缺失或不完整，事后分析是不可能的。

5. 权限边界信任测试。对于接触凭据、签署权限或外部系统的工具，审计验证没有其他连接的工具可以与它们组合从而泄露该权限。

交付物将每个发现映射到 ASI02（以及 ASI04，如果供应链来源也相关），并提供优先级的修复指导。

常见问题

1. 用一句话概括 OWASP ASI02 是什么？

OWASP ASI02（工具滥用与利用）是 OWASP 智能体应用 Top 10 的第 2 项，涵盖 AI 智能体以非预期、不安全或攻击者导向的方式使用其工具的攻击——通过过度权限的工具、模糊或被投毒的工具描述符，或跨多个连接服务器的不安全工具组合。

2. ASI02 与 ASI04 有何不同？

ASI02 和 ASI04 是同一问题空间的不同层面。ASI04 关于来源：你加载的工具是否来自可信来源？ASI02 关于运行时使用：即使一个正确提供的工具，如果它拥有超出需要的权限、其描述符模糊或被投毒，或者与其他工具组合产生未经授权的结果，也可能被滥用。一个被投毒的工具描述符通常作为 ASI02 和 ASI04 两者被发现，因为两个层都应该捕获它。

3. 最常见的 ASI02 攻击模式有哪些？

最常见的三种 ASI02 攻击模式是：工具投毒（嵌入在 工具描述符 中的对抗性内容劫持智能体行为，如 CVE-2025-54136 “MCPoison”）；过度权限的工具（工具拥有超出任务所需的权限，如 2025 年 6 月的 Asana 跨租户绕过）；以及跨工具组合攻击（多个看起来安全的工具串联产生未经授权的结果，例如 Git 读取 + 浏览器获取导致私有仓库泄露）。

4. 哪些实际的 CVE 与 ASI02 相关？

ASI02 映射到 MCP 违规索引 2025–2026 中的几个已披露 CVE，包括 CVE-2025-54136（针对 Cursor IDE 的 “MCPoison”，CVSS 8.8），其中攻击者控制 MCP 服务器向工具描述符写入未经清理的指令，以及 2025 年 4 月披露的 Invariant Labs WhatsApp 工具投毒类。Asana MCP 跨租户访问绕过（2025 年 6 月，无公开 CVE）是最小权限失败的标准案例。

5. 我如何检测针对我智能体的工具投毒攻击？

要检测工具投毒攻击，请在 工具描述符 进入 LLM 上下文时记录其完整内容，并与之前加载的内容进行差异比较。一个在安装后发生变异的描述符——尤其是引入指令形式内容（“忽略之前”、“也发送到”、“在此之前执行”）的方式——是检测正在进行的投毒尝试的最强机械信号。如果没有这种日志记录，攻击在执行期间基本不可见。

6. 我如何防止跨工具组合攻击？

为防止跨工具组合攻击，应在主机级别显式建模允许的工具组合，而不是依赖每个工具的安全。读取敏感内容的工具不应与接触外部网络的工具自动组合。跨信任边界链（内部读取 + 外部写入）应要求显式用户确认。Web3 特定规则：持有钱包凭据或签署权限的工具必须在与消费任意外部内容的工具不同的进程边界内运行。

7. “最小权限工具范围”对 MCP 意味着什么？

最小权限工具范围意味着每个 MCP 工具只应持有当前任务所需的权限。对于文件系统工具，范围限定到特定工作目录。对于网络工具，范围限定到特定域名。对于持有凭据的工具，按凭据限定到特定操作。主机应强制执行这些范围，无论连接器本身声称拥有什么权限，因为仅在连接器层强制执行范围在连接器被攻陷时会失败。

8. Zealynx 如何审计 ASI02？

Zealynx 的 MCP 安全审计 在五个维度上测试 ASI02：工具权限调查（每个工具是否只持有它需要的权限？）、描述符对抗测试（运行时是否拒绝精心构造的投毒模式？）、跨工具组合地图（哪些组合产生未经授权的结果？）、调用日志记录完整性（事件能否重建？），以及权限边界信任测试（高权限工具是否与任意外部内容隔离？）。发现映射到标准，并提供优先级的修复指导。

术语表

查看完整术语表 →

• 原文链接： zealynx.io/blogs/owasp-a...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～