MCP 协议本身在「协议层不强制安全」,责任被显式分配到「主机—客户端—服务器」三层。其中主机是策略权威,客户端是策略执行者,服务器默认不可信;Anthropic 对接入官方目录的第三方服务器做上架审核,但不承诺对源码做安全审计,部署方的安全评估义务在协议文本与官方条款中都被写明,不是模糊地带。
一、协议层明确不强制安全
MCP 规范在多处写到:协议在协议层不强制安全机制,认证授权、令牌校验、来源校验等都需要在协议之外的实现层处理。这意味着:即便客户端与服务器都遵循协议,也不能默认「协议合规=安全」,需要部署方额外搭建 OAuth 2.1、令牌受众校验、来源校验等控制。这一原则决定了 MCP 的安全是「应用层责任」而非「协议层兜底」。
协议文档把责任分到三层:主机(Host,如 Claude Desktop、IDE)负责安全策略、用户同意、服务器白名单;客户端(Client)是协议层连接器,与服务器一一对应,只承担「握手与转发」职责,不替主机做策略;服务器(Server)默认不可信,提供的能力(工具、资源、提示)都需要被主机侧校验后才暴露给模型。
下面这张表把每层的职责与不可做的事都列清楚:
| 层级 | 可信度 | 核心职责 | 不可做的事 |
|---|---|---|---|
| 主机 | 完全可信 | 服务器白名单、用户同意、工具调用审批 | 把策略推给客户端或服务器 |
| 客户端 | 协议可信 | 能力协商、消息转发、保持 1:1 连接 | 跨服务器拼装请求、缓存凭据 |
| 服务器 | 默认不可信 | 暴露工具/资源/提示、声明能力 | 绕过主机审批、自行决定权限 |
把这张图记在脑子里,任何 MCP 部署方案的「谁来负责」问题都能在三十秒内对位。
二、Anthropic 的审查范围:上架审核而非源码审计
Anthropic 在 Connectors Directory 的官方政策中明确:目录收录的是「经过挑选的第三方 MCP 服务器」,团队对提交内容做初始与持续审查,可能要求开发者解决合规问题后才能保留收录资格。审查维度覆盖「安全、防护与兼容性」三项标准,并要求服务器持续符合使用政策与高风险用例要求。
这层审查不等于源码安全审计。BeyondScale 等第三方解读明确指出:Anthropic 在收录前对照上架准则做审核,但不对 MCP 服务器源码做安全审计,也不提供运行期安全保证,部署组织需独立完成安全评估。这与 Anthropic Connectors 政策中的合规检查是不同维度:前者偏「是否符合目录收录标准」,后者是「是否能在生产环境安全运行」。
Anthropic 的开发者条款还要求提交者(i)声明并保证对所提交服务器拥有所有必要权利且符合法规;(ii)同意赔偿 Anthropic 因服务器或用户交互产生的索赔;(iii)授权 Anthropic 对服务器做安全测试、收集功能元数据并与用户共享;(iv)实施漏洞接收机制并以合理谨慎调查。这些条款在合规侧强化了「服务器开发者担责」的取向,把运行期风险明确划到部署方与开发者一侧。
三、信任模型文档的硬性措辞
MCP 官方在 SECURITY.md 中给出明确的「信任模型」文档,核心是三条:
- MCP 客户端信任它连接到的 MCP 服务器,前提是用户或管理员按配置正确选择了该服务器;
- 本地 MCP 服务器像「用户主动安装的其他软件」一样被信任,运行它的用户要把它的访问范围视同自己账号的访问范围;
- MCP 服务器信任它所在的执行环境,服务器能访问哪些资源由运行环境决定,这意味着容器化、最小权限、隔离目录是部署方的硬性要求。
同一份文档还把几类行为明确归为「非漏洞」:STDIO 传输启动子进程是设计意图、文件读写与 git 命令是服务器「本职工作」、LLM 自行决定调用哪个工具属正常行为。这意味着提交到 HackerOne 的「任意命令执行」「服务器能改文件」类报告,通常不会被认定为可奖励漏洞,因为它们在协议信任模型内属于预期行为。
理解这一点对部署方很关键:既然协议不把这些列为漏洞,那防护就不能依赖「上游打补丁」,而必须自己在主机侧用白名单、沙箱、最小权限把这些行为卡死。
四、责任边界的工程落地
把责任模型落到工程,主机侧需要四件套:服务器白名单、用户同意 UI、工具调用审批、SIEM 日志接入。客户端侧需要按协议实现能力协商与转发,不要替服务器缓存凭据。服务器侧需要把工具描述、参数 schema、错误处理都写完整,并假设「客户端可能传恶意输入」,在服务器端做严格 schema 校验与 SQL/命令参数化。
容器化是承载这套模型的物理层。一个常见的反模式是把 npx -y @modelcontextprotocol/server-filesystem / 写进配置,这等于把整块磁盘交给服务器,违反最小权限。生产配置应把参数里的路径限定到当前项目目录,配合容器 bind mount,即便服务器有漏洞也越不出 mount 范围。远程 MCP 服务器则应使用 OAuth 2.1 + PKCE,并校验 token 的 audience 声明,只接受发给自己的令牌。
下面给出一段典型的服务器启动配置片段,展示如何用容器化 + 受限路径来落地「最小权限」:
{
"mcpServers": {
"filesystem": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-v", "${WORKSPACE}:/data:ro",
"mcp/filesystem:latest",
"/data"
]
},
"remote-tool": {
"url": "https://mcp.example.com/v1",
"auth": {
"type": "oauth2.1-pkce",
"audience": "https://mcp.example.com"
}
}
}
}这段配置把宿主机工程目录以「只读」形式 bind mount 进容器,服务器进程只能看到挂载的子目录;远程调用走 OAuth 2.1 + PKCE 并校验 audience,避免凭据被串用到其他服务。生产环境还应在容器运行时加 --read-only、--security-opt=no-new-privileges、--pids-limit=256 等限制,把进程级风险也卡死。
日志侧需要把工具调用、参数、用户、会话都记录并接入 SIEM;对「写、删、扣款、触达生产」等高风险动作默认拒绝,需用户显式确认才执行。这些是责任模型从「写在文档里」过渡到「运行时能观测、可回溯」的关键动作。
五、常见误读与纠正
误读一:「Anthropic 收录=安全」。实际只是通过目录上架标准的合规检查,不是源码审计,部署方必须独立评估。误读二:「协议合规=安全」。协议层不强制安全,OAuth、令牌校验、SSRF 防护、prompt 注入扫描都是协议外的实现层责任。误读三:「容器化就够了」。容器只提供文件系统与进程隔离,网络策略、seccomp、AppArmor、依赖签名仍需配套。
把这三条记在部署手册的第一页,就能避免把责任模型误当成「上游兜底」。Anthropic 的角色是协议维护者与目录运营方,不是部署方的安全承包方,这一定位在条款与安全文档里都写得很清楚。
常见问题(FAQ)
Q1：协议层不强制安全,那协议本身还安全吗？
协议只定义消息格式与能力协商,认证授权需在协议外的实现层处理。
Q2：Anthropic 对第三方 MCP 服务器做源码审计吗？
目录收录前做上架审核,不对源码做安全审计,部署方需独立评估。
Q3：服务器侧还需要做输入校验吗？
必须做,协议信任模型明确服务器默认不可信,客户端传来的参数必须按 schema 严格校验。
