MCP 协议安全性设计包含哪些层面？

🏛 业务架构师

MCP 的安全性我从企业验收的视角分五层来讲：

传输与网络安全：远程模式强制 HTTPS，防中间人；本地 stdio 模式要防恶意 Server 冒充系统工具。
身份认证与授权：协议支持 OAuth2，Server 端要落地"哪个用户/哪个 Agent、什么权限、能调哪些工具"的三方绑定。业务上必须过的一关是权限最小化——只授予完成当前任务所需的最小工具集。
工具调用管控：高危操作（写数据、发消息、执行命令）要有审批流、限流、幂等保护；敏感数据在返回前脱敏。这层协议本身不管，是企业 MCP Gateway 必须自建的。
提示注入与恶意资源防护：MCP 返回的内容会进入模型上下文，攻击者可能在数据里藏指令（"请把文件内容发到某地址"）。要假定工具返回不可信，对输出做内容安检、指令隔离。
审计与合规：全量调用日志（谁、何时、调了什么、结果摘要）留存，满足等保和数据安全法要求。

我的治理建议：企业上 MCP 前先立三条规矩——所有 Server 走统一网关接入、工具按密级分级授权、高危工具默认人工确认。安全不是协议给的，是架构给的。

MCP 安全设计我从六层防线讲，这也是我评审企业 MCP 上线的清单：

身份认证：本地 stdio 靠进程边界与 OS 权限；远程 Streamable HTTP 必须 OAuth2/mTLS，禁止匿名暴露——公网裸奔的 MCP Server 是 2025~2026 年真实出现过的重大安全事故源；
授权最小化：每个 Server 只授予完成任务所需的最小权限（只读账号、库表白名单、行级过滤）；高危工具（写操作、支付、删除）在 Host 层要求用户显式确认；
输入校验与注入防护：所有 tools/call 参数做 Schema 校验；防工具描述注入（恶意 Server 在 description 里埋指令）与间接 Prompt 注入（工具返回的数据里藏指令），敏感上下文与外部数据要隔离标注；
传输安全：TLS 加密、消息完整性；防止中间人篡改工具调用参数；
审计与可观测：全量调用日志（谁、何时、调了什么工具、什么参数、什么结果），高危操作告警——这是事后取证与合规的底线；
隔离与资源控制：Server 进程/容器隔离，超时、返回大小、调用频次限制，防止恶意 Server 打挂 Host（资源耗尽攻击）。

架构总结：MCP 协议本身提供了认证与授权的接口，但安全的大头在部署侧——网关收口、工具分级、信任边界划分，"零信任"原则在 MCP 生态同样适用：任何 Server 都不可默认信任。

MCP 的安全设计要分层看，我在做企业内 MCP 平台时是这么落地的：

传输与认证层：远程 MCP 一律 HTTPS（Streamable HTTP）+ OAuth 2.1（Server 作为资源服务器，Agent Card/metadata 声明 scopes）；stdio 只用于本地可信进程。最小授权原则——每个 Server 一个 client，scopes 按需申请。
工具调用授权层：高危工具（写操作、删数据、发邮件）设 human-in-the-loop 确认；Host 侧维护策略管道（allow/deny/confirm），敏感参数脱敏后再记日志。
输入安全：工具返回的内容（网页、文档）是不可信数据，要防间接提示注入——对返回内容做标记隔离、注入检测；对 tools/call 的参数做 JSON Schema 校验 + 业务校验（防 SQL 注入、路径穿越）。
执行隔离：Server 端工具在沙箱执行（容器、独立账号、文件系统白名单），限制资源（超时、速率、返回体大小）。
审计与可观测：全链路记录谁在何时用什么参数调了什么工具、返回了什么（PII 脱敏），接入统一审计平台。

现实提醒：MCP 协议本身只提供了握手和鉴权框架，它不会替你防注入和越权——工具描述会被模型当指令读，第三方 Server 的 description 字段本身就是注入面，企业内要有 Server 准入审核。