MCP's 2026-07-28 revision goes stateless, turning planted prompts into reusable credentials

A protocol without sessions

The 2026-07-28 revision of the Model Context Protocol removes the initialize handshake and the Mcp-Session-Id header, the two mechanisms that previously pinned every call to a single server process. According to a dev.to analysis by an MCP server author, the change — introduced through spec proposals SEP-2575 and SEP-2567 — means any request can land on any instance behind a plain round-robin load balancer, with no sticky sessions and no shared session store. A stateless MCP server now behaves like any other HTTP workload: serverless functions, auto-scaling and round-robin dispatch all work without instance coordination.

The metadata that used to be exchanged once per connection — protocol version, client identity, capabilities — now travels in a _meta block on every request. Tool listings also became explicitly cacheable, with ttlMs and cacheScope hints. The author flags a side effect: a poisoned or stale tool catalog now has a wider blast radius, because every client and intermediary may share the same cached copy instead of the per-connection lists of the old model.

Handles are the new credentials

For servers that genuinely need state across calls, the spec's replacement is the explicit-handle pattern: a tool call mints a handle, and the model passes that string back as an ordinary argument on later calls. The official framing presents this as a feature — state becomes visible to the model, auditable in logs and easier to debug than transport metadata.

The consequence, which VentureBeat crystallised in a September 5 report, is that a prompt an attacker plants can now do the work of a stolen credential. An attacker no longer needs to compromise the server, a token vault or the transport. They need to place a string in a context window the model trusts, and later get the model to hand it back. Each endpoint decides what a handle authorizes, and as the dev.to author notes, the default in most servers will be to accept any string carrying the right prefix.

Three routes to abuse

The first is retrieval. An agent reads a Jira ticket, a GitHub issue or a web page through a tool, and that content is attacker-controlled text returned as plain tokens. If a handle from an earlier legitimate call is still sitting in the context window, the injected text can reference it by name and steer the model into replaying it.

The second is tool output. A read-style tool that returns fetched text verbatim — which the author says describes most read-oriented MCP tools — can deliver a handle and an instruction inside the same response. Nothing in that payload is a system prompt or an API key; it is a string from a tool the agent was told to call, containing both a credential and directions for using it.

The third is new to this release. The 2026-07-28 revision also formalises MCP Apps, where a server renders HTML that the client displays in a sandboxed iframe inside the IDE or agent window. Per VentureBeat's analysis, stored XSS can now appear in HTML rendered inside AI clients, sitting above terminals, filesystems and every other connected MCP server. A sandboxed iframe contains the browser exploit, but not the agent — which runs beside it holding the credentials of the person who launched it.

Enforcement moved to the endpoint

The protocol does not enforce security, and the dev.to analysis stresses that the revision is explicit about not starting now. Enforcement has shifted to gateways and endpoints, and it has become per-request: every call must be inspected, not just the start of a session. The release's OAuth-native authorization work mints tokens per server and binds them to an audience, so a token for one server must not replay against another — and performing that validation is the server's job, not the protocol's.

This is already in production rather than hypothetical. VentureBeat reports that all four Tier 1 SDKs spoke the new version by the end of day one, Cloudflare's Agents SDK supported it from day zero, and Sentry and Linear were already on it. The AWS Architecture Blog published a pillar-by-pillar review on September 1, and a twelve-month deprecation policy locks the changes in through at least mid-2027. The dev.to author's core warning is that most servers now running the new surface have not added per-request handle validation, because the pattern is brand new and nothing in the SDKs implements it for them.

Why it matters

The stateless redesign solves a genuine operational problem — horizontal scaling without sticky infrastructure — by relocating protocol state into the one place prompt injection already dominates: the model's context window. That turns every fetched ticket, issue and web page into a potential credential carrier, and it transfers responsibility for access control from the protocol layer to individual server operators. If you run an MCP server on the 2026-07-28 revision, per-request handle and token validation is no longer optional hardening; it is the security boundary itself.