一、执行摘要

MCP（Model Context Protocol，模型上下文协议）由 Anthropic 于 2024年11月推出，是连接 LLM 与外部工具、数据源的标准化协议，被业界形象地比喻为"AI 的 USB-C 接口"[1]。随着 MCP 在 2025–2026 年被广泛采用，其安全体系经历了从"可选认证"到"企业级纵深防御"的快速演进。

核心发现

1. 授权框架：MCP 基于 OAuth 2.1 构建，强制使用 PKCE、资源指示器（RFC 8707）、受保护资源元数据（RFC 9728），构建了从身份颁发到令牌管理的完整体系[2]。

2. 威胁模型：OWASP 于 2025 年发布 MCP Top 10 风险清单，覆盖令牌管理不善、工具投毒、提示注入、影子服务器等十大关键威胁[3]。

3. 前向防御：学术界提出 MCP-Guard 三层检测流水线，在对抗性提示检测上达到 96.01% 准确率[4]。

4. 密码学安全：IETF 发布 MCPS 草案（draft-sharif-mcps-secure-mcp），引入代理护照（Agent Passport）、逐消息签名、工具定义完整性保护[5]。

5. 企业实战：Red Hat、Microsoft、Anthropic 等已推出企业级安全方案，而国内腾讯云、阿里云也在快速跟进 MCP 安全能力建设6[8]。

二、MCP 安全架构总览

2.1 架构角色与攻击面

MCP 定义了三个核心角色[2]：

• MCP Host：AI 应用程序（如 Claude Desktop、Cursor、IDE 插件）

• MCP Client：连接一个或多个 MCP 服务器，向 LLM 传递工具定义

• MCP Server：暴露工具、资源和提示的轻量级程序

独特攻击面：OWASP 指出，LLM 在其上下文中看到所有已连接服务器的所有工具描述——这是理解跨服务器攻击的关键[1]。与传统的 API 不同（开发者控制每次调用），MCP 让 LLM 决定调用哪个工具、何时调用、使用什么参数。

2.2 安全设计原则

2.3 MAESTRO 威胁建模框架

arXiv 论文[10] 提出了 MAESTRO 框架，将 AI 系统的威胁建模为七层：

• L1–L3：基础模型层（模型权重、训练数据、推理）

• L4：Agent 框架层

• L5：工具集成层（MCP 协议所在层）

• L6：多 Agent 编排层

• L7：Agent 生态系统层

三、身份颁发与认证

3.1 MCP 官方授权框架

根据 MCP 规范（2025-11-25 版）[2]，授权框架定义了以下安全机制：

角色定义：

• 受保护的 MCP 服务器：充当 OAuth 2.1 资源服务器

• MCP 客户端：充当 OAuth 2.1 客户端

• 授权服务器：负责与用户交互，签发访问令牌

授权服务器发现（三层元数据发现）：

1. MCP 服务器必须通过 RFC 9728（受保护资源元数据）公布授权服务器

2. 授权服务器必须提供 RFC 8414（授权服务器元数据）或 OpenID Connect Discovery

3. 客户端必须同时支持两种发现机制

客户端身份注册[2]：

• 客户端在发起授权前必须通过以下机制之一获取 client_id：

  • Client ID Metadata Documents (CIMD)：推荐方式（SEP-991），客户端托管静态 JSON 元数据文件于 HTTPS URL

  • 预注册：事先在授权服务器注册

  • 动态客户端注册 (DCR, RFC 7591)：已被弃用，仅保留向后兼容

Red Hat 观点[6]："DCR 给服务器带来了管理无界客户端数据库和信任自声明元数据的沉重负担，社区正转向 CIMD 作为推荐的默认方式。"

3.2 令牌体系

令牌结构：基于 JWT（RFC 7519），包含以下标准声明[11]：

令牌安全要求（官方规范[2]）：

• 客户端必须使用Authorization: Bearer <token>请求头

• 严禁在 URI 查询字符串中包含访问令牌

• MCP 服务器必须验证访问令牌是专门为自己签发的（audience 验证）

• 服务器不得接受非其关联授权服务器签发的令牌

• 客户端不得向 MCP 服务器发送非其关联授权服务器的令牌

3.3 多因素认证 (MFA)

腾讯云开发者社区的技术深度文章[12] 给出了完整的 MFA 实现方案：

三类认证因素：

• 知识因素：密码、PIN 码

• 持有因素：手机、硬件令牌、U 盾

• 生物因素：指纹、面部识别、虹膜识别

MFA 支持类型：SMS、EMAIL、TOTP（基于时间的一次性密码）、PUSH 推送通知、BIOMETRIC 生物特征验证

安全机制：

• 挑战 5 分钟过期

• 最多 3 次验证尝试，超过则删除挑战

• 全日志记录所有挑战的生成和验证

3.4 OIDC 企业集成

Red Hat 方案[6]：推荐将认证委托给外部 OAuth/OIDC 提供者（如 Keycloak），MCP 服务器仅充当 OAuth relying party。这遵循了"不要自己构建 OAuth 提供者"的安全最佳实践。

Microsoft 方案[9]：支持外部身份提供者（如 Microsoft Entra ID）集成，好处包括：

• 消除自定义认证的漏洞风险

• 利用企业级 IdP 的高级安全功能

• 继承多因素认证和条件访问策略

• 简化用户生命周期管理和合规审计

Anthropic 方案[8]：2026年6月推出企业级托管授权（Enterprise-Managed Auth），管理员通过 IdP 一次性授权连接器，用户通过 IdP 组和角色继承访问权限。首发支持 Okta，Asana、Atlassian、Canva、Figma、Linear、Supabase 等已支持。

3.5 IETF MCPS 代理护照 (Agent Passport)

IETF MCPS 草案[5] 提出了"代理护照"（Agent Passport）概念，将 ECDSA P-256 公钥绑定到代理身份和特定来源（origin）：

护照核心字段：

• agent_name、agent_version、issuer、origin（来源 URI 绑定）

• public_key（ECDSA P-256）、capabilities（能力列表）

• trust_level（0–4 级）

• issuer_chain（信任链，类似 X.509，最多 5 层）

• key_rotation（密钥轮换支持）

信任等级体系[5]：

四、细粒度授权

4.1 作用域最小化策略

官方规范[2] 定义了渐进式、最小权限的作用域模型：

初始授权：

• 客户端应仅请求预期操作所需的最小权限

• 优先级：401 响应的WWW-Authenticate头中的scope参数 > 受保护资源元数据中的scopes_supported

增量提权（Scope Challenge）：

• 当令牌权限不足时，服务器返回 403 并附带scope="<required_scopes>"

• 客户端计算新旧作用域的并集，发起重新授权

• 服务器建议将当前操作所需的所有作用域一次性发出

常见错误（官方明确警告[2]）：

• ❌ 在scopes_supported中发布所有可能范围

• ❌ 使用通配符或全能范围（*、all、full-access）

• ❌ 捆绑无关权限

• ❌ 在每次挑战中返回整个范围目录

• ❌ 静默更改范围语义

4.2 防止混淆代理 (Confused Deputy)

官方规范[2] 定义了三层防护：

每客户端同意存储：

• 维护每个用户已批准的 client_id 注册表

• 在启动第三方授权流程之前检查此注册表

同意 UI 安全要求：

• 清晰标识请求的 MCP 客户端名称

• 显示所请求的特定第三方 API 范围

• 显示注册的 redirect_uri（令牌发送目标）

• 实施 CSRF 保护、防止点击劫持

重定向 URI 验证：

• 验证授权请求中的 redirect_uri 是否与注册的 URI完全匹配（精确字符串比较）

• 使用__Host-前缀 Cookie，设置 Secure/HttpOnly/SameSite=Lax

4.3 Rich Authorization Requests (RAR)

arXiv 论文[10] 推荐使用 RAR 实现更细粒度的授权，超越传统 OAuth scope 模型：

• 支持结构化授权请求（如特定资源、特定操作、特定条件）

• 结合 DPoP（Demonstration of Proof-of-Possession）防止令牌盗用

• 结合 mTLS 令牌绑定防止重放

4.4 Red Hat 的 RBAC 集成方案

Red Hat[6] 建议将 OAuth 令牌映射到内部角色和权限：

• 令牌的 JWT claims 中包含用户角色（如 Keycloak realm/client roles）

• MCP 服务器在工具执行前进行 token claim 检查

• 某些敏感工具仅限具有 admin 角色的用户访问

4.5 上下文感知的动态权限

arXiv 论文[10] 和 CSDN 技术文章[13] 描述了三个动态权限调整维度：

1. LLM 可信度：可信度低于阈值时限制敏感工具（文件系统、数据库、网络）

2. 请求来源 IP：限制特定 IP 范围

3. 时间窗口：限制非工作时间操作

五、访问控制

5.1 JIT (Just-in-Time) 访问

arXiv 论文[10] 提出了即时访问控制策略：

• 仅在任务期间签发临时凭证

• 结合设备状态、位置、时间、行为分析进行上下文感知决策

• 目的驱动授权：权限与工具调用声明的目的对齐

• 风险变化时立即撤销访问

5.2 多 MCP 服务器的隔离策略

网络级分段[10]：

• 专用 MCP 安全区域（VLAN、VPC 子网）

• 服务网格（Istio）实施基于身份的 mTLS 流量控制

• 限制服务器间通信，强制显式 allow 规则

会话状态隔离[10]：

• 防止跨会话干扰与数据泄露

• 环境分离：开发/测试/生产完全独立

Docker 容器化隔离（ChatForest 安全指南[14]）：

• 每个 MCP 服务器在独立容器中运行

• 使用--cap-drop ALL和--security-opt no-new-privileges

• 独立的文件系统、网络命名空间和资源限制

5.3 WebAssembly 沙箱隔离

Microsoft Wassette[14]：采用默认拒绝安全模型

• MCP 服务器编译为 WebAssembly 在沙箱运行时中运行

• 服务器必须显式声明需要的系统能力

• 未声明的能力在 WASM 运行时级别被阻止

• WASM 沙箱在微秒内启动，无容器开销

ToolHive[14]：Kubernetes 容器隔离（1,700+ Stars）

• MCPServer CRD 自定义资源

• 声明式 YAML 策略限制服务器可暴露的工具

• seccomp 配置文件和 AppArmor 策略

5.4 Human-in-the-Loop (人机协同)

Claude Code 的五模式权限系统（ChatForest[14]）：

分层审批模型（ChatForest[14]）：

• 低风险（只读工具）→ 自动批准

• 中等风险（写入工具）→ 记录并异步审查

• 高风险（破坏性工具）→ 阻止直到人工批准

• 关键（基础设施/财务）→ 多方批准

六、内容过滤（输入/输出安全）

6.1 提示注入防护

这是 MCP 独有的安全挑战。OWASP MCP Top 10[3] 将提示注入列为 MCP06（意图流颠覆）和 MCP10（上下文注入与过度共享）。

Microsoft Prompt Shields[9]：

• 基于高级机器学习的指令检测

• 对外部内容进行上下文分析

• 实时威胁模式识别

• 内容聚焦（聚焦）技术明确区分可信与不可信内容

• 分隔符系统定义内容边界

MCP-Guard 学术方案[4]（arXiv:2508.10991）：

• 三层检测流水线：

  1. 轻量级静态扫描：检测明显威胁

  2. 深度神经检测器：识别语义攻击

  3. 微调 E5 模型：在对抗性提示检测上达到96.01%准确率

• LLM 仲裁器综合三个信号做出最终决策

• 配套发布 MCP-ATTACKBENCH 基准（70,448 样本）

OpenGuardrails[14]（322+ Stars）：

• MCP 工具投毒扫描器：检测隐藏在工具描述中的恶意指令

• 提示注入扫描器：识别工具输入和输出中的注入尝试

• 敏感数据扫描器：捕获 PII、凭证和密钥

• 过度代理扫描器：标记代理请求超出所需能力

6.2 输入验证

OWASP 最佳实践[1]：

• 实施严格的 JSON Schema 验证（additionalProperties: false）

• 使用pattern限制字符串字段格式

• 验证所有 MCP 服务器工具的输入——视为不可信（来源是 LLM 输出，可能受恶意上下文影响）

• 防止注入攻击：SQL、OS 命令、路径遍历

CSDN 技术文章[13] 定义的三种输入检测：

6.3 输出过滤与数据泄露防护 (DLP)

Microsoft Presidio (mcp-presidio)[14]：

• 支持 25+ 种 PII 实体类型检测（姓名、电子邮件、电话、信用卡、社保号、护照号、IP 地址等）

• 作为 MCP 工具链中的服务运行

• 其他 MCP 服务器返回的数据在到达代理前经过 PII 检测

Pipelock 双向 DLP[14]：

• 46 个内置数据丢失防护模式

• AWS/GCP/Azure/GitHub 令牌检测

• 信用卡和金融数据模式

• 医疗记录标识符

• 双向扫描：请求和响应同时检测

Skyflow 数据隐私[14]：

• 标记化（Tokenization）：用保持数据格式但移除敏感内容的令牌替换敏感值

• 代理收到的是标记化值（如tok_4242_xxxx）而非真实数据

• 令牌在服务端解析，代理从未看到真实数据

arXiv 论文输出 DLP 策略[10]：

• 通过 ICAP 或 API 集成企业 DLP

• 基于模式的编辑：RegEx 识别并编辑信用卡号、SSN、PHI

• 响应大小监控：异常大响应可能表明数据外泄

• 信息披露防护：过滤内部系统细节、错误堆栈

6.4 URL 安全验证

官方安全最佳实践[2] 对 OAuth 授权 URL 的要求：

• 仅允许http://和https://方案

• 拒绝javascript:、data:、file:、vbscript:等危险方案

• 使用平台特定的非 Shell URL 打开机制

• 设置 CSP：script-src 'self'、default-src 'self'

七、OWASP MCP Top 10 威胁全景

OWASP 于 2025 年发布 MCP Top 10 风险清单[3]，项目由 Vandana Verma Sehgal 领导，当前处于 Beta 阶段（v0.1）。

十大风险清单

纵深防御模型

据 PipeLab 分析[15]，没有任何单一工具可以覆盖所有 10 项风险。推荐的可防御堆栈为：

预部署扫描器 + 运行时代理 + OAuth 2.1 身份网关 + 哈希链审计日志平台 + 网络允许列表

八、IETF MCPS 密码学安全草案

IETF 于 2026年3月14日 发布 draft-sharif-mcps-secure-mcp-00[5]，提出了不修改核心 MCP 协议的密码学安全层。

四大安全原语

1. Agent Passport（代理护照）：将 ECDSA P-256 公钥绑定到代理身份和来源

2. 消息签名（Per-Message Signing）：对每条 JSON-RPC 消息进行 ECDSA P-256 签名

3. 工具定义完整性（Tool Definition Signing）：覆盖完整工具对象（含 description 字段）的加密哈希

4. 重放保护（Replay Protection）：Nonce（16 字节随机数）+ 时间戳窗口（默认 300 秒）

密码学原语

MCPS 防御的威胁

MCPS 不防御的威胁

"合法服务器运营者签名的恶意工具——来源证明不等于安全分析；信任机构密钥泄露——类似 X.509 CA 泄露，通过 HSM 和多 TA 缓解。"[5]

九、企业级部署实践

9.1 Red Hat 的安全方案[6]

Red Hat 根据部署场景推荐三种授权策略：

9.2 Microsoft 的安全控制[9]

Microsoft 在 mcp-for-beginners 项目中发布的安全控制指南（截至 2026年2月）：

令牌安全控制：

• 严格禁止令牌透传

• 五项强制验证：audience_validation、issuer_verification、signature_check、expiration_enforcement、scope_validation

• 令牌轮换：优先使用短生命周期令牌

• 安全存储：使用 Azure Key Vault 或等效方案

• 传输安全：最低 TLS 1.3

AI 特定威胁防护：

• Microsoft Prompt Shields 集成（ML 指令检测）

• 工具投毒预防（模式验证、参数注入检测）

• 输出监控（Azure Content Safety 服务）

9.3 Anthropic 的企业方案[8]

2026年6月推出Enterprise-Managed Authorization：

• 管理员通过 IdP 一次性授权 MCP 连接器

• 用户通过 IdP 组和角色继承访问权限

• 支持零接触连接器设置（用户首次登录即可使用）

• 管理员可要求连接器仅通过 IdP 连接（防止个人账户混用）

• 首发支持 Okta；Asana、Atlassian、Canva、Figma、Linear、Supabase、Slack 等已支持

• HubSpot、Ramp、Webflow 等企业正在部署

9.4 CIS 安全控制指南[11]

CIS（Center for Internet Security）于 2026年4月发布 MCP Companion Guide，将 CIS Controls v8.1 应用于 MCP 系统，重点关注：

• 身份与访问控制表面管理

• 日志与审计扩展

• 应用安全表面

• Agent 驱动的工具执行保护

• 上下文管理安全

9.5 arXiv 企业安全框架[10]

论文《Enterprise-Grade Security for the Model Context Protocol》(arXiv:2504.08623) 提出了三种安全部署模式：

十、中国国内视角与实践

10.1 国内安全研究

腾讯云开发者社区（摘星，2025年9月）[12] 发表 MCP 安全机制深度剖析，核心观点：

"在 AI 技术快速发展的今天，安全性已成为决定技术能否大规模应用的关键因素。MCP 作为连接 AI 模型与外部世界的重要桥梁，其安全机制的设计和实施直接关系到整个 AI 生态系统的可信度和可靠性。"

文章定义了四大威胁模型（authentication_bypass、privilege_escalation、data_interception、injection_attacks，均标记为 HIGH 严重级别），提出五层隐私保护体系（数据收集层、存储层、传输层、处理层、访问层），并构建了完整的安全配置框架（密码策略、会话管理、MFA、加密、授权）。

CSDN 技术博客（2026年1月）[13] 深入解析 MCP v2.0 安全架构，指出 MCP v2.0 的三个新要素：

1. 零信任架构

2. 动态权限调整机制

3. 多层安全防护体系

文章将 MCP v2.0 与 OpenAI Function Calling、Anthropic Tool Use、Google Gemini Tools、AWS Bedrock Agent 进行了对比，结论为"MCP v2.0 在安全特性和性能之间取得了良好平衡"。

阿里云开发者社区（2025年5月）[16] 发布 MCP 规范新版安全通信架构升级解读，重点分析 2025-03-26 版本的变更，包括 Token 泄露风险减少、公共客户端适配等。

OAuth 2026 for MCP（CSDN，2026年3月）[17] 提出了面向零信任架构的协议增强范式：在 RFC 6749 基础上强制引入时间戳绑定、设备指纹签名、跨域授权链。

10.2 国内大厂实践

腾讯云[7]：推出企业级 MCP 服务，集成安全认证网关阿里云[7]：推出 MCP 智能化工具平台百度智能云[7]：推出行业 MCP 解决方案字节跳动[7]：构建 MCP 开发者生态

36氪 2025年4月报道[7]："扣子等智能体平台热潮刚过，MCP 又成为新热点；阿里云率先推出 MCP 平台后，腾讯云跟进。"

十一、安全工具生态矩阵

基于 ChatForest 和 PipeLab 的统计14，MCP 安全工具生态如下：

护栏框架

沙箱隔离

DLP/内容过滤

授权/访问控制

安全扫描

十二、未来趋势与展望

12.1 协议层面

• RFC 9728 的全面采用：当前仅 Amazon Cognito 和 Ping Identity 原生支持 RFC 8707（MCP 强制依赖），主流 IdP 提供商需要跟进[11]

• MCPS 成为正式 RFC：IETF MCPS 草案可能在 2026–2027 年成为正式标准[5]

• OAuth 2.1 最终版：draft-ietf-oauth-v2-1 正在进行中，将进一步影响 MCP 授权模型

12.2 技术演进方向

据 CSDN 技术文章[13] 预测：

• 2027：AI 驱动的安全防护成为标配，自动检测 90%+ 已知攻击

• 2028：零知识证明广泛应用，实现隐私保护审计

• 2029：量子安全成为强制要求

• 2030：去中心化身份认证（DID）成为主要认证方式

12.3 产业趋势

• Anthropic Enterprise-Managed Auth 的推出[8] 标志着 MCP 安全从"开发者自管理"到"企业级集中管理"的转变

• 阿里云、腾讯云、百度智能云加速 MCP 安全能力建设[7]

• OWASP MCP Top 10 从 Beta 走向 Final Release[3]

• 云原生 MCP 安全网关成为基础设施标配

十三、核心参考文献

附录：关键 RFC 时间线

声明