MCP 协议很火，但它的安全问题比你想象的严重

最近在搞 MCP 相关的东西，一开始觉得这协议真香——把 AI 模型和外部工具连起来，API 标准化，生态繁荣得很。然后我越看越不对劲。
MCP 的架构其实挺规整的：host（宿主应用）、client（客户端）、server（服务端）三层，通信走 JSON-RPC 2.0，可以通过 stdin/stdio 或者 SSE 两种方式。分层清晰，接口定义明确。但问题不在架构上，在权限模型上。
MCP server 一旦连上 host，基本上想干什么就能干什么。读文件、写文件、执行命令、访问内网——全看 server 自觉。没有作用域限制、没有细粒度权限控制、没有沙箱隔离。我翻译一下：这相当于你请了个装修工来刷墙，结果他把整栋房子的钥匙都拿到了。
我举一个实际场景。你装了一个 MCP server 来管理 GitHub Issues，它的本职工作就是读写 issue 对吧？但如果这个 server 被恶意利用，它可以顺手读你本地的 SSH 密钥、执行任意 shell 命令、往你的内网服务发请求。MCP 协议里没有任何机制阻止它。不是"防不住"，是压根没设计这层防护。
我翻了几个热门 MCP server 的实现，发现大多数都把能力声明得相当宽泛。拿某个文件系统操作的 server 来说，它的工具列表里写着 read、write、search、get_file_info，但 host 端根本不会限制 server 只能访问某个特定目录——server 自己说能读哪儿就写哪儿，host 全盘信任。
这还不是最让人头疼的。真正麻烦的是工具链传播。你从 npm/pip 装了一个第三方 MCP server，它依赖了另一个包，那个包又被植入了恶意代码——这套供应链攻击的戏码在 npm 生态里已经演过无数次了，现在 MCP 又复制了一遍。而且 MCP server 的权限比普通 npm 包大得多，因为它能直接对接 host 的系统能力。一个被污染的 MCP server，就等于在开发者的机器上开了一个后门。
那有没有解法？行业里几个方向在讨论。
一个是权限声明机制。server 启动时声明它需要什么能力，host 按最小权限原则授权——类似手机 app 的权限弹窗，你需要读文件？host 弹个窗让用户点头。这个方案看着简单，但实现起来有坑：MCP 的工具是动态组合的，你很难在启动时精确预测后面会调什么方法。
另一个方案是沙箱执行。在容器或者 sandbox 里跑 MCP server，限制系统调用和网络访问。Deno 的权限模型和 Cloudflare Workers 的隔离机制可以参考——默认不信任，需要什么权限得申请。代价是性能开销和部署复杂度，但对比安全收益，我觉得值。
还有就是内容安全策略。server 返回的数据应该经过校验和脱敏，不能直接把用户文件内容原样发给 LLM。试想一下，如果你的代码里恰好有数据库密码，MCP server 读文件的时候顺手就把敏感信息送出去了——这不是 server 坏不坏的问题，是协议层面就没考虑这块。
Google Vertex AI 和 Anthropic 的参考实现里已经有了一些安全设计，但距离成熟还差得远。MCP 目前还在协议规范的快速迭代期，安全问题还没被提到最高优先级。我问了几个用 MCP 搭工具的朋友，大家态度出奇一致：“知道有风险，但先跑起来再说。”
说句实话，MCP 是我这两年看到最有想象力的 AI 基础设施协议之一。它认真解决了工具互联的标准化问题，生态也在快速增长。但安全这个短板太明显了。希望在协议还没完全定稿之前能把权限模型补上。不然等 MCP 成了事实标准再回头修安全，就跟现在给 HTTP 补上 HTTPS 一样——知道该做，但动起来就难了。