Less than a month after the Model Context Protocol’s 2026-07-28 specification shipped a stateless protocol core on schedule, MCP’s lead maintainers — David Soria Parra and Den Delimarsky — published a follow-up on August 22: a roadmap for “the next specification release and beyond,” organized into five priority areas. I fetched the post directly at blog.modelcontextprotocol.io/posts/mcp-roadmap/ rather than relying on a secondary paraphrase, since roadmap posts are exactly the kind of source that gets flattened into vaguer claims once it passes through an aggregator.
Four of the five priorities are the sort of steady infrastructure hardening you’d expect from a protocol that’s already moved close to half a billion downloads a month across its Tier 1 SDKs. The fifth is more interesting, because it’s the maintainers admitting out loud that a foundational piece of MCP’s security model doesn’t actually fit how agents run in production.
The Admission: OAuth Was Built for Humans With Browsers#
MCP’s current authorization model leans on browser-based human approval — the familiar “click to authorize this app” flow that OAuth was designed around two decades ago, when the thing requesting access was assumed to be a person sitting at a keyboard. The roadmap says this plainly: that model “doesn’t fit cloud-based agents.” A Claude Code session running unattended in a CI pipeline, a background subagent spawned at 3am, an agent invoked by a webhook — none of them have a browser tab to click through, and building infrastructure that pretends they might is the kind of design debt that only gets more expensive the longer it’s deferred.
The fix under development, filed as “Agent Identity and Enterprise-Ready Security,” standardizes how MCP recognizes an agent as its own identity rather than a proxy for a human’s browser session. Three mechanisms are named specifically:
- Demonstrating Proof of Possession (DPoP) — binds a token to the specific client holding it, so a stolen bearer token alone isn’t enough to impersonate the agent.
- Workload Identity Federation — short-lived, cryptographically-verified identity issued by a platform (AWS IAM, GCP, Azure, Kubernetes, Okta) instead of a static credential.
- Enterprise-managed authorization — org-level policy control over what an agent identity is allowed to touch, without a human re-approving every session.
None of this is invented from scratch. Anthropic shipped Workload Identity Federation for the Claude API in June, replacing static sk-ant-... keys with short-lived OIDC tokens precisely because long-lived secrets sitting in CI configs are a liability that “fails loudly” only after something’s already gone wrong. MCP’s roadmap is now proposing the same pattern at the protocol level, for every MCP server an agent talks to, not just the Claude API itself. The maintainers also say they’re engaging directly with OAuth standards bodies — a sign this isn’t a unilateral MCP extension but an attempt to get agent identity recognized as a first-class case in the underlying spec that browser-based auth has quietly assumed to be human-only for twenty years.
The Other Four Priorities#
Agentic messaging primitives. The current request-response pattern doesn’t cover everything agent workloads actually need — the roadmap calls out server-initiated events (webhooks and channels) and maturing the Tasks extension, which only moved out of the protocol core into its own io.modelcontextprotocol/tasks namespace in the July spec, toward full specification inclusion.
HTTP-native transport unification. The July spec already made the protocol core stateless and header-routable. This priority extends that further, including running local servers over Streamable HTTP instead of stdio — collapsing the local/remote transport split that’s forced server authors to support two different code paths.
Improved primitives. Two separate problems bundled together: tool-call results currently have no clear contract for what shape a response takes, and large tool catalogs don’t scale well when a client has to ingest every tool’s full schema up front. The fix is progressive discovery — a server presents a smaller initial catalog and expands it as a conversation narrows, rather than dumping everything into context on connection.
SDK developer experience. Conformance testing, more intuitive APIs, and documentation investment across the Tier 1 SDK languages — unglamorous, but this is the layer every other priority on this list depends on actually being usable.
The roadmap post doesn’t attach dates or version numbers to any of these — a deliberate choice, and consistent with how MCP has generally under-promised on timelines since the confusion earlier this summer over whether the July 28 release candidate had actually shipped. There’s no adoption-metrics refresh in this post either; the half-billion-downloads-a-month figure and the Honeycomb 20%-of-queries-are-agents data point both come from the July spec announcement, not this one.
Why the Identity Piece Matters More Than It Sounds#
It’s easy to read “agent identity and enterprise-ready security” as a compliance checkbox and move on. It isn’t one. The gap it’s closing is structural: every agentic coding tool that runs unattended — Claude Code’s background subagents, a scheduled cron-triggered session, a CI pipeline invoking an MCP server on a merge — currently either has to fake a human OAuth flow, fall back to a static credential, or route everything through an authorization server built around a browser that was never going to be there. That’s the same category of problem sandbox.credentials and Claude’s own Workload Identity Federation were built to solve at the application layer. MCP proposing to solve it at the protocol layer means every MCP server, not just Anthropic’s own tooling, gets a native answer instead of each vendor inventing its own workaround.
That’s the actual stakes of a protocol crossing a billion downloads on its flagship SDKs: the parts of it that still assume a human is present stop being an edge case and start being the thing blocking the next order of magnitude of adoption. This roadmap is MCP’s maintainers saying, in public, which assumption they’re removing next.
Sources:
- MCP Roadmap Update: Five Priority Areas — MCP Blog, August 22, 2026
- The 2026-07-28 MCP Specification — MCP Blog, July 28, 2026 (adoption metrics cited)
- This blog’s prior coverage: MCP’s Stateless Spec Just Shipped for Real and Claude’s Workload Identity Federation Kills the API Key