If you have AI agents wired into production through the Model Context Protocol — and in 2026, you probably do — the spec underneath them is about to change more than it has since it launched. The 2026-07-28 release candidate is what people are already calling MCP 2.0, and unlike most protocol revisions, two of its changes land directly on the reliability and security surface SRE teams own.
I want to cut through the changelog and answer one question: what does this actually change for the people who keep these agents running at 3am? Two things. The protocol goes stateless, and the auth gets hardened. Both are good news. Both have a migration cost. And you have about ten weeks.
Change 1: MCP goes stateless
In the spec you’re running today, every MCP connection opens with an initialize handshake that returns an Mcp-Session-Id. That header pins the client to a specific server instance for the life of the session — which means the moment you put more than one MCP server behind a load balancer, you need sticky sessions, session affinity, and somewhere to keep per-session state that survives a pod restart.
If that sentence gave you a flashback, you’ve operated stateful services before. You know exactly which failure modes follow: the rebalance that drops live sessions, the deploy that can’t be rolling because state is in-memory, the load balancer config that’s load-bearing in a way nobody documented.
The release candidate deletes all of it. SEP-2567 removes the Mcp-Session-Id header and the protocol-level session that came with it. The core becomes stateless and scales on ordinary HTTP infrastructure.
A stateless MCP server is just a horizontally-scalable HTTP service. Any instance can serve any request. That’s the whole reliability story, and it’s a big one.
For operators this is the most consequential line in the spec. It means:
- No session affinity. Your load balancer goes back to being a load balancer.
- Trivial horizontal scaling. Add instances; route round-robin; nothing breaks.
- Clean rolling deploys and restarts. There’s no session to lose, so a pod cycling out stops being an incident waiting to happen.
- Cheaper failure recovery. A dead instance takes nothing with it.
This is the kind of change that makes the MCP gateway pattern materially simpler — the gateway no longer has to reason about which backend owns a session. It’s the difference between operating a stateful cluster and operating a stateless web tier, and we have thirty years of well-understood tooling for the latter.
The migration cost: if any of your MCP servers keep state in the session today — accumulated context, partial tool state, per-connection caches — that state needs a new home (a request-scoped token, an external store, or eliminated entirely). Audit for this now. The servers that lean on session state are exactly the ones that need rework, and they won’t announce themselves.
Change 2: OAuth gets hardened
The second cluster of changes is six SEPs that each fix a sharp edge in MCP’s OAuth 2.1 deployment story. The one to know by name is SEP-2468: clients must validate the iss (issuer) parameter on every authorization response, per RFC 9207.
Here’s the attack it closes. In a mix-up attack, a client talks to more than one authorization server, and an attacker arranges for a response minted by authorization server A to be replayed against the client as though it came from authorization server B. Without issuer validation, the client can’t tell the difference and accepts a token it should have rejected. For an SRE tool wired into multiple identity providers — say, Okta for humans and a workload identity provider for services — that’s a genuine cross-tenant confusion risk. Validating iss on every response slams it shut.
This is the protocol catching up to the principle I argued in no anonymous inference endpoints: every call that reaches a model or a tool must carry a verifiable identity. The 2026 RC pushes that from “a thing good teams do” toward “a thing the spec requires,” aligning MCP authorization with OAuth 2.0 and OpenID Connect deployments you already run. The NSA’s 2026 MCP cybersecurity information sheet and the NIST AI Agent Standards work were the policy pressure; this is the protocol responding to it.
The migration cost: if you wrote your own MCP client (a lot of internal SRE tooling did), you now owe explicit iss validation. If you use an SDK, the work is upgrading and confirming the maintainers shipped it. Either way, this is a correctness change, not an optional hardening — skipping it leaves the mix-up door open.
The window you actually have
The release candidate is exactly that — a candidate. The final spec publishes July 28, 2026, and the roughly ten-week gap is deliberate: it’s the window for SDK maintainers and client implementers to validate the changes against real workloads before they’re standard.
Don’t read “ten weeks” as “ten weeks of slack.” Read it as a deadline for a three-part audit:
- Which of my MCP servers rely on session state? Those need a stateless rework before SEP-2567 lands as the norm.
- Which of my MCP clients are hand-rolled? Those need explicit
issvalidation per SEP-2468. - Which SDK versions am I pinned to, and have the maintainers shipped the RC changes? This determines whether your migration is a version bump or a rewrite.
The reason this matters more than a typical protocol revision: MCP is the tool-access layer of the AI-native SRE stack. When the layer that every agent reaches your production systems through changes its session model and its auth requirements in the same release, that’s not a library upgrade you schedule for “sometime.” That’s a reliability and security event you plan for.
The good news is that both changes point the same direction we’d choose anyway: stateless services and identity that survives every hop. The protocol is finally making the safe path the default path. Use the ten weeks to get there on your terms instead of the spec’s.
Reference: the official 2026-07-28 MCP specification release candidate announcement.