MCP 鉴权与安全：你的 MCP Server 可能正在裸奔

上个月我写了一个 MCP Server 给团队用，加了 Streamable HTTP 传输层，跑在办公室内网。第二天运维大叔跑来问我：你这服务怎么谁都能调？

我一查，慌了。没有鉴权，没有白名单，任何一个能访问内网的人都可以往我的 MCP Server 发请求，调工具、读资源，全裸奔。

MCP 协议从设计上就没考虑过鉴权。它的默认传输层 stdio 走标准输入输出——只有你本地能启动的进程才能用它，自然不需要鉴权。但一旦你把它搬到网络上——无论是 SSE 还是新的 Streamable HTTP——安全就变成了你的问题。

官网给的说法也很直白：“MCP 目前不实现任何认证或授权机制。”

MCP 安全到底缺什么

MCP 协议的安全假设很简单：传输层安全由你负责。但实际落地时，问题集中在三个层面：

1. 没有身份验证

MCP 的 initialize 请求里有一个 capabilities 字段，声明服务端能干什么。但它不做身份校验——任何人发了 initialize，服务端都会回复“你好，我可以调用这些工具”。有人能连上就意味着有人能用你的所有工具。

2. 工具调用没有权限分层

你写了一个 list_files 工具和一个 reboot_server 工具。在 MCP 的模型里，它们都是平等的 tool——没有“只读操作不需要鉴权、危险操作需要二次确认”这种区分。客户端能调用所有工具，或者一个都不能调。

3. 资源访问范围不可控

你的 MCP 服务端暴露了一个资源路径 documents://reports/public 和一个 documents://internal/hr。客户端一旦连接就能访问所有已注册的资源模板，你的代码没法在协议层说“这个资源只有管理员能读”。

你的 MCP Server 暴露了什么

拿我那个裸奔的 Server 举例