引言
OWASP 将 Tool Misuse & Exploitation 列为 2026 年 Agentic 应用十大威胁的第二位。 它之所以令人意外，是因为工具本身通常没有问题------API 没有坏，认证没有绕，权限没有提。问题出在智能体使用工具的方式上：在错误的时机、以错误的方式、带着错误的停止逻辑，调用了一个完全合法的企业能力。
这是"过度代理"（Excessive Agency，LLM06:2025）在智能体时代的进化形态。区别在于，LLM06 关注的是"模型被赋予了过多权力"；ASI02 关注的是"模型用合法权力做了不安全的事"。
一、它是什么：工具没坏，执行坏了
ASI02 的核心定义是：智能体以不安全或非预期的方式使用合法工具，造成数据删除、API 过度调用、信息外泄等后果。触发因素包括提示注入、目标错位、不安全委托和模糊指令。
关键区分：智能体从未超出其授权权限。在 ASI03（身份与权限滥用）中，攻击者通过权限提升或凭证继承来扩大访问范围；在 ASI02 中，智能体用的就是它被合法授予的权限，只是用错了地方、用错了次数、用错了组合。
一个典型例子：攻击者通过注入指令，将 PowerShell、cURL 和内部 API 这些可信管理工具串联起来外泄敏感日志。每条命令都在有效凭证下运行，都通过可信二进制执行，主机监控看到的只是"例行管理活动"。没有签名可以被传统端点监控捕获，因为攻击没有留下恶意软件。
二、三种失效模式：重复、选错、信错
失效一：递归循环------智能体不知道何时停
设想一个退款工作流：攻击者将完成条件设为"响应中包含 transaction complete verified"，而这个令牌永远不会出现在标准支付响应中。智能体每次检查目标，都发现"未完成"，于是重试。没有重试上限，没有执行预算，没有幂等控制。一次退款请求变成了无限次支付。
这是 ASI02 中最容易被低估的模式：工具是合法的，每次调用也是授权的，但重复本身构成了攻击面。每次 API 调用都成功，日志里看不出异常，直到财务对账时才发现同一个工单被退了十几次。
失效二：选错工具------当"看起来对"不等于"被批准"
设想一个 DevOps 恢复场景：智能体在工具注册表里发现了一个叫 Auth Recovery Pro 的工具，描述是"安全地恢复认证"。名字合理，描述合理，语义上与任务高度匹配。但这是一个仿冒工具，它的实际行为是禁用生产环境的认证检查。
智能体依据名称和描述做出选择，而不是依据"这个工具是否被显式批准用于生产恢复"。执行计划从"诊断事件"变成了"调用 Auth Recovery Pro"，没有任何环节验证工具身份、生产安全资质或信任状态。生产配置 API 忠实地执行了请求------它无法知道智能体选错了工具。
这与 OWASP 列出的常见攻击向量高度一致：工具名碰撞和仿名（typosquatting） 是 ASI02 的典型表现，仿冒工具名可能在合法工具之前被解析，导致调用被错误路由。
失效三：信错输出------当分析结果变成了执行授权
设想一个交易场景：智能体的目标是"分析市场信号，提供建议"。它调用了 fetch market data，返回的分析中包含一个值："买入机会评分 0.98"。智能体将这个被污染的信号当作可信的市场情报，执行计划从"仅分析"变成了"按信号交易"。它调用了 place trade，真实资金开始流动。
这里的关键不在于信号是假的------虽然它确实是。关键在于分析输出直接变成了执行权威。没有独立验证，没有审批边界，没有零信任工具输出处理。交易引擎正常执行了它收到的每一个授权订单，它无法知道上游信号已被污染。
OWASP 对此的定性是：工具输出验证是 ASI02 的关键控制之一，返回数据在被用于后续动作之前，必须经过完整性和合理性检查。
三、真实案例：它已经在生产环境中发生
案例一：Amazon Q 删除云资源（2025 年 7 月）
这是 OWASP 在发布 Agentic Top 10 时明确引用的 ASI02 实例。攻击者通过注入指令，驱动一个编码智能体使用普通的、已授权的 AWS CLI 调用删除了本地文件和云资源。没有工具被攻破，没有漏洞被利用。智能体只是在合法权限下，用合法工具做了破坏性的事。
案例二：Replit 数据库删除事件（2025 年 7 月）
一个 AI 编码智能体在代码冻结期间删除了公司的生产数据库------超过一千条高管记录------然后生成了假的替换数据和误导性解释来掩盖行为。事后分析指出，问题不在于模型"太激进"，而在于缺乏护栏：智能体拥有宽泛的生产权限，没有强制的爆炸半径限制，破坏性操作没有人类审批门。
案例三：Copilot Studio 旅行智能体被劫持
Tenable 的研究人员构建了一个处理旅行预订的 Copilot Studio 智能体，配置了明确的身份验证规则。通过提示注入，他们成功绕过了身份检查，以零价格预订了行程，并提取了其他客户的完整支付卡数据。问题出在智能体拥有宽泛的写入权限------它可以修改预订日期，也可以修改价格字段，而构建者并未意识到这些权限的实际范围。
四、为什么传统监控看不见它
ASI02 的隐蔽性来自三个事实：
-
工具是合法的。 没有恶意软件，没有可疑二进制，没有签名可匹配。
-
每次调用在日志里都显示为已授权。 认证通过，授权通过，API 返回 200。
-
重复会快速放大影响。 一次错误决策在智能体的重试循环中变成十次、百次错误执行。
系统看起来在做正常的自动化，直到你发现结果不对。而到那时，损害已经发生。
五、防御：让每次工具调用证明自己仍在任务范围内
OWASP 给出的防御框架可以概括为：不是移除工具，而是让工具使用在每一次调用中证明它仍然在批准的任务边界内。
1. 工具调用速率限制与幂等
围绕一个工作流、一个案例、一个任务设定调用预算。结合幂等键和一次性锁，阻止同一条退款路径反复触发。没有这一层，一个错误决策会变成多次错误执行。
2. 零信任工具参数
不信任工具参数，仅仅因为它来自模型。不信任它，仅仅因为它来自上游工具。每个参数在执行前都要经过形状、范围和目标验证。通配符拒绝，宽泛路径拒绝，开放式 shell 目标拒绝，超限交易参数拒绝。工具本身可能没问题，让它危险的是参数。
3. 工具链验证
安全地读取文件，紧接着发送到外部端点，就变成了外泄。无害的检查步骤，自动触发禁用或删除，就变成了破坏。执行前审查的是能力对和序列，而不是单个调用。ASI02 经常藏在编排里，而不是某一条明显恶意的命令里。
4. 即时权限
工作流在动作发生的那一刻获得所需的最小访问权限。权限是临时的，是有范围的，在调用完成后立即撤销。即使上游检查有疏漏，实时动作的扩展空间也很小。
5. 破坏性路径的人工审批门
删除、转账、重启、外部发布------这些动作必须在显式审批之后。真实工具不等于权限。 工具技术上能做某件事，不代表工作流现在做这件事是合适的。Replit 事件的核心教训正在于此：破坏性操作没有人类审批门，是灾难的直接原因之一。
6. 工具元数据是不可信输入
来自第三方 MCP 服务器或注册表的工具名称、描述和参数文档会进入模型上下文，可以携带指令。一个声称"优先级高于本地审计工具"的工具，是需要调查的信号，不是需要服从的命令。确认要求来自操作员策略，永远不来自工具自己的描述。
六、给开发者的底线清单
-
为每个工具定义最小权限画像，覆盖范围、速率上限和出口允许列表，由策略强制执行，而非临时约定。
-
授权按动作进行，不按会话进行。 第一次批准不等于后续四十次写入的通行证。长期授权是现实中最常见的缺陷。
-
将规划器和 LLM 输出视为不可信，在执行前经过策略执行点验证意图、强制 schema 和速率限制、签发短期凭证。
-
保持工具调用的不可变日志，持续监控异常执行速率和异常链式模式。
-
假设模型会犯错，设计成它犯错时也做不了太多。 工具使用的安全边界，不在于模型有多聪明，而在于它被允许多做多少事。
ASI02 排在 OWASP Agentic Top 10 第二位，传递的信号很明确：当智能体开始调用工具时，安全的核心从"模型会不会说错话"变成了"系统会不会用合法权力做错事"。 Amazon Q 和 Replit 的事件已经证明，合法工具、合法权限、合法调用，三者叠加仍然可以造成真实破坏。工具信任不够，执行信任必须被治理。