企业级 MCP 重构：安全责任从协议转移到开发者

这是什么？

Model Context Protocol 迎来了自 Anthropic 于 2024 年底发布以来最大的结构性变更。MCP 2026-07-28 规范——候选版本于 2026 年 5 月 21 日 发布，最终版本计划于 2026 年 7 月 28 日 发布，并为遗留功能提供为期十二个月的弃用窗口——将 MCP 从本地、单用户的集成工具，推向一个无状态、面向企业级云部署的协议。

2026 年 6 月 25 日，Akamai 威胁研究团队（Maxim Zavodchik、Segev Fogel、Gal Meiri）发布了对新规范的威胁建模。他们的结论正是本文报道的原因：这次重构确实关闭了若干协议层的漏洞类别，但代价是把相应的安全决策下放给实现 MCP 服务器的开发者与平台运营方。协议本身变得更安全；而任何一个具体部署是否安全，如今完全取决于实现质量。

工作原理

三类旧的风险被削减或移除。由协议管理的会话——攻击者可窃取用以冒充用户的长期 Mcp-Session-Id——被无状态模型取代而消失。服务器不再能在任意时刻向客户端推送未经请求的提示，从而关闭了被入侵服务器可利用的一个通道。认证也转为强制 OAuth 2.1，弃用遗留的密码授权与隐式授权，并要求 PKCE 等保护措施。

作为代价，出现了一组新的攻击面，其安全性取决于每个服务器如何编写，而非协议本身：

被协议移除 / 削减                          现在是开发者的责任
---------------------------------------  -------------------------------------------
协议层会话劫持                            状态对象完整性（工作流劫持）
未经请求的服务器提示                      对客户端 _meta 元数据的信任
弱 / 遗留认证                             请求头与请求体一致性（去同步）
                                         不要把密钥映射进 HTTP 请求头
                                         对 MCP Apps 界面做输出编码（存储型 XSS）
                                         对长时间异步任务设置配额

由于协议是无状态的，服务器把跟踪 ID 和状态对象交给客户端，并信任客户端将其回传以恢复暂停的工作流。如果服务器使用可预测的跟踪 ID，或未校验回传状态的完整性，攻击者便可猜测或篡改这些值，以劫持他人正在进行的工作流，或触发跨租户操作。规范要求开发者校验这些对象，却未规定具体做法。

新的 _meta 对象允许客户端向几乎任何消息附加任意键值对，且这些字段没有加密签名。若服务器信任诸如 {"tenant": "admin"} 之类的字段用于路由或授权，攻击者一次请求即可完成权限提升。同理，新的 MCP HTTP 请求头（Mcp-Method、Mcp-Name）在请求头与 JSON-RPC 请求体不一致时会招致去同步攻击；而将工具参数映射进请求头的 x-mcp-header 指令，一旦开发者映射了错误字段，就会把密钥泄露给路径上的每个代理和日志。最后，MCP Apps——如今被提升为一等扩展的交互式界面面板——把经典的存储型 跨站脚本（XSS） 带入了智能体表面（虽被隔离在 <iframe> 中，但仍足以进行钓鱼或窃取面板可见的数据）；而创建成本低廉的长任务则构成了「打了就跑」式的拒绝服务向量。

为什么重要

MCP 已经是智能体与企业工具之间事实上的连接组织，其采用正加速涌向该规范所针对的多租户、云托管部署。安全问题从「协议是否安全？」转变为「这个服务器是否正确实现了新的信任边界？」——而答案将因服务器而异。迁移窗口（遗留支持十二个月）也意味着新旧语义并存的混合环境同时运行，而这恰恰是去同步和状态管理缺陷滋生的温床。如果贵组织发布或使用 MCP 服务器，7 月 28 日的切换是一个可以提前准备的既定事件。

防御措施

Akamai 的建议，推广至任何采用新规范的团队：

1. 将客户端提供的一切状态与元数据视为不可信。 对状态对象签名并校验完整性；绝不根据未签名的 _meta 字段做授权或路由决策。使用不可预测、高熵的跟踪 ID，并在服务器端将其绑定到已认证主体。
2. 协调请求头与请求体。 确保代理、网关与服务器在 Mcp-Method / Mcp-Name 与 JSON-RPC 请求体上达成一致；拒绝相互矛盾的请求，以关闭去同步缺口。
3. 审计 x-mcp-header 映射。 绝不要把 API 密钥、令牌或 PII 映射进 HTTP 请求头。在部署前及代码审查中检查这些映射，因为泄露是无声的。
4. 对 MCP Apps 内容做输出编码。 对面板中渲染的任何用户或工具提供的 HTML 施加严格的输出编码和紧凑的内容安全策略（CSP）；保留沙箱，但不要仅依赖它。
5. 对异步任务设配额。 对任务创建限速并限制资源，并将长任务绑定到可问责的已认证会话，使单个断开连接的客户端无法耗尽服务器。
6. 规划迁移。 盘点 MCP 服务器与客户端，跟踪哪些已采用新的无状态语义，并避免长期的混合模式部署，以免新旧行为被相互利用。

状态

项目	参考	日期	说明
MCP 2026-07-28 候选版	modelcontextprotocol.io	2026-05-21	无状态架构、MCP Apps、异步任务、OAuth 2.1
Akamai 威胁建模	Akamai SIG	2026-06-25	攻击面转移分析
最终规范	modelcontextprotocol.io	2026-07-28（计划）	12 个月遗留弃用窗口

标题不是「新的 MCP 规范不安全」——它确实移除了真实的协议层风险。真正的要点是：安全责任已转移到构建 MCP 服务器的人身上，自 7 月 28 日切换起生效。把迁移当作一个实现安全项目、而非直接升级来对待的团队，才能避免继承这些新的攻击面。