要点汇总
2026 年 7 月 28 日,模型上下文协议 (MCP) 将正式转向企业级的无状态架构。
通过向无状态模型的演进,并引入丰富的 UI 应用和异步任务,该协议将构建关键安全边界的责任完全交到了开发人员手中。
此次更新成功消除了以往的主要安全风险,包括协议层会话劫持、未经请求的服务器提示,以及弱身份验证方式。
然而,应用管理状态、丰富的交互式 AI 界面以及长期运行的异步任务的引入,也为滥用滋生了全新渠道。
如果未能实施妥善的安全防护,这些新特性可能会导致客户数据遭受越权访问、通过受信任的 AI 体验实施针对性网络钓鱼、绕过企业安全控制,并因滥用后台处理工作流而引发服务中断。
即将发布的 MCP 2026-07-28 规范,代表了模型上下文协议 (MCP) 自诞生以来最重大的一次架构演进。这一原本定位于本地、单用户 AI 集成的工具,正在蜕变为能够支撑企业级、云原生部署的强大平台。
继 2026 年 5 月 21 日发布候选版本之后,最终规范定于 2026 年 7 月 28 日正式发布。届时,针对特定的历史遗留功能,将开启为期 12 个月的正式弃用过渡期。
攻击面的演进
为了奠定这一企业级基础,此次更新彻底重构了协议处理数据与执行的方式。它引入了由多轮次往返请求支持的无状态架构、标准化的全新 HTTP 标头,以及用于上下文消息传递的通用 _meta 对象。此外,该规范还正式确立了 MCP 应用与异步任务的地位,并提升了 OAuth 集成功能的重要性,使其成为核心功能之一。
尽管关于这些功能的讨论大多集中在可扩展性和互操作性上,但它们对协议攻击面的结构性影响同样深远。随着安全模型的转变,一些长期存在的协议层风险得到了缓解或被彻底根除,而全新的安全责任则直接落在了 MCP 应用开发人员的肩上(如图 1 所示)。归根结底,虽然这些改变巩固了底层架构,但具体的实施选择现在将直接决定整体的安全态势。
减少或消除攻击面
在早期版本的 MCP 中,由协议管理的会话、服务端发起的通信以及尚不成熟的身份验证要求,曾暴露出了诸多安全风险。全新规范对其中几项核心机制进行了重构或彻底移除,从而有效减少了协议层面的攻击面。这些机制具体包括:
协议层会话劫持
未经请求的服务器提示
弱身份验证方式
协议层会话劫持
早期版本的 MCP 依赖有状态的初始化过程,通过 Mcp-Session-Id 标头来建立长连接会话。这些会话标识符通常具有很高的价值,因为攻击者一旦获取,便能直接冒充已认证的用户。
全新规范彻底移除了此类由协议管理的会话,从根本上消除了这一特定的攻击渠道。然而,这也意味着开发人员现在必须自行构建安全的状态管理机制(我们将在本博文的后面部分中对此进行深入探讨)。
未经请求的服务器提示
早期版本的 MCP 允许服务器在任意时间,通过服务器发送事件向客户端发送非预期的请求或提示。
全新规则对这一行为进行了严格限制,从而有效防止了被入侵的服务器利用未经提示的恶意交互,在暗中对用户实施干扰。
弱身份验证方式
此次更新强制转向严格的 OAuth 2.1 标准,从而大幅降低了身份验证风险。通过淘汰传统密码和隐式授权,并强制实施代码交换证明密钥 (PKCE) 等现代防护机制,该协议极大地限制了凭据和令牌被泄露或利用的可能性。
总体而言,这些改进极大减少了早期 MCP 部署中存在的身份验证相关攻击面,并显著缩小了会话被劫持后的爆炸半径。
新版规范引入的新攻击面
尽管该协议消除了几类漏洞,但它也带来了全新领域的安全挑战。在这些领域中,安全性在很大程度上取决于具体的实施质量。这些新型风险包括:
跨智能体工作流劫持
客户端可控的元数据操纵
标头混淆与标头数据泄露问题
MCP 应用与存储型跨站脚本攻击
长周期后台任务中的恶意利用风险
跨智能体工作流劫持
向无状态架构的转型带来了一些隐蔽的安全挑战。在企业级环境中,AI 交互往往并非简单的单次请求对话,而是通常需要依赖一系列连续的事件链。例如:
请求澄清:工具可能会在执行到一半时暂停,向用户询问缺失的细节
验证进展:长周期作业可能需要系统定期请求更新
暂停工作流:复杂流程可能会暂停一小时以等待人工审批,随后从此前完全相同的状态恢复执行
由于全新 MCP 采用无状态设计,它不再使用持久会话来识别身份。相反,它引入了追踪标识符与状态对象,并由服务器交付给客户端。当客户端准备恢复执行流时,再将这些数据传回,这实际上让客户端拥有了对任务状态的完全控制权。
随之而来的安全隐患非常直观:由于这些追踪 ID 和状态对象直接来自客户端,服务器绝不能盲目信任它们。如图 2 所示,如果 MCP 服务器使用了可预测的追踪 ID,或者未能严格校验所接收状态对象的完整性,攻击者就可以通过推测或篡改这些数值来:
劫持其他用户的活跃工作流
访问属于其他智能体的敏感信息
触发未授权的跨租户操作
尽管 MCP 官方规范明确警告开发人员要验证这些对象的完整性,但它并未制定具体的标准或实施指南,从而将构建该安全层的重任完全留给了服务器开发人员。
客户端可控的元数据操纵
全新规范引入了一个 _meta 对象,允许客户端将自定义元数据附加到几乎任何 MCP 消息中。即使在最简单的单次请求中,攻击者也能提供恶意的键值对,例如 {"tenant": "admin", "authenticated": true}。
由于这些字段缺乏加密签名,如果服务器在路由或授权决策时轻信这些元数据,那么一个恶意请求就可能瞬间导致权限提升或跨租户数据访问。
标头混淆与标头数据泄露问题
新版规范引入了 MCP 特定的 HTTP 标头,例如 Mcp-Method 和 Mcp-Name,以帮助中间件、代理、网关和服务器始终如一地理解 MCP 请求并对其进行正确路由。
而,这些标头也带来了两种全新的安全风险:
协议混淆(去同步化)攻击:攻击者可以在 HTTP 标头与 JSON-RPC 请求体之间发送相互矛盾的数值。利用 HTTP 和 JSON-RPC 这两种不同通信协议之间的解析分歧,诱发后端基础架构的去同步化。这种不一致性会误导代理和后端服务器,使其对同一个请求做出截然不同的解读,从而使攻击者能够绕过安全控制、逃避监控或掩盖恶意行为。
x-mcp-header 数据泄露问题:这一全新指令允许开发人员将特定的工具参数直接映射到 HTTP 标头中。这有助于代理更安全、更快速地路由流量,而不必解析完整请求体。然而,如果开发人员不慎将 API 密钥、令牌或个人身份信息 (PII) 等敏感输入映射进去,这些机密数据就会被直接推送到标头中。一旦进入标头,传输路径上的每一个负载均衡器、代理和日志系统都将对这些数据一览无余。
MCP 应用与存储型跨站脚本攻击
MCP 最令人瞩目的更新之一,是将 MCP 应用提升为原生、深度的协议扩展。MCP 应用是指您在 Claude Desktop 等 AI 应用程序内部看到的交互式可视化面板,例如交互式表单和仪表盘、文档查看器、工作流以及任务追踪界面。
虽然这些丰富的交互界面极大地提升了用户体验,但它们也把诸如存储型跨站脚本攻击 (XSS) 等传统的 Web 浏览器风险引入到了 AI 生态系统中。例如,攻击者可以通过 MCP 工具存储恶意的 HTML 或 JavaScript。当另一个用户(或 AI 智能体)查看该内容时,恶意脚本就会在应用界面内自动运行。
尽管 MCP 规范要求智能体在沙盒化的 <iframe> 内部执行这些脚本,以阻止恶意攻击者完全接管 AI 智能体,但用户依然面临风险。攻击者仍能利用已被入侵的面板来展示欺骗性内容、通过伪造提示发起针对敏感信息的钓鱼攻击、窃取该特定面板内当前可见的所有用户数据,并将这些窃取的信息传回自己的服务器(如图 3 所示)。
长周期后台任务中的恶意利用风险
长周期任务的引入,催生了一个依赖单向交互的巨大拒绝服务 (DoS) 攻击渠道。由于对客户端而言,创建任务的成本极其低廉,但对服务器来说却属于资源密集型操作,攻击者只需发送单个请求即可触发一项高能耗操作(大肆消耗 CPU、内存或数据库存储),并随后立即断开连接。
这种单向异步恶意利用方式,迫使服务器在客户端离线后仍必须继续处理沉重的业务负载,从而轻而易举地耗尽服务器资源。
结语
MCP 2026-07-28 规范标志着该协议正式从本地应用迈向企业级规模部署。从安全视角来看,这些变革绝非简单的渐进式微调,而是从根本上重塑了安全责任的归属。此前由协议本身强制执行的安全决策,正越来越多地移交给 MCP 服务器开发人员和平台运维人员。
随着 MCP 在云环境中的普及全面加速,最核心的安全课题已不再是协议本身是否安全。相反,安全团队必须审慎评估构建在其之上的应用,是否正确实施了该规范所引入的全新信任边界、状态管理机制以及执行模型。
为了有效保护这些新型攻击面,安全团队必须将所有由客户端提供的状态数据和元数据都视为不可信的输入,同时实施严格的加密验证、对 AI 生成的可视化面板进行输出编码,并为异步任务部署稳健的资源配额约束。
应对这一变革,关键在于构建主动防御架构,在漏洞触及后端基础架构之前将其御于门外。
立刻行动
Akamai 助力企业未雨绸缪,立即付诸行动。依托我们现有的边缘、API 和应用安全平台,并将其扩展至具备 MCP 感知能力的智能防御体系,我们能够协助团队精准识别 MCP 的演进动态、在试点实验阶段筑牢切实可行的安全护栏,并在风险暴露面不断扩大时实现稳健的风险管控。
通过这种方式,企业可以在当下积极拥抱 MCP 架构,同时放心依托 Akamai 的安全实力。随着 MCP 应用的不断深入,我们将同步升级您的安全防护、监测能力与控制力。
标签