2026年7月28日，Model Context Protocol（MCP）2026-07-28版规范正式发布。这次升级把MCP从"本地单用户AI集成协议"推向企业级云原生平台：协议层彻底无状态、路由基于HTTP头、多轮请求机制（MRTR）落地、OAuth 2.1强制化。但同一天，Akamai安全团队发布的详细分析给出了另一个视角的总结：MCP把安全责任从协议层移交给了开发者——那些过去由协议兜底的安全边界，从今往后完全取决于你的实现质量。
对于正在把AI智能体接入业务系统的团队，这可能是近期最值得逐字阅读的一次规范变更。本文梳理无状态化改了什么、旧风险消除了哪些、五个新攻击面长什么样，以及过去一年里MCP生态已经交过的几次"安全学费"。
一次跨越12个月的架构迁移：MCP到底改了什么
旧版MCP是有状态协议：客户端与服务器通过一次initialize/initialized握手建立长连接，用Mcp-Session-Id维护会话，通过Server-Sent Events双向通信。状态由协议管理，安全也由协议兜底。
新规范彻底抛弃了这套机制。每次请求完全独立，自带协议版本、客户端身份与能力声明（通过_meta参数），可以落在负载均衡器后面的任意实例上，无需共享存储。对工程师来说，MCP现在长得更像一个普通的HTTP API：Mcp-Method与Mcp-Name两个HTTP头承担路由职责，网关与WAF无需解析Body即可完成分发；tools/list等响应携带ttlMs与cacheScope，客户端可以缓存工具目录；需要用户确认的场景由多轮请求（MRTR）取代服务器主动推送——服务器返回input_required，客户端带着答案重试。
授权层面，OAuth 2.1成为强制要求，iss参数必须验证，动态客户端注册（DCR）被废弃。与此同时，Roots、Sampling、Logging、HTTP+SSE传输被标记废弃，官方给出12个月的最低支持窗口期：旧功能暂时可用，但新实现不应再采用。
协议层甩掉的三顶旧帽子
无状态化确实消灭了三类真实存在过的风险，这一点应当承认：
- 会话劫持：旧版Mcp-Session-Id是高价值攻击目标，窃取即冒充。无状态化让这个攻击向量从协议层面消失；
- 服务器主动推送：旧版允许服务器通过SSE随时向客户端推送未请求的提示内容——这是提示注入的天然通道。新规范严格限制了这一行为；
- 弱认证：强制OAuth 2.1移除了大量基于弱凭证的认证风险。
但安全的守恒定律在这里同样生效：协议层卸下的责任没有消失，而是平移到了每一个MCP服务器实现者的肩上。
五个新攻击面：每个都依赖实现质量
根据Akamai的分析，无状态化引入了五个需要开发者自行设防的攻击面。
一、工作流劫持与跨租户访问。状态管理从协议层移到应用层后，服务器需要自己设计"跟踪标识符"与"状态对象"来串联多轮请求。如果这些标识符可预测——递增整数、时间戳哈希、未绑定租户上下文的随机数——攻击者就能劫持进行中的工作流、访问其他智能体的中间数据、甚至触发未授权的跨租户操作。这在多租户AI平台上是致命的：协议不再帮你区分"这是谁的请求"。
二、头部与主体不一致攻击（Desync）。Mcp-Method与Mcp-Name头部让路由层无需解析Body——但这也意味着头部和Body可能说的是两回事：网关以为在处理一次轻量的tools/list，服务器实际执行的是一次危险的tools/call。这是经典反向代理请求走私漏洞的MCP翻版。任何在网关上基于头部做策略（限流、鉴权、审计）的架构，都必须额外校验头部与JSON-RPC方法的一致性。
三、敏感信息经x-mcp-header泄漏。规范允许通过自定义头部传递上下文。如果开发者把API密钥、令牌或个人身份信息映射到头部，Akamai的警告非常直白："这些密钥会直接进入头部——一旦到了那里，沿途的每个负载均衡器、代理和日志系统都能看到。"头部是整个请求链路上被记录得最频繁的地方，把秘密放进去等于广播。
四、异步任务的拒绝服务。新规范的长任务机制存在结构性缺陷：任务创建对客户端近乎免费，对服务端却可能极其昂贵。攻击者可以发起一个消耗CPU、内存或数据库存储的长任务，然后立刻断开连接——服务器还在跑，账单还在走，调用方已经消失。没有配额、超时与并发上限的实现，等于把信用卡留在了门外。
五、MCP UI面板的XSS。MCP Apps成为一等扩展后，MCP服务器可以向前端提供UI界面。这意味着存储型XSS、界面伪装钓鱼这些传统Web攻击面正式进入MCP协议范畴。一个恶意MCP服务器提供的"登录面板"，渲染在用户的智能体客户端里，杀伤力不亚于任何钓鱼页面。
这不是MCP的第一次安全考试
过去一年，MCP生态已经交过几次学费。把这些事件与本次规范变更放在一起看，趋势非常清晰：AI智能体基础设施正在快速复演Web安全二十年的历史。
CVE-2026-11624：DNS重绑定打穿本地MCP服务器。0.25版本之前的MCP服务器实现不校验入站请求的Origin头。攻击者运营一个短TTL的恶意域名：受害者访问时先解析到攻击者服务器加载恶意JavaScript，随后域名重新绑定到127.0.0.1——浏览器后续请求全部打到受害者本机的MCP服务器上。由于服务器不验证来源，恶意脚本可以任意调用本地MCP工具：读文件、执行命令、访问数据库。凡是开发者本机、CI/CD流水线或内网中运行旧版MCP服务器且浏览器可达的环境，均在射程之内。修复方式是升级到v0.25或更高（Python执行pip install --upgrade mcp>=0.25.0，Node.js更新@modelcontextprotocol/sdk），并确认Origin校验已启用。
STDIO传输的设计级缺陷。2026年4月15日，OX Security披露MCP STDIO传输接口存在系统性漏洞：官方多语言SDK将用户可控的服务器配置直接传给底层Shell执行——凡是攻击者能影响MCP服务器配置的场景（一个恶意仓库里的配置文件、一个诱导粘贴的安装指南），都能转化为宿主机上的任意命令执行。据估计，受影响的AI部署超过20万个。这是"协议设计缺陷"而非单个实现 bug，也是STDIO本地传输场景长期被低估的注脚。
工具投毒（Tool Poisoning）。学术研究已经系统化地分析了这个客户端侧风险：恶意指令被藏在MCP工具的元数据（描述文本、参数说明）中，模型在读取工具清单时就会"读到"并遵循这些指令——不需要任何漏洞，提示注入本身即是攻击载荷。对七个主流MCP客户端的实证评估显示，大多数客户端缺乏足够的静态校验与参数可见性控制，多层次的防御（元数据静态分析、模型决策路径跟踪、行为异常检测）仍属稀缺品。当智能体生态走向"装一个新工具就像装一个浏览器扩展"的便利度时，投毒面也在同步扩张。
防御体系：把协议不管的都管起来
新规范之下，一份务实的MCP安全清单应当覆盖以下层次：
- 升级与版本管理：所有MCP服务器实例统一升级至v0.25+（修复Origin校验），存量版本盘点进资产台账——包括开发者本机的那一台；
- 跟踪标识符工程：应用层的状态跟踪标识必须使用加密随机数生成，绑定租户与请求上下文，杜绝可预测性；
- 头部一致性校验：网关与服务器双重校验Mcp-Method/Mcp-Name头部与JSON-RPC方法的一致性，防止路由走私；
- 头部卫生：禁止将密钥、令牌、PII写入任何x-mcp-header，把它写进代码评审清单；
- 长任务治理：为异步任务设置并发上限、资源配额与超时回收，按调用方维度限流；
- UI输出转义：MCP Apps面板的渲染必须做上下文转义，视同不可信第三方内容；
- 工具供应链审计：接入第三方MCP服务器前审计其工具描述与元数据，运行时监控工具调用的行为异常——防投毒要靠读写两端；
- 部署边界：MCP服务器仅绑定127.0.0.1（无远程需求时），远程场景置于认证与网络控制之后，敏感场景考虑容器化沙箱隔离。
迁移时间表：12个月窗口期的优先级
对正在集成的团队，建议按以下节奏推进：本周（P0）盘点当前MCP版本与废弃功能使用情况，确认SDK更新状态；第一个月（P1）设计无状态迁移方案与跟踪标识符生成策略，评估长任务资源模型；前三个月（P2）替换初始化流程，将HTTP+SSE迁移至Streamable HTTP，补齐头部路由与一致性校验；12个月内（P3）完成Roots、Sampling、Logging的替换，从DCR迁移到CIMD，更新OAuth流程验证iss参数，并对所有MCP UI面板做一轮安全审计。
结语
MCP的无状态化是一个正确的架构决定——弹性伸缩、负载均衡、故障恢复，这些都是企业级标准的必要条件。但Akamai报告里那句话值得贴在每个MCP服务器的README顶部："安全决策之前由协议执行，现在被委托给了MCP服务器开发者和平台运营者。同样的动作，换个实现者，安全结果天差地别。"
Web安全的历史规律正在AI基础设施上加速重演：每一个被修掉的旧漏洞，都会以新协议、新传输、新交互界面的形式在新的层里重生。MCP的12个月迁移窗口，既是功能迁移的工期，也是把二十年Web安全经验提前注入智能体基础设施的最后机会。