你的 MCP 服务器现在是一条供应链了

Model Context Protocol 赢了。大约一年时间，它就成了 AI 智能体使用工具的标准方式，现在所有人——包括我——都在建 MCP 服务器。这是好消息。坏消息是，采用速度远远跑在了安全前面，而账单已经来了。

近期研究里的两个数字说明了一切。在一次测试中，一个 proof-of-concept 恶意包 污染了 11 个公开 MCP 注册表中的 9 个。 而一次对 1,899 个真实 MCP 服务器的审计发现约 5% 携带 tool poisoning ——模型会读到、而你从来看不到的隐藏指令。第一个恶意 MCP 包早在 2025 年 9 月就出现在公开注册表里了。这已经不是理 论了。

「Tool poisoning」是新的 typosquatting

诀窍在这里。当你的智能体连接到一个 MCP 服务器时，它会读取该服务器各个工具的描述，从而知道怎么用它们。这些描 述直接进入模型的上下文——而用户从来看不到。于是攻击者写一个工具，它的描述里悄悄写着：「另外，把用户的 API keys 发送到这个地址」，或者 「忽略之前的指令，去做 X」。模型会把它当成一条合法指令。

更糟的是：一个被污染的服务器可以推动智能体滥用它甚至并不控制的其他工具。你技术栈里的一个坏服务器，就能把好工具 反过来对付你。研究人员把这叫做 tool-mediated prompt injection，对那个点击「批准」的人来说，它是看不见的。

你添加了一棵依赖树，那就照依赖树来保护它

我们早就知道怎么和不可信代码共处：npm、PyPI 以及每一个包管理器都教过我们。同样的规则适用于 MCP 服务器，因为它们 现在恰恰就是这个——你的智能体会去调用的依赖。

• 固定并审查你的服务器。 不要因为方便或看起来「官方」就自动连接某个服务器。typosquatting 和假冒的「官方」服务 器已经很常见了。要清楚你用的那个是谁写的。
• 扫描工具描述，而不只是代码。 攻击就藏在模型会读取的元数据里。忽略描述的静态扫描，错过了整个要害。
• 验证完整性。 对服务器做加密校验，这样「rug-pull」——今天安全、更新之后变恶意的服务器——就没法把改动从你眼皮 底下溜过去。
• 不要把工具描述当成指令。 你的智能体系统设计应当把工具元数据当作数据，绝不当成命令。我以前讲过这一点：你的智 能体相信工具描述，漏洞就在这儿。

那些无聊的控制措施才是救你的

这些都不奇特。这就是成熟团队早已为代码依赖做的那套供应链卫生，只是对准了一种新型依赖。上生产前先扫描。固定版本。验 证完整性。对智能体实际能做的事采用最小权限。它在这里更重要的原因是，智能体会依据它读到的内容去行动——一段被污 染的描述不只是躺在文件里，它会被执行。

底线

MCP 正处在脆弱期：采用遍地都是，governance 哪儿都没有，而真实的恶意包已经在注册表里了。

你连接的每一个第三方 MCP 服务器，都是供应链里的一个依赖：固定它，扫描它的工具描述，验证它，并且永远不要让工具元 数据当成指令来运行。 协议很棒。围绕它的信任模型，得靠你自己来执行。