MCP 安全最佳实践：面向 2026-07-28 规范的纵深防御与 AI 威胁防护实战指南（mcp-for-beginners）

• 教程
• 文档
• 人工智能

本指南以 mcp-for-beginners 课程 02-Security/mcp-security-best-practices.md 为骨架，系统讲解基于MCP Specification 2026-07-28的安全最佳实践：从强制安全条款、令牌与状态句柄安全，到提示词注入、工具投毒等 AI 特有威胁的防御，再到 OAuth 2.1/Confused Deputy 防护与供应链安全。读者完成本篇后，将掌握一套可直接落地的分层安全控制清单，并能在本仓库的 TypeScript 授权示例中看到令牌校验、CIMD/DCR 客户端注册与基于 scope 的工具级授权是如何用真实代码实现的。

MCP 为何需要一套"超出传统软件安全"的防护体系

Model Context Protocol（MCP）为 AI 应用带来了强大的工具与数据接入能力，同时也引入了传统软件安全之外的独特风险。与经典 Web 安全相比，MCP 系统不仅要应对安全编码、最小权限、供应链安全等既有问题，还面临一系列 AI 特有威胁：

• 提示词注入（Prompt Injection）：恶意指令被嵌入外部内容，诱导 AI 执行非预期动作；
• 工具投毒（Tool Poisoning）：攻击者篡改工具定义元数据，使 LLM 做出错误的执行决策；
• 状态句柄劫持（State-Handle Hijacking）：跨用户复用或猜测可预测的状态标识；
• Confused Deputy 问题：MCP 服务器在客户端与第三方服务之间充当认证代理时被利用；
• 令牌透传漏洞（Token Passthrough）：服务器未经校验转发上游令牌，绕过安全控制、破坏审计链。

本篇围绕这些威胁，逐一给出与 MCP 2026-07-28 规范及 OWASP MCP Top 10 对齐的控制措施。所有实践与 OWASP MCP Azure Security Guide 保持一致，可用于 Azure 场景的落地实现；更系统的学习可参加 "MCP Security Summit Workshop (Sherpa)"，通过 "漏洞 → 利用 → 修复 → 验证" 的方式获得实操经验。

来自规范的强制安全要求（MUST 条款）

MCP 2026-07-28 规范在授权与安全部分给出了四条不可妥协的硬性要求，它们是所有后续实践的总纲：

其中"令牌不得透传"与"会话不得用于认证"是两条最容易被忽略、但后果最严重的红线，本指南后续章节将反复围绕它们展开。

1. 令牌安全与身份认证

认证与授权控制

• 严格的授权审查：对 MCP 服务器的授权逻辑进行全量审计，确保只有预期的用户与客户端能够访问资源；授权逻辑一旦出现缺陷，可能直接导致敏感数据泄露或访问控制被错误应用。
• 外部身份提供方集成：优先使用成熟的身份提供方（如 Microsoft Entra ID）完成认证，而不是自研认证实现。规范允许 MCP 服务器将认证委托给外部身份提供方：HTTP 传输的授权按请求逐个评估，本地 stdio 服务器则从运行环境中获取凭据。
• 令牌受众校验：始终验证令牌确实签发给当前 MCP 服务器，绝不接受上游令牌。MCP01（令牌管理不善与机密泄露）与MCP07（认证与授权不足）是 OWASP MCP Top 10 中最常见的问题类别。
• 完整的令牌生命周期：实施安全轮换、过期策略，并防止令牌重放攻击。

受保护的令牌存储

• 使用 Azure Key Vault 或同类安全凭据仓库保存全部机密；
• 对令牌同时实施静态加密与传输加密；
• 定期轮换凭据，并对未授权访问保持监控。

从 CIMD 与 DCR 授权示例 的源码可以看到令牌校验在工程上是如何落地的。该示例的 oauth.ts 使用jose库通过授权服务器的 JWKS 端点验证 JWT：

return { async verifyAccessToken(token: string): Promise<AuthInfo> { const { payload } = await jwtVerify(token, jwks, { issuer: options.issuer, audience: options.audience, algorithms: [options.algorithm] }); // 必须包含 client_id（或 azp）与 exp 声明 const clientId = stringClaim(payload, "client_id") ?? stringClaim(payload, "azp"); if (!clientId || !payload.exp) { throw new Error("Token must contain client_id (or azp) and exp claims"); } return { token, clientId, scopes: scopesFrom(payload), expiresAt: payload.exp }; } };

这段代码实现了"签发者（issuer）、受众（audience）、签名算法、过期时间"的四重强制校验——正是本节要求的"只接受签发给本服务器的令牌"的代码级体现。相关 YAML 级配置要求在 mcp-security-controls.md 中有更完整的表述：

Token Validation Requirements: audience_validation: MANDATORY issuer_verification: MANDATORY signature_check: MANDATORY expiration_enforcement: MANDATORY scope_validation: MANDATORY Token Lifecycle Management: rotation_frequency: "Short-lived tokens preferred" secure_storage: "Azure Key Vault or equivalent" transmission_security: "TLS 1.3 minimum" replay_protection: "Implemented via nonce/timestamp"

令牌透传：被明令禁止的反模式

令牌透传在现行 MCP 授权规范中被明确禁止，因为它会带来四类严重后果：

• 绕过安全控制：MCP 服务器与下游 API 依赖"正确校验令牌"才能实施限流、请求校验与流量监控，客户端直连式透传会绕开这些关键防护；
• 审计与问责失效：服务器无法区分使用上游令牌的客户端，下游资源服务器的日志会显示误导性的请求来源，事件调查与合规审计变得极为困难；
• 数据外泄风险：未经验证的令牌声明使攻击者可借 MCP 服务器充当数据外泄代理，越权访问绕过既定安全控制；
• 多服务横向移动：被多个服务接受的失陷令牌可导致攻击在互联系统中横向扩散。

因此本节与 mcp-security-controls.md 均强调：服务器不得接受未显式签发给自身的令牌，必须校验受众声明，并使用短生命周期令牌配合安全轮换。

2. 状态句柄与传输安全

MCP 2026-07-28 在协议层是无状态的，应用若要跨请求保存状态，通常由某个工具调用返回一个显式句柄，并在后续调用中把它作为普通参数传回。这种设计带来了状态句柄劫持的威胁面：

• 句柄猜测：可预测的标识暴露其他调用者的状态；
• 跨用户复用：窃取的句柄被用于不同的身份；
• 隐式授权：误把"持有句柄"当作"有权访问"。

安全状态句柄实践

• 不透明状态句柄：使用安全、非确定性的句柄承载跨请求的应用状态；
• 用户绑定：在服务端将句柄绑定到已认证主体，拒绝跨用户复用，绝不信任客户端提供的用户 ID；
• 生命周期管理：设置句柄过期与撤销机制，缩短漏洞暴露窗口；
• 逐请求授权：绝不把状态句柄当作认证凭据，每个出示句柄的请求都必须重新授权——句柄是"名字"，不是"凭据"。

mcp-security-controls.md 给出了可操作的状态句柄生成参数：

State Handle Generation: randomness_source: "Cryptographically secure RNG" entropy_bits: 128 # Minimum recommended format: "Base64url encoded" predictability: "MUST be non-deterministic" State Binding: user_binding: "Bind server-side to the authenticated principal" authorization: "Recheck on every request" client_input: "Never trust a client-supplied user ID" State Lifecycle: expiration: "Configurable timeout policies" rotation: "After privilege escalation events" invalidation: "Immediate on security events" cleanup: "Automated expired state removal"

状态应独立于任何单一传输连接存储，并为过期句柄定义恢复行为。

传输层安全

• 生产环境的远程 HTTP 传输必须使用 HTTPS；
• 本地 stdio 服务器通过进程隔离 + 环境凭据加以保护（stdio 服务器从环境而非网络获取凭据）；
• 配置现代 TLS，并做好证书轮换与校验。

3. AI 特有威胁防护

这是 MCP 安全与传统软件安全差异最大的部分，对应 OWASP MCP Top 10 中的MCP06（意图流颠覆）、MCP03（工具投毒）与MCP05（命令注入与执行）。

提示词注入防御

间接提示词注入（跨域提示词注入）是 MCP 体系中最危险的漏洞之一：攻击者把恶意指令藏在文档、网页、邮件或数据源中，AI 系统随后把它们当作合法指令处理。典型攻击场景包括：

• 基于文档的注入：恶意指令隐藏在待处理文档中，触发非预期 AI 动作；
• Web 内容利用：被攻陷网页内嵌提示词，AI 抓取时被操控；
• 邮件攻击：邮件中的恶意提示词诱导 AI 助手泄露信息或执行未授权操作；
• 数据源污染：被攻陷的数据库或 API 向 AI 系统投喂带毒内容。

防御手段包括：

• Microsoft Prompt Shields：部署高级检测与过滤，利用机器学习与 NLP 实时分析文档、网页、邮件与数据源中潜藏的攻击指令，并区分合法与恶意的提示模式；
• 输入清洗：对所有输入进行校验与净化，防止注入攻击与 Confused Deputy 问题；
• 内容边界：使用分隔符（delimiter）与数据标记（datamarking）系统区分可信指令与外部内容，配合Spotlighting 技术区分可信系统指令与可能被攻陷的外部输入，保持正确的指令层级（instruction hierarchy）；
• 输出监控：检测可能被操控或有害的模型输出。

工具投毒预防

工具投毒针对定义 MCP 工具的元数据下手，利用 LLM 依据工具描述与参数做执行决策的特性：

• 元数据操控：向工具描述、参数定义或使用示例中注入恶意指令；
• 隐形指令：藏在工具元数据中、对用户不可见但会被模型处理；
• 动态工具修改（"Rug Pulls"）：用户已批准的工具事后被改成执行恶意动作——远程托管服务器的工具定义可在用户批准后更新，使"曾经安全"的工具变成恶意工具；
• 参数注入：工具参数 schema 中嵌入影响模型行为的恶意内容。

防御框架（详见 mcp-security-controls.md）：

Tool Definition Protection: validation: - "Schema validation against expected formats" - "Content analysis for malicious instructions" - "Parameter injection detection" - "Hidden instruction identification" integrity_verification: - "Cryptographic hashing of tool definitions" - "Digital signatures for tool packages" - "Version control with change auditing" - "Tamper detection mechanisms" monitoring: - "Real-time change detection" - "Behavioral analysis of tool usage" - "Anomaly detection for execution patterns" - "Automated alerting for suspicious modifications"

配套的动态工具管理要求：工具修改必须经显式用户审批、支持回滚、保留完整的变更审计，并做自动化风险评分。

其他 AI 攻击向量

• 跨域提示词注入（XPIA）：利用多域内容绕过安全控制的高级攻击；
• 动态能力修改：实时改变工具能力以逃过初始安全评估；
• 上下文窗口投毒：操纵大型上下文窗口以隐藏恶意指令；
• 模型混淆攻击：利用模型局限制造不可预测或不安全行为。

这些攻击可能造成数据外泄、隐私泄露、系统被篡改、凭据被窃，以及以被攻陷的 AI 系统为跳板的横向移动。

4. 访问控制与权限管理

最小权限原则

• 只授予 MCP 服务器实现预期功能所需的最小权限；
• 实施细粒度 RBAC（基于角色的访问控制），把角色严格限定到具体资源与动作，避免扩大攻击面的宽泛权限；
• 定期做权限复查，持续监控提权迹象；及时回收过剩或闲置权限。

运行时权限控制

• 施加资源上限，防止资源耗尽攻击；
• 使用容器隔离工具执行环境；
• 对管理功能实施JIT（Just-In-Time）临时访问。

针对工具执行环境，mcp-security-controls.md 给出了沙箱化的具体参数（对应 OWASPMCP05命令注入与执行）：

Execution Environment: containerization: "Docker/Podman with security profiles" resource_limits: cpu: "Configurable CPU quotas" memory: "Memory usage restrictions" disk: "Storage access limitations" network: "Network policy enforcement" privilege_restrictions: user_context: "Non-root execution mandatory" capability_dropping: "Remove unnecessary Linux capabilities" syscall_filtering: "Seccomp profiles for syscall restriction" filesystem: "Read-only root with minimal writable areas"

文件系统仅保留最小必需目录（尽可能只读）、网络访问使用显式白名单并做 DNS/端口限制、系统资源禁止提权与硬件访问——这些都是最小权限在工具执行层的落地。

5. 内容安全与监控

内容安全实现

• Azure Content Safety 集成：检测有害内容、越狱（jailbreak）尝试与策略违规，其检测模型覆盖恶意指令识别、威胁模式识别与内容过滤，并可接收持续更新的威胁情报；
• 行为分析：对 MCP 服务器与工具执行做运行时行为监控，发现异常；
• 综合日志：记录全部认证尝试、工具调用与安全事件，并存入防篡改的安全存储。

仓库中的 azure-content-safety-implementation.md 提供了 Azure Content Safety 的实战集成示例，可进一步参考其代码实现。

持续监控

• 对可疑模式与未授权访问尝试做实时告警；
• 集成 SIEM（安全信息与事件管理）系统做集中化事件管理；
• 定期开展安全审计与针对 MCP 实现的渗透测试。

在日志维度，mcp-security-controls.md 建议至少覆盖三类事件（对应 OWASPMCP08缺乏审计与遥测）：

• 认证事件：全部成功/失败认证、令牌签发与校验、会话创建/修改/终止、授权决策与策略评估；
• 工具执行：调用细节与参数、执行时长与资源占用、输出生成与内容分析、错误与异常；
• 安全事件：可疑提示词注入尝试、工具投毒检测、会话劫持指标、异常访问模式。

行为分析层面可使用用户行为分析（UBA）、实体行为分析（EBA）、机器学习异常检测与威胁情报关联。

6. 供应链安全

供应链安全在 AI 时代已从传统软件依赖扩展到整个 AI 生态，每个环节都可能引入破坏系统完整性的漏洞。除开源库、容器镜像、构建工具等传统依赖外，还需要把以下 AI 组件纳入同等防护力度：

• 基础模型（需验证来源 provenance）；
• Embedding 服务与语义检索服务；
• 上下文提供方（数据源、知识库、文档仓库）；
• 第三方 AI API 与数据处理端点；
• 模型工件（权重、配置、微调变体）；
• 训练数据源。

组件验证

• 依赖扫描：对全部软件依赖与 AI 组件做自动化漏洞扫描；
• 来源验证：核实模型、数据源与外部服务的来源、许可与完整性；
• 签名包：使用密码学签名包并在部署前验证签名。

安全开发流水线

• GitHub Advanced Security：实施 secret 扫描、依赖分析与 CodeQL 静态代码分析；
• CI/CD 安全：把安全验证内嵌到自动化部署流水线；
• 工件完整性：对部署工件与配置实施密码学验证。

mcp-security-controls.md 还补充了 SBOM（软件物料清单）、包签名验证、模型行为测试、对抗鲁棒性评估，以及第三方 API 的安全评估与事件响应能力考察（对应 OWASPMCP04供应链攻击与依赖篡改）。

7. OAuth 安全与 Confused Deputy 防护

Confused Deputy 问题

当 MCP 服务器在客户端与第三方服务之间充当认证代理时，若使用静态客户端 ID，就可能出现授权绕过：

• 基于 Cookie 的同意绕过：此前用户认证留下的 consent cookie，被攻击者利用恶意授权请求与构造的 redirect URI 复用；
• 授权码窃取：既有 consent cookie 使授权服务器跳过同意页，把授权码重定向到攻击者控制的端点；
• 未授权 API 访问：窃取的授权码可换取令牌、冒用用户身份。

OAuth 2.1 实施要点

• PKCE：所有授权请求使用 Proof Key for Code Exchange（S256）；
• 客户端注册：优先使用Client ID Metadata Documents（CIMD）或预注册，已废弃的Dynamic Client Registration（DCR）仅作兼容性回退；
• 显式同意：使用静态第三方客户端 ID 的 MCP 代理必须在转发授权前为每个 MCP 客户端取得同意；
• Redirect URI 校验：对重定向 URI 与客户端标识做严格白名单校验；
• 授权码保护：短生命周期、单次使用；
• 监控授权码窃取与未授权 API 访问。

仓库内的工程化参考：CIMD 与 DCR 授权示例

本仓库的 CIMD 和 DCR 授权示例 是一个可运行的 TypeScript 资源服务器，专门对比两种客户端注册机制：

• CIMD（推荐）：用稳定的 HTTPS URL 作为client_id，适合与授权服务器没有预先关系的客户端；
• DCR（兼容回退）：运行时让授权服务器铸造不透明客户端 ID，MCP 2026-07-28 仅将其保留用于向后兼容。

示例的注册优先级为：已有预注册信息 → 服务器通告client_id_metadata_document_supported: true时用 CIMD → 服务器通告registration_endpoint时用 DCR 回退 → 以上均不可用时要求用户提供预注册信息。

registration.ts 中的分类逻辑值得关注：仅当client_id是带路径的 HTTPS URL（无用户信息、无查询串、无片段）时才判定为 CIMD；不透明 ID 若匹配可选的DCR_CLIENT_ID_PREFIX才判定为 DCR，否则如实报告为opaque-client-id——因为标准令牌声明无法区分 DCR 与预注册。

mcp.ts 展示了"在工具内部强制 OAuth scope"的做法：greet工具在执行前检查authInfo.scopes是否包含tool:greet，否则返回insufficient_scope错误。这正是"按工具细粒度授权 + 最小权限"的代码级示范。

该示例还演示了令牌校验端到端链路：oauth.ts 从授权服务器元数据强制校验issuer、authorization_endpoint、token_endpoint、jwks_uri的 HTTPS 与存在性；config.ts 规定除回环地址开发外一律要求 HTTPS；server.ts 用requireBearerAuth包住/mcp路由，所有入站请求都先验令牌再交给 MCP 处理器。

8. 事件响应与恢复

快速响应能力

• 自动化响应：凭据轮换与威胁遏制自动化——立即终止会话、账户锁定、撤销访问权限；
• 系统隔离：网络分段激活、服务隔离协议、通信信道限制；
• 回滚程序：快速回退到已知良好配置与组件；
• 取证能力：详尽的审计轨迹与日志，支持事件调查；审计日志需具备密码学完整性，支持时间线重建与影响评估。

恢复流程还包括自动令牌刷新、API 密钥重新生成、证书续期，以及干净状态恢复、配置回滚与服务重启。

沟通与协调

• 明确的安全事件升级流程；
• 与组织事件响应团队集成；
• 定期开展安全事件模拟与桌面演练（tabletop exercises）。

9. 合规与治理

• 法规合规：确保 MCP 实现满足行业特定要求（如 GDPR、HIPAA、SOC 2）；
• 数据分类与隐私：对 AI 数据处理实施数据分类与隐私控制，遵循 privacy-by-design；
• 审计文档：为合规审计维护完整文档与审计轨迹；
• 变更管理：所有 MCP 系统修改都经过正式安全评审，配置变更走版本控制与审批流，定期做合规评估与差距分析。

10. 高级安全控制

零信任架构

• Never Trust, Always Verify：对用户、设备与连接持续验证；
• 微隔离：用细粒度网络控制隔离单个 MCP 组件；
• 条件访问：基于当前上下文与行为做风险自适应访问控制。

运行时应用保护

• RASP：部署运行时应用自我保护技术做实时威胁检测；
• 应用性能监控：监测可能预示攻击的性能异常；
• 动态安全策略：根据当前威胁态势动态调整策略。

11. Microsoft 安全生态集成

综合安全套件

• Microsoft Defender for Cloud：面向 MCP 工作负载的云安全态势管理；
• Azure Sentinel：云原生 SIEM/SOAR，为 AI 工作负载提供高级威胁检测；
• Microsoft Purview：面向 AI 工作流与数据源的数据治理与合规。

身份与访问管理

• Microsoft Entra ID：企业身份管理 + 条件访问策略，天然继承 MFA 与风险自适应认证能力；
• Privileged Identity Management（PIM）：管理功能的 JIT 访问与审批工作流；
• Identity Protection：基于风险的条件访问与自动化威胁响应。

安全模块总览 中提供了 OWASP MCP Top 10 与 Azure 缓解措施的完整对照表（如MCP01→Key Vault/Managed Identity、MCP07→Entra ID/OAuth 2.1 + PKCE 等），可作为本节的配套速查。

12. 持续安全演进

保持与时俱进

• 规范监控：定期跟踪 MCP 规范更新与安全指南变化（可对照 01-CoreConcepts/mcp-2026-07-28.md 了解授权变更全貌）；
• 威胁情报：集成 AI 专属威胁源与失陷指标（IoC）；
• 社区参与：参与 MCP 安全社区与漏洞披露计划。

自适应安全

• 机器学习安全：用 ML 异常检测识别新型攻击模式；
• 预测性安全分析：建立预测模型做前瞻性威胁识别；
• 安全自动化：基于威胁情报与规范变更自动更新安全策略。

关键安全资源与仓库导航

MCP 安全实践演进迅速，实施前务必对照现行 MCP 规范与官方安全文档核实。以下为与本文直接相关的仓库内资源：

• MCP 安全控制：本文 YAML 控制清单（令牌校验、状态句柄、工具防护、沙箱化、日志策略、事件响应）的完整来源，并按 OWASP MCP Top 10 逐项对齐；
• MCP 最佳实践速查：涵盖输入校验、通信协议、限流与资源保护、加密存储、零信任、隐私保护 AI 等 12 类核心实践的速查清单；
• Azure Content Safety 实现：Azure Content Safety 的落地代码示例；
• CIMD 与 DCR 授权示例：可运行的 TypeScript MCP 2026-07-28 资源服务器，源码位于 src 目录，配套 12 个测试（test 目录）使用本地密钥与 mock HTTP 端点，验证 CIMD 文档形状、JWT 五重校验、不安全 DCR 端点拒绝等行为，无需真实授权服务器账号即可运行；
• 安全模块总览：OWASP MCP Top 10 对照表、Sherpa 训练营路线（Base Camp → Summit）与授权演进史；
• MCP 2026-07-28 规范变更：iss参数校验（RFC 9207）、凭据绑定、DCR 弃用等授权变更的完整说明。

核心要点回顾

• 分层防御：把基础安全实践（安全编码、最小权限、供应链验证、持续监控）与 AI 特有控制结合，形成纵深防御；
• AI 威胁全景：提示词注入、工具投毒、会话劫持、Confused Deputy、令牌透传与过度授权都需要专门缓解；
• 认证与授权卓越：用外部身份提供方（Entra ID）做认证，严格令牌校验，绝不接受非签发给本服务器的令牌；
• 令牌安全原则：杜绝令牌透传反模式，校验受众声明，使用短生命周期令牌并安全轮换，保持清晰的信任边界；
• AI 攻击防御：部署 Prompt Shields 与 Azure Content Safety，校验工具元数据并监控动态变更；
• 会话与传输安全：密码学安全、非确定性的会话 ID 绑定用户身份，妥善管理生命周期，永不用会话做认证；
• OAuth 最佳实践：对动态注册客户端显式取得同意，实施带 PKCE 的 OAuth 2.1，严格校验 redirect URI，防止 Confused Deputy；
• 供应链全覆盖：把模型、Embedding、上下文提供方、外部 API 视为与传统依赖同等重要的防护对象；
• 持续演进：随着协议成熟，跟踪规范变化、贡献社区标准、保持自适应安全姿态；
• Microsoft 生态集成：利用 Prompt Shields、Azure Content Safety、GitHub Advanced Security、Entra ID 增强 MCP 部署防护。

下一步可阅读 MCP 安全控制 获取可执行的控制清单，返回 安全模块总览 复习 OWASP MCP Top 10，或进入 模块 3：开始入门 学习 MCP 的实操搭建。

• 教程
• 文档
• 人工智能