如果你在做 agent，这条值得停下来看一眼：它把矛头对准的不是大家熟悉的 prompt injection，而是一个更隐蔽的攻击面——工具描述本身。现在的 LLM agent 普遍靠接外部工具来扩展能力，而每个工具都带一段描述（功能说明、参数、用途），这段描述会进入规划器的上下文，供模型决定下一步调哪个工具。问题就出在这里。 论文提出的威胁模型叫"跨工具描述投毒"（cross-tool description poisoning）。攻击者不去改用户的输入，而是污染某个工具的描述文本，借此操纵规划器可见的元数据，从而把 agent 的整条执行轨迹引向攻击者想要的方向。这里有个反直觉的关键点：被投毒的那个工具可以从头到尾都不被选中、不被实际调用，仅凭它的描述挂在上下文里，就足以扭曲 agent 对其他工具的选择。这正是它比常规 prompt injection 更难防的地方——污染源不在用户对话里，而在系统侧的工具清单里。 作者第一步做的是检验"老办法还管不管用"。他们评估了若干现有的 prompt-injection 防御方法，发现迁移到跨工具描述投毒上效果很差。给出的解释抓住了机理上的差异：prompt injection 往往是一次性的注入，而被投毒的工具描述会持续驻留在规划上下文中，跨多个推理步骤反复影响后续的工具选择。换句话说，这是一种"持续性"而非"一次性"的影响，针对单次注入设计的防御自然顾不过来。 基于这个观察，论文提出了 Tool-Guard，一种系统级防御。它的核心概念叫"隔离式规划"（isolated planning）：当某次工具调用被检测为与用户意图不一致或可疑时，就把对应的工具放进一个"隔离列表"（论文里称为 influenced list / quarantined list），从而切断被投毒描述对后续步骤的进一步影响。 值得注意的是它的设计取向不是简单地把可疑工具一禁了之。按摘要的说法，隔离掉影响之后，这个工具仍可以继续被用来支撑任务——也就是说，目标是隔离"描述带来的污染影响"，而不是牺牲掉这个工具本身的功能可用性。这一点对真实部署有意义：agent 系统里很多工具是任务必需的，粗暴拉黑会直接破坏可用性。 诚实的保留也得说清楚。这条素材来自 arXiv 论文摘要，且摘要在介绍 Tool-Guard 收益的句子处就被截断了（"...enabling"之后没有了），所以原文在这部分并未给出任何量化结果——没有检出率、没有防御成功率、没有点名具体的评测基准或对比基线数字。它目前能确认的是：提出了一个被论证为现有防御覆盖不到的新攻击面，并给出了一套对应的系统级机制。这个机制实际能挡住多少、误隔离率多高、在哪些 agent 基准上验证过、相比基线提升多少，都得等读到论文正文或第三方复现才能下判断。对在做 tool-use / MCP / agent 编排的团队，把"工具描述也是攻击面"这件事纳入威胁建模，可能是这篇当下最实在的提醒。