微软警告：被投毒的 MCP 工具描述可诱使 AI 代理泄露数据

微软最新研究显示，攻击者只需使用被投毒的工具描述，就能劫持代表用户执行操作的 AI agents，让 agent 悄悄把公司数据交给外部人员。

诀窍在于，agent 从来没有违反任何规则。每一步看起来都很正常，所以在默认设置下，可能不会触发任何警报。

这项工作来自 Microsoft Incident Response 和其 Defender security research team，而它出现之际，正值公司开始让 AI 做的不只是阅读和总结。

当 agent 能执行操作时，会发生什么

直到最近，职场 AI 风险主要还是围绕模型读取和写入的内容来讨论。被投毒的文档可能会让答案偏离，但大致也就止于此。

agent 不一样。Microsoft 365 Copilot 可以发送电子邮件、创建文件并更改日历。构建于 Copilot Studio 或 Azure AI Foundry 的自定义 agent，可以深入业务系统并自主运行多步骤任务。

同样的注入技巧，过去只是让摘要产生偏差，如今却会触发动作。对于阅读者，攻击改变的是输出；对于 agent，攻击改变的是软件实际执行的内容。

这些 agent 通过 MCP，也就是 Model Context Protocol，接入业务系统。MCP 是一种开放协议，让 AI 像应用调用 API 一样调用外部工具。微软称它是 agentic AI supply chain 中增长最快的部分，这也使其成为不断扩大的攻击面。

攻击是如何运作的

每个 MCP 工具都会附带一个 description：也就是几行纯文本，告诉 agent 这个工具做什么，以及何时使用。agent 会读取这些文字来决定如何行动。弱点就在这里。description 只是文字，而文字可以携带指令。

微软用一个发票示例来说明这个过程，目的是展示这种模式，而不是报告某个已具名受害者。一个财务团队部署了一个 agent 来处理供应商发票。它连接了三种工具，其中包括一个第三方的“invoice enrichment”服务，该服务已获准使用，但从未接受过真正的安全审查。

随后，攻击者更新了那个第三方工具。名称和可见摘要都保持不变。但在 description 里，伪装成格式说明的隐藏命令要求：抓取最后三十张未支付发票，并把它们附加到下一次调用中。MCP 会即时接收 description 的变化。在没有重新批准触发机制的环境中，被投毒的版本会直接上线，无需额外审查。

之后，一名分析师询问了一个关于某供应商的常规问题。agent 按照隐藏命令行事，收集发票，并把它们作为一个看起来很正常的请求的一部分发送出去。该工具返回了干净的答案，并悄悄把被盗数据复制到攻击者控制的服务器。分析师看不出任何异常。

agent 做出的每个动作单独来看都是合法的。该工具已经获批。数据查询是以分析师自己的权限运行的。外发连接指向一个在加入时被允许的服务器。弱点并不在任何一个单独系统里。它存在于微软所称的“它们之间的 trust boundary”中。

更深层的问题在于，MCP 把指令和数据混在同一个地方。工具的 description 存在于 agent 的工作记忆中，紧挨着其真实指令，因此编辑该 description 的效果，就像改写 system prompt 一样，足以改变 agent 的行为。

agent 没有可靠的方法分辨一条诚实的指令，和由工具维护者偷偷塞入的恶意指令。微软指出，这不是 Copilot 本身的 bug，而是因为接入外部工具而打开的 trust gap。

防御者应该怎么做

微软的建议，简化成直白的话来说：

把每一个已连接工具都视为供应链的一部分。维护一份获批工具发布者清单，关闭“allow all”，并且只让 agent 使用它实际需要的特定工具。

把工具的 description 当作 system prompt 来看待。像审查代码变更一样审查它的改动，并扫描文本中是否存在不该出现在帮助字段里的命令。

把人工审核放在高风险动作前面。任何会转移资金、向公司外共享数据或更改账户的操作，都应当需要人工批准。

为每个 agent 分配独立身份，并监控它的行为。记录它的动作，为正常行为建立基线，并标记新的 endpoint、更大的数据拉取或异常查询。

应用 least agency，而不仅仅是 least privilege。即使是低权限 agent，如果被允许在没有检查的情况下行动，也可能造成实质性伤害。

微软把自家的产品映射到每一步，包括 Prompt Shields、Purview DLP、Entra Agent ID、Defender for Cloud 和 Sentinel，但无论你运行什么技术栈，这些原则都适用。

不是理论：我们如何走到这一步

这类攻击是有文献记录的。Invariant Labs 在 2025 年 4 月提出了“tool poisoning”这一说法，并给出了一个概念验证：它把指令隐藏在 calculator tool 的 description 中，成功让 Cursor editor 读取用户的私密 SSH key 并发送出去。开发者 Simon Willison 在几天后深入研究了这件事。

同一团队后来又展示了一个相关技巧：一个恶意 GitHub issue 可以劫持连接到 GitHub MCP server 的 agent，并把私有 repositories 中的数据带走。那里的工具本身是受信任且未被改动的；恶意指令是随着 agent 读取的数据一起传入的。

OWASP 现在已将该案例列为 Agentic Supply Chain Vulnerabilities 示例，收录在其 2025 年 12 月的 Agentic Applications Top 10 中。

类似的供应链故障在真实环境中已经发生。2025 年 9 月，Koi Security 的研究人员发现了一个名为 postmark-mcp 的 npm package。它在 1.0.16 之前的十五个干净版本里，镜像了一个合法的电子邮件工具；到了 version 1.0.16，却悄悄加入了一行代码，把 agent 发送的每封 email 都秘密 BCC 给攻击者。Koi 将其称为首个真实世界的恶意 MCP server。

学术界也开始对这个问题进行量化。MCPTox benchmark 于 2025 年 8 月发布，它对 45 个真实 MCP servers 和 20 个领先的 AI models 测试了被投毒的工具描述。结果发现这类攻击广泛有效，成功率高达 72.8 percent，而这些模型几乎从不拒绝。

贯穿始终的结论，就是微软现在强调的这一点。能够执行操作的 AI，其可信度只取决于你允许它接触的工具；而眼下，这些工具很容易被投毒，也很难被监控。