The enterprise MCP rewrite moves security from the protocol to your developers

What is this?

The Model Context Protocol is getting its biggest structural change since Anthropic released it in late 2024. The MCP 2026-07-28 specification — release candidate published May 21, 2026, final version scheduled for July 28, 2026, with a 12-month deprecation window for legacy functionality — moves MCP from a local, single-user integration tool toward a stateless, enterprise-scale protocol built for cloud deployment.

On June 25, 2026, Akamai’s threat research team (Maxim Zavodchik, Segev Fogel and Gal Meiri) published a threat model of the new specification. Their finding is the reason we are covering it here: the rewrite genuinely closes several protocol-level vulnerability classes, but it does so by pushing the corresponding security decisions down to the developers and platform operators who implement MCP servers. The protocol becomes safer; whether any given deployment is safe now depends entirely on implementation quality.

How it works

Three older risk classes are reduced or removed outright. Protocol-managed sessions — the long-lived Mcp-Session-Id that an attacker could steal to impersonate a user — are gone, replaced by a stateless model. Servers can no longer push unsolicited prompts to clients at arbitrary times, which shuts a channel a compromised server could use to interrupt users. And authentication moves to mandatory OAuth 2.1, dropping legacy password and implicit grants and requiring protections such as PKCE.

The trade-off is a new set of surfaces where safety is a function of how each server is written, not of the protocol:

Removed / reduced by the protocol        Now the developer's responsibility
---------------------------------------  -------------------------------------------
Protocol-managed session hijacking       State-object integrity (workflow hijack)
Unsolicited server-initiated prompts     Trust in client-supplied _meta metadata
Weak / legacy authentication             Header vs. body consistency (desync)
                                         Not mapping secrets into HTTP headers
                                         Output-encoding MCP App UI (stored XSS)
                                         Quotas on long-running async tasks

Because the protocol is now stateless, the server hands the client a tracking ID and a state object and trusts the client to hand them back to resume a paused workflow. If a server uses predictable tracking IDs or fails to verify the integrity of the returned state, an attacker can guess or tamper with those values to hijack another user’s active workflow or trigger cross-tenant actions. The specification tells developers to verify these objects but does not standardise how.

A new _meta object lets clients attach arbitrary key-value pairs to almost any message, and those fields are not cryptographically signed. A server that trusts something like {"tenant": "admin"} for routing or authorization can be walked straight into privilege escalation with a single request. Similarly, new MCP HTTP headers (Mcp-Method, Mcp-Name) invite desync attacks when the header and the JSON-RPC body disagree, and an x-mcp-header directive that maps tool arguments into headers will leak secrets to every proxy and log on the path if a developer maps the wrong field. Finally, MCP Apps — the interactive UI panels now promoted to a first-class extension — import classic stored cross-site scripting into the agent surface (sandboxed in an <iframe>, but still enough to phish or exfiltrate what the panel can see), and cheap-to-spawn long-running tasks create a hit-and-run denial-of-service vector.

Why it matters

MCP is already the de-facto connective tissue between agents and enterprise tools, and adoption is accelerating into exactly the multi-tenant, cloud-hosted deployments this spec targets. The security question is shifting from “is the protocol secure?” to “did this server implement the new trust boundaries correctly?” — and the answer will vary server by server. The migration window (legacy support for 12 months) also means mixed fleets running old and new semantics simultaneously, which is precisely where desync and state-handling bugs breed. If your organisation ships or consumes MCP servers, the July 28 cutover is a scheduled event you can prepare for rather than a surprise.

Defenses

Akamai’s guidance, generalised for any team adopting the new spec:

1. Treat all client-supplied state and metadata as untrusted. Sign and integrity-check state objects; never make authorization or routing decisions from unsigned _meta fields. Use unpredictable, high-entropy tracking IDs and bind them to the authenticated principal server-side.
2. Reconcile headers and body. Ensure proxies, gateways and the server agree on Mcp-Method / Mcp-Name versus the JSON-RPC body; reject requests where they conflict to close desync gaps.
3. Audit x-mcp-header mappings. Never map API keys, tokens or PII into HTTP headers. Review these mappings before deployment and in code review, since the leak is silent.
4. Output-encode MCP App content. Apply strict output encoding and a tight content-security policy to any user- or tool-supplied HTML rendered in app panels; keep the sandbox, but do not rely on it alone.
5. Quota asynchronous tasks. Rate-limit and resource-cap task creation, and tie long-running work to an authenticated, accountable session so a single disconnecting client cannot exhaust the server.
6. Plan the migration. Inventory MCP servers and clients, track which speak the new stateless semantics, and avoid long-lived mixed-mode deployments where legacy and new behaviour can be played off each other.

Status

Item	Reference	Date	Notes
MCP 2026-07-28 release candidate	modelcontextprotocol.io	2026-05-21	Stateless architecture, MCP Apps, async tasks, OAuth 2.1
Akamai threat model	Akamai SIG	2026-06-25	Attack-surface shift analysis
Final specification	modelcontextprotocol.io	2026-07-28 (scheduled)	12-month legacy deprecation window

The headline is not “the new MCP spec is insecure” — it removes real protocol-level risks. It is that the responsibility for security has moved to the people building MCP servers, effective the July 28 cutover. Teams that treat the migration as an implementation-security project, not a drop-in upgrade, are the ones who will avoid inheriting the new surfaces.