Key takeaways
On July 28, 2026, the Model Context Protocol (MCP) will officially transition to an enterprise-grade, stateless architecture.
By moving to a stateless model and introducing rich UI apps and async tasks, the protocol shifts the responsibility of building critical security boundaries now entirely up to the developers.
The update successfully eliminates major historical security risks, including protocol-level session hijacking, unsolicited server prompts, and weak authentication methods.
The introduction of an application-managed state, rich interactive AI interfaces, and long-running asynchronous tasks, however, creates new avenues for abuse.
If not properly secured, these new capabilities could enable unauthorized access to customer data, user-targeted phishing through trusted AI experiences, the bypass of enterprise security controls, and service disruption through abuse of background processing workflows.
The upcoming MCP 2026-07-28 specification represents the most significant architectural evolution of the Model Context Protocol (MCP) since it began. What began as a local, single-user AI integration tool is transforming into a platform capable of supporting enterprise-scale, cloud native deployments.
Following the release candidate published on May 21, 2026, the final specification is scheduled for release on July 28, 2026, accompanied by a formal 12-month deprecation window for select legacy functionality.
Attack surface evolution
To achieve this enterprise-ready foundation, the update completely overhauls how the protocol handles data and execution. It introduces a stateless architecture supported by multi–round-trip requests, standardized new HTTP headers, and a universal _meta object for contextual messaging. Furthermore, the specification formalizes MCP apps and asynchronous tasks, while elevating OAuth integration to a first-class citizen.
While much of the discussion around these features focuses on scalability and interoperability, their structural impact on the protocol’s attack surface is equally profound. As the security model shifts, some long-standing protocol-level risks are mitigated or removed entirely, while new responsibilities move squarely to MCP application developers (Figure 1). Ultimately, while these changes improve the foundation, implementation choices now dictate the overall security posture.
Fig. 1: Evolution of the MCP attack surface in the new specification
Attack surfaces that were reduced or eliminated
Previous versions of MCP exposed several security risks through protocol-managed sessions, server-initiated communication, and less mature authentication requirements. The new specification redesigns or removes several of these mechanisms, reducing the protocol-level attack surface. These mechanisms include:
Protocol-level session hijacking
Unsolicited server prompts
Weak authentication methods
Protocol-level session hijacking
Previous MCP versions relied on a stateful initialization process that established a long-lived session using the Mcp-Session-Id header. These session identifiers are usually high-value targets because attackers who obtain them can impersonate authenticated users.
The new specification completely removes these protocol-managed sessions, eliminating this specific attack vector. However, developers must now build their own secure state management mechanisms (which we will examine later in this blog post).
Unsolicited server prompts
Earlier MCP versions allowed servers to send unexpected requests or prompts to clients at arbitrary times via Server-Sent Events.
The new rules strictly limit this behavior, preventing compromised servers from silently interrupting users with unprompted, malicious interactions.
Weak authentication methods
The update forces a move to strict OAuth 2.1 requirements, drastically cutting down authentication risks. By eliminating legacy password and implicit grants, and mandating modern protections like Proof Key for Code Exchange (PKCE), the protocol severely restricts how credentials and tokens can be leaked or exploited
Collectively, these changes dramatically reduce the authentication-related attack surface and session blast radius that existed in previous MCP deployments.
New attack surfaces introduced by the specification
Although the protocol removes several classes of vulnerabilities, it also introduces new areas where security depends heavily on implementation quality, including:
Cross-agent workflow hijacking
Client-controlled metadata manipulation
Header confusion and data exposure via headers
MCP Apps and stored cross-site scripting
Exploit risks in long-running background tasks
Cross-agent workflow hijacking
The push for statelessness introduces subtle security challenges. In enterprise environments, AI interactions are not always a simple, single-request conversation; they often require a sequential chain of events. For example:
Requesting clarity: A tool might pause mid-task to ask the user for missing details
Verifying progress: A long job might require the system to regularly request updates
Pausing workflows: A complex process might pause for an hour while waiting for human approval, then resume execution from its exact previous state
Because the new MCP is stateless, it doesn't use permanent sessions to remember who is who. Instead, it introduces tracking identifiers and state objects that the server hands to the client. The client then passes these back whenever they are ready to resume the execution flow, practically giving the client full control over the task's state.
The security concern is straightforward: Because these tracking IDs and state objects come directly from the client, the server cannot thoughtlessly trust them. Figure 2 illustrates that if an MCP server uses predictable tracking IDs or fails to strictly validate the integrity of the received state object, an attacker could guess or alter these values to:
Hijack another user's active workflow
Access information belonging to a different agent
Trigger unauthorized, cross-tenant actions
Fig. 2: Illustration of tracking ID guessing and state tampering
While the official MCP specification explicitly warns developers to verify the integrity of these objects, it does not lay out a specific standard or implementation, leaving the job of building that security layer entirely to individual server developers.
Client-controlled metadata manipulation
The new specification introduces a _meta object that allows clients to attach custom metadata to virtually any MCP message. Even in a simple single request, an attacker could supply malicious key-value pairs, such as {"tenant": "admin", "authenticated": true}.
Because these fields lack cryptographic signing, if a server thoughtlessly trusts this metadata for routing or authorization decisions, a single malicious request can instantly lead to privilege escalation or cross-tenant data access.
Header confusion and data exposure via headers
The specification introduces MCP-specific HTTP headers such as Mcp-Method and Mcp-Name that help intermediaries, proxies, gateways, and servers consistently understand MCP requests and route them correctly.
However, those headers also introduce two new security risks:
Protocol confusion (desync) attacks: Attackers can send conflicting values between the HTTP headers and the JSON-RPC request body, exploiting a disagreement between two different communication protocols — HTTP and JSON-RPC — to throw the back-end infrastructure out of sync. This inconsistency can trick proxies and back-end servers into interpreting the same request differently, allowing attackers to bypass security controls, evade monitoring, or mask malicious actions.
Data leakage via x-mcp-header: This new directive lets developers map specific tool arguments directly into HTTP headers. This helps proxies route traffic faster without parsing the full request body. However, if developers accidentally map sensitive inputs like API keys, tokens, or personally identifiable information (PII), those secrets are pushed straight into the headers. Once there, they become visible to every load balancer, proxy, and logging system along the path.
MCP Apps and stored cross-site scripting
One of the most exciting updates to the MCP is changing MCP Apps to a first-class protocol extension. MCP Apps are the interactive visual panels that you see inside AI applications like Claude Desktop (e.g., interactive forms and dashboards, document viewers, workflow and task tracking screens).
While these rich interfaces massively improve the user experience, they also bring traditional web browser risks like stored cross-site scripting (XSS) into the AI ecosystem. For example, an attacker may store malicious HTML or JavaScript through an MCP tool. When another user (or an AI agent) views that content, the malicious script automatically runs inside the app's interface.
While the MCP specification requires the agents to execute these scripts inside a sandboxed <iframe> to block malicious actors from completely taking over the AI agent, users are still at risk. An attacker can still use the compromised panel to display deceptive content, execute phishing campaigns for sensitive information with fake prompts, steal any user data currently visible inside that specific panel, and send that stolen information back to their own servers (Figure 3).
Fig. 3: Illustration of MCP Apps exploitation through stored XSS
Exploit risks in long-running background tasks
The introduction of long-running tasks creates a massive denial-of-service (DoS) vector that relies on one-way interactions. Because task creation is cheap for the client but resource-intensive for the server, an attacker can send a single request to spawn an expensive operation (consuming CPU, memory, or database storage) and immediately disconnect.
This one-way asynchronous exploitation method forces the server to process heavy workloads even after the client is gone, easily exhausting server resources.
Conclusion
The MCP 2026-07-28 specification marks the protocol's transition from local use to enterprise-scale deployment. From a security perspective, the changes are not simply incremental improvements. They fundamentally reshape where security responsibilities reside: Security decisions that were previously enforced by the protocol are increasingly delegated to MCP server developers and platform operators.
As MCP adoption accelerates across cloud environments, the most important security question is no longer whether the protocol itself is secure. Instead, security teams must determine whether the applications built on top of it correctly implement the new trust boundaries, state management mechanisms, and execution models introduced by the specification.
To properly secure these new attack surfaces, security teams must treat all client-provided state data and metadata as untrusted inputs by enforcing strict cryptographic verification, output encoding for AI-generated visual panels, and robust resource quotas for asynchronous tasks.
Navigating this shift requires a proactive defense architecture that blocks exploits before they ever reach your back-end infrastructure.
Act now
Akamai enables organizations to act now. By building on our existing edge, API, and application security platform and extending it with MCP-aware intelligence, we help teams identify where MCP is emerging, apply practical guardrails during experimentation, and manage risk as exposure grows.
This approach allows organizations to adopt MCP today while relying on Akamai to evolve protection, visibility, and control as MCP use develops.
Tags
