Sunday, 20 September 2026 Login

Virtual Tech. Real Impact.

BREAKING
Remote Workflows

MCP Spec Turns Prompts Into Stolen Credentials

MCP Spec Turns Prompts Into Stolen Credentials - mcp spec

The Model Context Protocol (MCP) shipped a major update on July 28, introducing a stateless core that scales on ordinary HTTP and a new 12-month deprecation policy. By the end of the first day, Cloudflare’s Agents SDK had support in place, with customers like Sentry and Linear already adopting the new standard. While coverage has focused on the protocol’s scalability improvements, the update fundamentally shifts where security obligations fall. The new specification moves enforcement from the protocol layer to your endpoints and developers, creating attack surfaces that existing network-layer tools cannot see.

Three New Attack Vectors

This design change introduces three new attack vectors that live on the endpoint rather than the network. A Censys scan found 12,520 MCP services exposed to the public internet, and OX Security reported a design flaw in the STDIO transport that put as many as 200,000 servers at risk. The NSA’s Artificial Intelligence Security Center warned that adoption has outpaced the protocol’s security model. These risks compound because the session is no longer the unit of control; each request is treated as an independent unit.

When a handle is merely a string within a conversation, anyone able to insert or read that string can exploit it. A prompt-injection payload in a Jira ticket or a tool response can hand an attacker a valid handle without ever touching the server. The new spec enables handle hijacking, and the security work that used to happen at the session layer now has to happen deliberately on the endpoint. This is a different problem than the permissive servers or missing authentication that dominated previous coverage.

Historically, enterprises have relied on the session layer to enforce trust, assuming that once a connection was established, the subsequent traffic was implicitly authorized. This model worked when state was tied to a persistent connection. The new MCP spec breaks that assumption, forcing organizations to inspect and validate every single request independently. The security architecture must evolve alongside the protocol, or the organization inherits an invisible attack surface.

Stored Cross-Site Scripting Risks

The first new vector is stored cross-site scripting (XSS) in MCP Apps. The specification allows a server to ship interactive HTML rendered in a sandboxed iframe by the host. An attacker stores malicious HTML or JavaScript through an MCP tool; when an agent or another user views it, the script runs inside the app’s interface. The sandbox limits full takeover, but the client is layered above source code, terminals, filesystems, and every other connected MCP server.

The second vector is handle hijacking, which relies on prompt injection. Because handles are untrusted strings within the conversation, a payload in a tool response can hand an attacker a valid credential. This requires per-request handle validation rather than hygiene at the conversation layer. The third vector involves enforcement gaps on the network. Since state has moved out of the transport and into the application, security controls that used to happen automatically at the session layer now have to be implemented deliberately at the endpoint.

Related: Prompt injection tops security threat lists

Microsoft’s tool-poisoning research illustrates why this shift bites once agents move from reading to acting. Backslash and Akamai have each mapped where the new spec opens the attack surface. These threats begin on the other side of the boundary where network visibility terminates, making them difficult to detect with traditional security tools.

Platform teams must treat the migration and security transition as the same work. Exposure of MCP Apps requires identifying which servers can render HTML UI and setting a policy for reviewing that code, similar to third-party scripts. Enforcement needs to move to the request level, where every call must be inspected rather than just the session start.

Hardened Authorization Model

The hardened authorization model requires OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, and audience-bound tokens. A token issued for one server must not replay against another. An identity-aware gateway must sit in front of every server and reject any call without a valid, audience-bound token. Handles are considered untrusted input, and conversation-layer hygiene must remove or flag instruction-like content in tool outputs and retrieved documents.

Endpoint visibility is also critical. An identity-aware gateway enforces the request but lacks knowledge of the MCP Apps rendering or local server operations. Platform teams need a different tool to build visibility for the host process, local MCP servers, and client rendering. Unit tests will not identify what breaks here because a spec change looks fine in isolation but fails in a live agent loop. Organizations must run migrated servers against real models driving real workflows and watch for state that leaks across server instances or handles reused across scopes.

Deprecation Timeline and Strategy

Roots, sampling, and logging are deprecated with this spec, as is the legacy HTTP+SSE transport. The 12-month clock started on July 28, and removal comes no earlier than mid-2027. Deprecation windows always seem long, and then they feel quite short. Companies that consider this a simple migration will deliver the new spec with the same security posture they had for the stateful protocol, leaving them misaligned with the current threat surface. Those that treat this as a security transition, moving enforcement to the request level and governing MCP Apps before they proliferate, will be the ones whose agent deployments outlast contact with a genuine attacker.

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *