MCP went stateless. So who guards the gate now?
Any request can now hit any instance behind a plain load balancer. That helps hosting. The security work now moves to identity and the gateway.
MCP is the Model Context Protocol, the now-standard way an AI assistant reaches out and calls your tools and data.
Under the old MCP spec, once a user started a conversation, every follow-up request had to return to the same server instance, because that instance held the conversation state in memory. That’s a sticky session, and it’s a pain to run at scale.
You can’t spread load evenly, you can’t scale to zero, and if that instance falls over, the conversation dies with it.
The new MCP spec landed on July 28, and the release post calls it the most important since remote MCP first launched.
It deletes all of that. It went stateless: any request can now hit any instance behind an ordinary load balancer.
For hosting and scaling MCP, this is a gamechanger.
The cost shows up in security. Going stateless leaves the server count alone and moves the security burden to identity and the gateway. Let’s dig in to see why that matters.
What “stateless” changed
Stateless means the server doesn’t have to remember you between requests. The new spec drops the opening handshake, drops the session ID header that used to pin you to one instance, and moves the protocol version and capabilities into the metadata of each request.
The useful analogy is a coffee shop. The old way had one barista who remembered your order, so you kept going back to her counter. Stateless is a shop where you carry a ticket with the whole order on it, and any barista can serve you.
Open more counters at lunch rush, close them at night, nobody loses their place.
That’s the same technique that enabled the web scale 26 years ago: servers stopped having to remember you between clicks, so any server could answer any request.
MCP is finally getting its version of that. It inherits decades of boring, well-understood HTTP plumbing (load balancers, content delivery networks, standard monitoring), and the server author gets to delete a pile of session-management code.
Where the security work goes
Going stateless doesn’t remove the security work. It relocates it.
Per-request authentication isn’t new: under the old spec every HTTP call already carried its own token, so the identity check already fired on each request. What the session used to hold was your protocol version, your capabilities, and the conversation so far, all safe inside the server’s memory.
That’s the part that now rides in the open on every call, and per the TypeScript SDK’s migration guide it’s untrusted input the developer has to cryptographically seal so it can’t be forged.
So the real change is narrower than “auth moved from once to every request“: the state the server used to guard for you is now yours to protect in transit.
That’s the enforcement point There Is No Runtime Moat to Buy landed on: identity and the gateway.
ELI5: why the carried-over state has to be sealed
Old way: the server kept your conversation in its own memory, where you couldn’t touch it. New way: that state travels with your request, like a coat-check ticket you carry yourself. If the shop doesn’t stamp the ticket in a way that can’t be faked, a customer could rewrite it to claim someone else’s coat. Sealing the state is that tamper-proof stamp.
The MCP servers already running are messier than the new spec.
A May 2026 study of 7,973 live remote MCP servers found 40.55% expose their tools with no authentication.
A separate study of 1,899 open-source servers found 66% carry code smells and 5.5% exhibit MCP-specific tool poisoning.
The new spec tightened the auth contract on paper. But, it obviously didn’t change the servers already in production.
Enterprise-Managed Authorization (EMA) helps at one layer: sign-in. It routes that through your company’s identity provider, and it’s been stable since June 18, with Okta, Microsoft, and servers like Atlassian, Figma, and Linear already on it.
Its own spec is explicit about where its control ends: the identity provider’s visibility “is limited to the process of issuing the access token“ and “does not extend to the actual MCP traffic“ that follows.
ELI5: authentication vs. runtime authorization
Authentication is checking who’s knocking. Runtime authorization is deciding what they’re allowed to do once you let them in. EMA does the first for MCP. The second (which records an agent can read, which actions it can take, what limits apply) is still something each enterprise has to build for itself.
The server-count problem is untouched too. Statelessness changes how each server is hosted, not how many you run. It retires zero servers, and adds one more protocol generation to carry.
And it leaves most of the shadow-AI burden map from Shadow AI in 2026: The Enterprise Playbook where it was. The release moves one lever on that map (OAuth scope).
Local execution, package supply-chain risk, anonymous server authors, and runtime authorization are unchanged.
Earlier MCP vs the new MCP, side by side
For a dev-team lead, the old and new specs differ on the operational pieces.
Two changes in that table will consume migration time.
Long-running work used to ride a held-open stream that could resume where it left off if the connection dropped. That resumability is now gone: a broken stream now loses the in-flight request, so anything running for minutes or days has to be rewritten to poll the new Tasks extension.
Separately, the old pattern where a server called back to the client mid-run, to ask a question or request a sample, is replaced by Multi Round-Trip Requests: the server returns an “input_required” answer and the client retries with the inputs.
Both are the official replacements, but neither is a simple swap. If your servers use either one, that’s where your migration weeks go.
A small, stateless core with the extra features split out into optional add-ons is the groundwork for the multi-agent setup I described in Monotheist vs. Polytheist.
The case for migrating anyway
The strongest argument for migrating sooner is infrastructure.
Statelessness is more than ops gimmick. It’s the precondition for running MCP on the serverless and edge infrastructure that regulated enterprises deploy on.
You can’t hold a sticky, always-on connection on scale-to-zero infrastructure.
And by putting MCP on ordinary HTTP, with standard method and name headers plus OpenTelemetry trace context, the new spec makes remote servers watchable for the first time: your tools can finally see which tool a request called, if not yet which records it touched.
That matters, because the blindness was real: in that same Shadow AI Playbook I mapped how much MCP runs locally, out of sight of the security tooling meant to watch it.
Watchable remote hosting is what addresses that.
So the migration I’m suggesting you to roll out in stages may be what shrinks the burden — but only the blindness part, and only if you move to remote, managed hosting.
Here’s the catch: that visibility only comes with the new transport, so putting the gateway in front first gets you the security control now and lets you delay the rest of the migration. You get one win now, the rest later.
What I’d do Monday
None of this adds up to “upgrade now.” So, I’d work in this order.
Count what you run. I’d start by inventorying every MCP server in play, local and remote. The count is the sprawl problem, and the spec did nothing to it.
Centralize auth first. I’d route MCP sign-in through your identity provider now, using EMA. It’s stable, it’s available today, and it pays off now without touching the transport migration at all.
Put the gateway in front. Think of it as a front desk for every agent request: one place that checks the badge, logs the visit, and inspects what’s being carried in. That’s where the security work actually landed, so I’d own that enforcement point before migrating, not after.
Stage the transport, don’t rush it. All four flagship SDKs shipped stable with the launch (TypeScript and Python v2, Go 1.7, C# 2.0; only Rust is still in beta), so the wait-for-GA reason is gone. The migration is a breaking rewrite either way, and everything the release deprecates keeps working at least twelve months. If you are building new? Go stateless-first now, since the transport you’d otherwise reach for is already deprecated. Staging is for existing servers that lean on resumability, sampling callbacks, or held-open streams. Those are the rewrites worth timing to your needs.
Build runtime authorization yourself. This is the piece you can’t buy or defer. EMA gets an agent through the door as the right identity. Deciding what it’s allowed to do once inside is still unbuilt, and it’s still yours.
Statelessness is real, which is why the first move is identity and the gateway, not the upgrade button.
What I’m watching now is the race underneath: whether the remote-server population cleans up its authentication faster than teams migrate onto it. Right now exposure is running ahead of the fix.
I’d find out whether your stack is ahead of that cleanup or behind it.
If you’re running MCP servers today, official or shadow: do you know how many, and who checks what the agents can touch once they’re inside?
References:
MCP 2026-07-28 specification changelog: https://modelcontextprotocol.io/specification/2026-07-28/changelog
MCP 2026-07-28 release announcement: https://blog.modelcontextprotocol.io/posts/2026-07-28/
MCP beta SDKs post: https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
MCP TypeScript SDK migration guide: https://ts.sdk.modelcontextprotocol.io/v2/migration/support-2026-07-28
Enterprise-Managed Authorization (EMA) extension spec: https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization
Enterprise-Managed Authorization announcement: https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
Anthropic, “Bringing MCP 2026-07-28 to Claude”: https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
Zhou et al., “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers,” arXiv:2605.22333: https://arxiv.org/abs/2605.22333 [Note: preprint, not peer-reviewed]
Hasan et al., “Model Context Protocol (MCP) at First Glance,” arXiv:2506.13538: https://arxiv.org/abs/2506.13538 [Note: preprint, not peer-reviewed]