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

MCP——让智能体使用工具的协议——火得太快，安全根本没跟上。研究人员用一个 proof-of-concept 包污染了 11 个公开 MCP 注册表中的 9 个，而对 1,899 个 MCP 服务器的审计发现约 5% 已经携带隐藏的恶意指令。如果你的智能体连接第三方 MCP 服务器，你就添加了一条供应链——你得把它当供应链来对待。

- **Author:** Fedor Chishchin
- **Published:** 2026-06-23
- **Tags:** security, agents, mcp
- **Source:** https://fedorthinks.com/zh/blog/your-mcp-servers-are-a-supply-chain

---

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

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

## 「Tool poisoning」是新的 typosquatting

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

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

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

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

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

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

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

## 底线

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

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