On May 21, 2026, the maintainers of MCP published a release candidate for the next version of the specification, dated 2026-07-28. The main change is that MCP is moving from stateful to stateless, where every request from an AI client to an MCP server is now self-contained, with no persistent session established upfront. This eliminates the need for sticky routing and shared session stores.
The RC also includes a section called "Authorization Hardening". It's the most important change getting little coverage. It contains six Specification Enhancement Proposals (SEPs) that pull MCP's authorization story closer to how OAuth 2.0 and OpenID Connect work.
I previously wrote about this on my personal blog. Expanding on it, these six bug fixes pair into three problems that MCP has been carrying since auth was first specified. Each cluster points toward a larger open question that the hardening does not fully solve.
Pattern 1: Who are you talking to?
Two SEPs, SEP-2468 (iss validation / RFC 9207) and SEP-2352 (credential binding to issuer), pair together.
SEP-2468 requires clients to validate the iss parameter on authorization responses. This mitigates against mix-up attacks, where a response from one authorization server gets replayed against a different one. This attack exists in regular OAuth, but MCP makes it more likely: a single client connects to many servers at once, each backed by its own authorization server, creating more trust boundaries to confuse.
SEP-2352 binds client credentials to the specific authorization server that issued them, so that if a resource migrates to a new server, the old credentials don't silently keep working.
For standard OAuth, most clients talk to one or two authorization servers. With MCP, there are many. Both of these are client-side validations. The spec doesn't specify what to do when a check fails.
Multi-hop delegation
MCP has no standard mechanism to carry trust boundaries across multi-hop delegation. Agent chains (where a user delegates to an agent, which re-delegates to a sub-agent) leave operators passing tokens through unchanged (a security problem) or doing ad-hoc token exchange that is non-standardized and hard to audit.
Pattern 2: How long does this credential live?
SEP-2207 (refresh tokens from OIDC-style ASes) and SEP-2351 (.well-known discovery suffix) pair together.
SEP-2207 documents how an MCP client should request refresh tokens from an OpenID Connect-style authorization server. It gives agents a spec-blessed path to extend their access after an initial token expires without requiring the user to re-authenticate.
SEP-2351 standardizes the URL path suffix used for MCP's discovery endpoint. This is the location where a client looks up the authorization server backing a given MCP server.
Both of these SEPs are preconditions for credentials that work reliably over time, not just at the moment of initial authentication. SEP-2207 handles what happens when a token expires mid-task. SEP-2351 handles whether the client can reliably find the AS to begin with.
Pattern 3: Who authorized this, and for what?
SEP-837 and SEP-2350 pair together.
SEP-837 fixes a failure in Dynamic Client Registration (DCR) where the MCP spec never told clients to declare their OpenID Connect application_type during registration. Authorization servers would fill the gap with their default: web. The problem is that web clients aren't allowed to use localhost or custom-scheme redirect URIs. That is exactly what every CLI tool and desktop app relies on.
SEP-2350 specifies that when an agent needs additional permissions mid-task (step-up authorization), the new scopes stack on top of existing ones rather than replacing them
Both of these detail the authorization boundary. They define what a client is allowed to do, and how that allowance is defined and extended as it operates. SEP-837 establishes the correct identity of the client at the moment of registration so the AS treats it appropriately from the start. SEP-2350 governs how that authorization evolves as the task escalates.
Issue trails across Claude Code, Copilot CLI, Cursor, and multiple MCP servers including Meta Ads and Asana confirm that DCR failures are the dominant auth pain point today. SEP-837 closes the application_type variant at the protocol level. Yet the broader category of DCR-related registration failures remains an active surface.
SEP-2350's scope accumulation is the right semantic, but it opens a real question: who authorizes step-up? Today most systems rely on the user. Step-up goes through a browser consent flow: the user clicks Allow. This model breaks for autonomous agents running overnight jobs or background tasks where no user is present.
Why this matters
These gaps aren't a failure of the SEPs. Mature protocols develop incrementally, closing well-defined problems one at a time. An MCP control plane solves the remaining infrastructure gaps.
That is why we built Runlayer. It knows which authorization servers back which MCP servers. It handles credential lifecycle and revocation. It detects shadow MCP usage. It monitors agent behavior. It closes the gaps MCP leaves open.
