25个MCP服务器安全扫描：它们能对你的机器做什么

MCP 服务器并非你通过 HTTPS 调用的远程 API。对于构成主流流行服务器的 stdio 服务器来说，npx some-mcp-server 会下载代码并作为本地进程运行——带着你的 shell 环境、你的文件系统、你的网络。随后你的 agent 把指令交给那个进程执行。

这是一个正常的、有用的设计。同时也是一个没有人替你逐一列出的能力面（capability surface）。所以我做了测量。

方法（静态源码扫描——如实承认其局限性）

我拉取了 25 个流行的 Model Context Protocol 服务器包，对已发布的包代码（而非运行时行为）进行了四项静态扫描：

• net-call 站点——代码是否发起出站网络调用？
• secret-env 读取——是否从 process.env 读取凭证（例如 process.env.API_KEY）？
• 子进程 spawn——是否 shell 出去 / 派生子进程（exec 形态）？
• 捆绑二进制——包是否附带了预编译二进制文件？

静态扫描告诉你一个包可以触及什么，而非它在特定运行中实际做什么。process.env.API_KEY 的读取几乎总是服务器在加载自身的凭证——完全合法。重点不在于"这些是恶意的"。重点是你每次添加一个服务器时，在不知情的情况下所授予的聚合能力面。

25 个服务器的能力面

典型的多服务器 agent 设置会运行十几个本地进程，其中大多数读取你的环境并发起网络调用，部分可以派生子进程——全部以启动它们的 shell 相同的权限运行。没有任何安装步骤会呈现这些。没有目录列表会列出它们。

为什么对 agent 比对人类更重要

当你运行一个 CLI 工具时，你大致知道它做什么。当你的 agent 连接了一组 MCP 服务器然后在循环中行动时，爆炸半径是：每个服务器的能力 × agent 的自主性 × 循环运行的轮数。一个过度授权的服务器、一个包中一个被攻陷的依赖，process.env 中的凭证就只需一次网络调用就能离开你的机器——而就在不久前，*.amazonaws.com 这样的通配符在允许列表上会一路畅通，让它直达攻击者可命名的 S3 bucket。

你无法通过每次添加一个服务器时手动审计 25 个包来解决这个问题。解决之道是在沙箱中运行服务器（和 agent），默认拒绝文件系统 egress 和 secrets——使服务器的能力不再是 一种权威（authority）。

这正是 enclave 做的事情：一个面向 agent 的 Apache-2.0 沙箱化运行时，默认拒绝 egress 允许列表、secret 重写（redaction），以及一个 guard，阻止沙箱化进程重写自身的 guardrail。将使用 MCP 的 agent 指向它，上述能力面就变成了你显式授予的东西，而不是默认继承的东西。

如果你想要账本的另一半——同样这些服务器给每次请求增加的 token context 税（我测量了 544 倍的跨度，从 35 到 19,054 tokens/request）——那是 tokenscope：npx @wartzar-bee/tokenscope。

这些数字来自对 25 个已发布 MCP 服务器包的静态源码扫描；每个计数均可从包代码复现。这是能力的下限，而非对任何特定服务器行为的指控。