AI Agent的安全性正面临一个新兴且难以察觉的威胁：运行时盲点。大多数现有的安全扫描器在这一关键领域仍旧束手无策，无法有效识别“工具投毒”（Tool Poisoning）这类攻击。
近期，OWASP（开放式Web应用程序安全项目）已将MCP工具投毒明确分类为一种独立的攻击类别，这标志着业界对AI Agent独特安全挑战的日益重视。微软Defender团队也发表了题为《Plug, Play, and Prey》的报告，深入探讨了相同的问题。传统的Agent安全工具主要关注指令（prompts）、代码仓库（repos）以及工具定义（tool definitions）的扫描，却普遍忽视了工具响应可能被恶意利用的风险，即这些响应能够伪装成指令，诱导Agent执行非预期操作。
运行时信任鸿沟的根源：
两周前，我曾撰文指出MCP（Microservice Communication Protocol）如何成为AI工具的“USB接口”。该插件标准确实运作良好，但现在的问题是“数据线”中流动的内容。像Smithery这样的工具注册中心列出了超过7,000个公共MCP服务器。每一个服务器都能向模型提供自由文本内容，而这些内容都处于与文件系统、收件箱和写入操作相同的上下文窗口（context window）中。
这便是所谓的运行时信任鸿沟。OWASP在其报告中直接指出了这一点：“工具响应直接进入LLM（大型语言模型）的上下文，而没有任何等效的检查。”这句话是当前Agent安全领域中最为重要的一句话，它揭示了核心问题所在，并指明了亟待解决的方向。
盲点的具体表现：
大多数Agent安全工具的设计理念，是基于旧有的安全问题模型：扫描提示、扫描连接器目录、扫描依赖图，然后就认为万事大吉。这种模型假设危险源自输入端，但事实并非如此。当前扫描器能检查的内容包括：
- 提示内容和模板
- 工具定义和权限
- 已知的软件包CVEs
- 服务器名称和信誉
然而，它们在运行时却错过了以下关键环节：
- 工具输出流回上下文
- 连接打开后的响应路径
- 伪装成结构化数据的自由文本
- 模型将这些数据视为“计划”
如果一个外部工具将纯文本返回到与特权工具相同的上下文窗口中，模型并不会将其归类为“数据”，而是将其视为“上下文”的一部分。一个看似友好的响应，实际上可以指示Agent读取私有文件、推送分支或粘贴令牌。而Agent本身对工具之间的信任边界缺乏原生概念，这就构成了严重的安全隐患。
Invariant Labs率先在生产环境中展示了这一漏洞。他们的工具投毒通知演示了恶意MCP服务器如何将指令隐藏在工具描述中，这些指令对用户不可见，但对模型却清晰可见。随后，他们的GitHub MCP漏洞利用进一步升级：一个精心构造的GitHub Issue成功劫持了Agent，并将私有代码仓库内容泄露到一个公开的Pull Request中。这整个过程没有用户进行提示注入，也没有恶意软件包的参与，仅仅是工具响应“尽职尽责”地完成了它的“任务”。
应对策略：
一旦明确了攻击模式，赢家和输家便可预见。那些将特权工具与不受信任的外部工具进行隔离的团队将占据优势。同时，强制要求对具有破坏性行为的操作进行人工批准也是至关重要的防御措施。
