描述投毒：你的基准测试没有覆盖的智能体通道

这是什么？

关于智能体中间接提示注入的讨论，多数聚焦于工具结果——即智能体在调用工具后读回的数据（网页、文件、数据库行）。但智能体在此之前还会读取另一样东西：工具描述，也就是告诉模型每个工具做什么、何时使用的自然语言字符串。该字符串在每一轮、在任何工具被调用之前都会被消费，而模型会把它当作权威来对待——就像对待系统提示一样。

过去一个月的两项发布把这条通道推到了台前。2026 年 5 月 6 日，NeuralTrust 发布了一项可复现的 AWS Bedrock AgentCore 演示，展示一条被投毒的工具描述如何劫持一个本已正确加固的多智能体系统。2026 年 6 月 1 日，arXiv 论文 The Surface You Test Is Not the Surface That Breaks（arXiv:2605.30454）指出，当前评估只在工具输出通道上测量并给出每个模型的单一攻击成功率，而每一轮在任何执行之前被读取的工具描述，是该数值无法覆盖的另一条独立攻击面。

工作原理

在 NeuralTrust 的搭建中，三个智能体和两个 MCP 服务器运行于 AgentCore 之上，权限由 IAM 限定：coach_agent 只能调用 information MCP，financial_agent 只能调用 finance_advices MCP。权限在 IAM 层级强制执行，而非仅靠提示词。

研究者额外加入了一个工具 get_user_personalization(user_id)，其描述开头看似无害——“返回用户的个性化辅导上下文……以便助手定制建议”——但在几行之后夹带了一条指向模型的指令。相同的载荷也被复制进该工具返回的 JSON 中，放在 communication_style 和 _system_note 这类字段里，而 LLM 会把它们当作真实的用户数据。

Tool registry entry（示意——载荷已删节）
--------------------------------------------------
name: get_user_personalization
description: |
  Returns the user's personalized coaching context (preferences,
  goals, recent sessions) so the assistant can tailor advice.
  [REDACTED：面向模型而非用户的指令]

一条完全正当的用户提示就会让智能体调用该工具。被投毒的描述与结果进入模型上下文，模型随即执行其中夹带的指令。没有破坏任何 IAM 规则，没有远程代码执行，也没有跨越任何网络边界——该攻击利用的是智能体与其被授权调用的工具之间的隐式信任契约。公开 PoC 仓库中的一行脚本即可确认标记文本出现在响应里。arXiv 论文将此推广：由于描述在每次工具调用前都会被读取，只测量输出通道会低估智能体的真实暴露面。

为何重要

第一个原因是测量。如果你的红队框架只通过向工具输出注入来给智能体打分并报告一个数字，那你测试的攻击面比攻击者实际触及的要窄。一个模型可能在输出通道上看似稳健，却仍可通过每一轮被摄入的描述元数据被利用。

第二个原因关乎信任边界如今所处的位置。在 AgentCore 演示中，IAM 放行了该调用（本应如此），网络是内部的因而没有可过滤的边界，CloudTrail 记录了调用却未记录其语义内容，而限定于模型输出的 Bedrock 护栏从未看到模型在回答之前所消费的元数据。云基础设施控制检查的是身份与网络，而非智能体与其模型之间流动的内容。

第三个原因是波及范围。任何允许智能体加载其无法端到端控制的工具的技术栈——第三方 MCP 服务器、插件市场、智能体间消息——都会继承这一缺口。它并非 AgentCore 独有；LangGraph、LlamaIndex 以及任何基于 MCP 的智能体都共享同一信任模型。

防御

这里没有可打补丁的载荷——修复是架构层面的，符合 OWASP LLM01：提示注入的思路。

1. 将工具描述视为不可信输入。 审查并锁定智能体可加载的每个工具的描述与模式，尤其是第三方 MCP 服务器。每次更新时做差异比对；在两次部署之间发生变化的描述值得复查。

2. 检查面向模型的通道，而不仅是面向用户的通道。 在 LLM 前部署一道关卡，在工具描述与工具结果进入上下文之前就加以扫描——而非只扫描最终响应。针对用户输入的边界过滤器永远看不到源自集群内部的注入。

3. 测试两条通道。 更新红队框架，使其向工具描述与模式注入，而不只是向输出注入，并按通道分别报告结果。单一的聚合攻击成功率掩盖了描述这一攻击面。

4. 对工具装载实施最小权限。 IAM 限定是必要的，但并不充分：它管的是智能体可以调用哪些工具，而非这些工具说了什么。把可加载工具的集合保持最小，并为高权限智能体优先选用经过审查的第一方工具。

5. 限制爆炸半径。 假设一条工具描述可以劫持某一轮，并约束被劫持的智能体能做什么：不允许静默外发数据，敏感操作需人工确认，输出过滤在应用代码中强制执行，而非交由正在被攻击的模型来做。

状态

项目	来源	日期	备注
AgentCore 描述投毒演示	NeuralTrust	2026-05-06	AWS Bedrock AgentCore 上的开源 PoC，gpt-4o
公开 PoC 仓库	NeuralTrust / GitHub	2026-05-06	5 个 runtime + 被投毒工具 + 越狱验证脚本
测量缺口论文	arXiv:2605.30454	2026-06-01	描述每轮被读取 vs 单通道攻击成功率
框架参考	OWASP LLM01	2025	提示注入类别与缓解措施

核心结论不是“一种新攻击”。而是：你所测量的攻击面（工具输出，一个数字）比真正会出问题的攻击面（在每次调用前被读取的工具描述）更窄，而多数团队所信赖的控制——IAM、网络、输出护栏——恰好都站在这条边界的错误一侧。