On August 22, 2026, the MCP maintainers released a new roadmap, listing agent identity as one of five top priorities. The roadmap states:
“Today, MCP’s authorization model centers on a human clicking approval in a browser. This works well for interactive clients, but callers are increasingly agents running as cloud workloads: they carry their own identity, act on behalf of offline users, or delegate narrower permissions to sub-agents. We want MCP servers to have a standardized way to identify and trust these agent identities—built on existing standards rather than relying on pasted API keys and long-lived tokens.”
This highlights the shift in caller: from a human sitting in front of a screen to a cloud process carrying its own identity. MCP originally took off because of its simplicity—zero barrier to entry, write a script and it runs. Today, it introduces the complexity of enterprise identity layers. Agents need to run unattended, yet authorization approvals were stuck in the browser, driving this pivot. Across its timeline, MCP’s authorization mechanism has continually migrated from manual approval toward machine identity, and the 2026-08-22 roadmap establishes this evolutionary trajectory as the official direction.
There are two ways to look at this. The first is productivity leverage. Managing AI is like leading a team. By analogy, investing 5% effort to get 100% output yields a 20x leverage. To maintain high leverage, AI must have enough agency to work independently without stopping at every step to wait for human input, making autonomous authorization essential. Addy Osmani pointed out in “Long-running Agents” that once production agents run, humans are not at the screen; tasks like coding, scanning, or monitoring can run for hours or weeks, with some attached to event streams or database tables handling audits, anomalies, or routing. Teradata’s definition of autonomous agents also centers on independently selecting tools, sequencing actions, recovering from errors, and driving tasks forward without a human in the loop. A chat-window loop cannot support unattended operation.
From another perspective, many scenarios inherently require no human intervention. For instance, customer support agents handle user requests with no human sitting behind a screen waiting to approve actions. The MCP protocol provides specific mechanisms to bring humans back into the loop: pausing mid-tool execution to ask a human to decide, a design we previously analyzed in detail. But these scenarios demand a fully automated closed loop. Blocking approvals in the browser is like assigning a full-time supervisor to a background agent, negating the value of delegation.
Whether maximizing productivity leverage or serving scenarios that never needed humans in the first place, cloud agents must obtain authorization on their own. The early roadblock was that when Anthropic released MCP in 2024-11, it only supported stdio transport and single-process communication, with no session or authorization framework, assuming a developer sat in front of the screen clicking approvals. Tool calls were akin to local functions; this zero barrier drove MCP’s rapid adoption, but could not support unattended cloud processes.
To remove this hurdle, the protocol built out authorization capabilities in four stages: The first stage supported remote calls, where the 2025-03-26 changelog introduced an OAuth 2.1-based authorization framework (PR #133) and replaced HTTP+SSE with Streamable HTTP for remote deployments (PR #206). The second stage introduced machine autonomous credentials; the 2025-11-25 first anniversary post introduced extensions SEP-1046 and SEP-990, enabling machine-to-machine credentials and enterprise policy controls, allowing machines to present credentials to acquire tokens autonomously for the first time. The third stage brought platform-endorsed identity; on 2025-12-05, the Workload Identity Federation (WIF) proposal was opened as PR 1933 (SEP-1933), with platforms issuing short-lived, cryptographically verifiable JWTs. The fourth stage tackled narrow-permission delegation; on 2026-05-21, the IETF OAuth Working Group draft draft-ietf-oauth-identity-assertion-authz-grant updated to version 4, giving credential delegation draft-level standardization. The 2026-08-22 roadmap officially established this line as the official direction.
Each step forward introduces complexity that was deliberately avoided at the outset. Originally, one could write a script, spin up a server, and make calls without authorization or sessions; simplicity was why it took off. Now, to enable autonomous calls by cloud agents, the protocol is progressively layering in the complex machinery of enterprise identity.
The goal of the new roadmap is clear: the protocol needs a standardized way to recognize and trust agent identities, moving away from pasted API keys and long-lived tokens. A long-lived token is like a long-lasting key whose loss creates a broad blast radius; short-lived credentials expire quickly, rotate automatically, and become invalid rapidly if leaked. Zero Trust trusts no one by default, requiring verifiable proof of identity on every access rather than granting access simply for being on an internal network. Workload identity means the platform issues each program running on a machine a short-lived, auto-rotating digital ID that the program uses to prove who it is. Platforms like Kubernetes and SPIFFE and SPIRE already do this. Red Hat’s analysis on Zero Trust for AI agents points out that Zero Trust for agents differs from Zero Trust for humans: the challenge is propagating user identity unbroken from the browser to the agent, and then down to the services the agent calls. Under the principle of least privilege intersection, the agent can only narrow user permissions, never expand them.
First question: How does a program running on a cloud platform prove its identity to an MCP server? The platform already issues it a short-lived digital ID in the form of a JWT; the WIF mechanism allows the MCP server to directly validate this token without requiring the program to register a separate OAuth client. This corresponds to the WIF proposal PR 1933 (SEP-1933), opened on 2025-12-05 by Pieter Kasselman, co-chair of the IETF WIMSE Working Group, and currently in Draft status as of 2026-08-25. Responding to skepticism about “inventing wheels” on 2025-12-17, the author stated that there is nothing custom-built here—it is entirely RFC 7523 combined with OpenID Connect Discovery. The roadmap planned by maintainers includes conformance testing, a TypeScript SDK implementation (PR #2572), and extension reviews.
Second question: If a user is already logged into a corporate account and an application wants to access MCP tools on their behalf, what happens? The application uses the user’s SSO identity to request a dedicated token from the enterprise IdP, presenting it directly to the MCP server to exchange for access—without ever popping up a browser window asking the user for consent. This mechanism corresponds to the IETF draft draft-ietf-oauth-identity-assertion-authz-grant, updated to v4 on 2026-05-21, abbreviated as ID-JAG. The corresponding MCP Enterprise-Managed Authorization extension is noted by maintainers as stable, with documentation explicitly requiring that users not be redirected to authorization endpoints; the draft also prohibits reusing the same ID-JAG across downstream hops. The enterprise IdP evaluates policies prior to issuance, and permission revocation takes effect globally on the IdP side.
Third question: What if a token is stolen? The DPoP mechanism binds the token to a private key held by the caller; even if the token is intercepted, it cannot be used without the private key, and the server can simultaneously detect replay attacks. This mechanism was finalized as the RFC 9449 standard in 2023, and the MCP implementation proposal SEP-1932 is in conformance testing as of 2026-07-02.
These mechanisms build upon the 2026-07-28 specification baseline:
the protocol removed handshakes and session headers (SEP-2575 and
SEP-2567), introduced self-contained _meta, and completed
the stateless foundation and basic authorization hardening—detailed in
the changelog.
The foundation has shipped, while the upper-layer process identity
system remains under construction.
This shift is not free; MCP paid two prices.
The first price is a heavier protocol, forcing existing
implementations to adapt. Previously, the protocol relied on sessions to
maintain state: the server remembered who the client was and what it had
called before. After going stateless, the server retains no session
memory. Every request must be self-contained, packing the protocol
version, client identity, capability scope, and target tool name all at
once. Fields and validation rules in requests multiplied accordingly,
requiring existing MCP integrations to conform to the new rules. In
terms of technical details, the protocol eliminated handshakes and
session headers (SEP-2575 and SEP-2567), mandated
Mcp-Method and Mcp-Name headers in requests
(SEP-2243), added ttlMs and cacheScope fields
to listing responses (SEP-2549), introduced resultType to
response bodies, deprecated Dynamic Client Registration (DCR) in favor
of CIMD (PR #2858), and phased out HTTP+SSE transport (SEP-2596). MCP is
no longer a lightweight protocol where you call a tool and walk
away.
The second price is more direct: MCP dropped two recently added features. The first is Sampling, which let servers borrow the client’s model to do work: the server initiated sampling requests, the client’s model generated completions and called tools exposed by the server, with the server driving this loop round after round. This capability joined the spec in 2025-11 (SEP-1577); eight months later, the 2026-07-28 spec placed it on the deprecation list (SEP-2577) with at least a 12-month transition window. The second is Roots, which allowed clients to share local files and directories with the server, serving single-machine interactions for a human at a computer; Roots was also deprecated in this revision. Cutting them signals that MCP’s focus no longer encompasses scripting scenarios for solo developers.
Cutting these two capabilities defines the protocol’s boundaries. As we previously wrote regarding MCP 2026’s main theme of drawing boundaries at the protocol layer: MCP focuses on the tool and identity layers and refuses to take over agent runtime, leaving the reasoning loop to client frameworks. MCP took off on the zero-friction promise of writing a script and spinning up a server; now, to let cloud agents operate autonomously, every layer of enterprise identity added piles on the very complexity it once deliberately avoided. Meanwhile, OpenAI took the opposite path, as we previously analyzed comparing these two routes: OpenAI’s Responses API pulls reasoning state, conversation history, and hosted tools into its own backend, hosting the agent’s core loop directly on vendor cloud infrastructure. MCP bets on a neutral tool and identity substrate while staying out of the runtime business; OpenAI bets on owning the runtime along with it. These are two divergent technical paths betting at different layers.
That API key pasted into your project’s .env can be revoked, rate-limited, or inspected in call logs at any moment by its issuer. The issuer holds this power because every request carrying that key passes through their systems. This mandatory transit point is the choke point—a concept we previously analyzed in detail.
This shift moves the gateway into the hands of the token issuer. The authority issuing digital IDs now controls who can use them, how they are revoked, and oversees every delegation. In the ID-JAG flow, requests initiated by an application must first pass through the enterprise IdP for policy evaluation before gaining access. In the WIF flow, the MCP server trusts the identity issued by the cloud platform, directly validating the platform’s short-lived JWT. Public cloud platforms and enterprise IdPs are precisely the two entities solo script-writers never had to deal with. In deciding who approves, who revokes, and who sees delegation, the issuer undeniably occupies the gateway; that assessment holds completely.
How this evolution affects you depends on your position in the pipeline. If you build MCP servers: once your server leaves the local machine and deploys remotely, you need to hook into the published OAuth 2.1 authorization framework and issuer validation—something you can do today. When enterprise clients require using their own SSO, you can integrate the Enterprise-Managed Authorization extension, which maintainers describe as stable. WIF is still in Draft; hold off on writing validation code for it.
If you build agent applications and have agents call MCP tools: to run agents unattended, browser-based approval is a dead end. What works today are the machine-to-machine credentials introduced in the 2025-11-25 release, allowing agents to present credentials and exchange tokens on their own. ID-JAG is still an IETF draft; wait until it exits draft status before adopting it.
If you only use off-the-shelf agent products to call tools: no
changes are needed; the client handles it. Note, however, that this
architecture is phasing out the habit of pasting long-lived API keys
into .env files—stop doing that in new scripts. There is a
clear benchmark to judge whether this transition succeeds: if WIF and
DPoP remain stuck in draft status over the next two to three
specification cycles, and mainstream servers continue passing through
user credentials rather than workload identity, the thesis that the
default caller has shifted to cloud processes will have failed.
This pivot has stirred debate across the community. The discussion on the new roadmap on HN reached 269 points, with complaints of over-engineering taking center stage; one top-voted comment stated: “building a bespoke new protocol during the initial launch phase is among the dumber things MCP has done.” The REST + skills.md camp is even more blunt, with AWS Builder Center publishing under the headline: Agent skills and CLI tools: ditch the MCP overhead. Cloudflare’s code mode equips models with code execution tools, claiming to “bring full APIs to agents in under 1,000 tokens,” marked as experimental in its documentation. MCP bets on serving as a neutral tool and identity substrate for unattended production agents while leaving runtimes aside. Whether this bet pays off remains an open question.