The MCP roadmap published on 22 August makes a clear promise. Under the heading "Agent identity and enterprise-ready security," the lead maintainers write that they want MCP servers "to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens" [1]. They then name three mechanisms that will get there: Demonstrating Proof of Possession, Workload Identity Federation, and the ID-JAG grant behind Enterprise-Managed Authorization [1].
It is worth checking where each of those three actually stands, because the answer is lopsided in a way the roadmap does not dwell on. One of them has shipped. It is the one about people. The two that are about the agent itself have been open pull requests since December.
What the protocol does today
Start with the current specification, because the roadmap only makes sense against it.
In the 2026-07-28 spec, a protected MCP server is an OAuth 2.1 resource server, and a client makes requests "on behalf of a resource owner" [2]. The hygiene is genuinely good. Clients must name the exact server a token is for using resource indicators, servers must reject tokens issued for anyone else, and a server "MUST NOT accept or transit any other tokens" [2]. The release that made MCP stateless, covered here in July, also added issuer validation and replaced dynamic registration with fetchable client metadata documents.
Then look at how the token travels. The spec requires it in a header of exactly this form: Authorization: Bearer <access-token> [2].
A bearer token means precisely what the word says. Whoever bears it is the caller. The server has no way to tell the agent that was issued the token apart from anything else that obtained a copy of it: a log line, a crash dump, a prompt-injected tool that echoed its own environment. Audience binding limits where a stolen token works. It does nothing about who is holding it.
The spec also only has two shapes for a caller. A client acts on behalf of a user, or a client using client credentials acts on its own behalf [2]. There is no core construct for the sentence enterprises actually need to write down: this agent, running as this workload, acting for this person, within these limits.
That gap is what priority three is for. So what has arrived?
The piece that shipped is about the employee
Enterprise-Managed Authorization went Stable on 18 June [3]. It solves a real and expensive problem: every MCP server asking every employee to click through its own consent screen.
With it, an administrator approves an MCP server once in the company identity provider. The client picks up an Identity Assertion JWT Authorization Grant from that provider during single sign-on, and trades it for an access token at the server's authorization server, with no per-server consent flow [3]. The adoption list at launch was strong: Okta as the identity provider; Claude, Claude Code, Cowork and VS Code as clients; Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase as servers, with Slack adding support [3].
This is a real win, and it deserves the attention it got. But read the flow again. It begins with a person signing in. The grant exists to carry that person's corporate identity to a new service without asking them twice [6]. It answers "which employee is this?" extremely well.
It does not answer "which agent is this?" at all, and it was not designed to.
There is a smaller point worth knowing too. The extension is Stable in MCP's terms, but the grant it rests on is still an IETF Internet-Draft. The current revision is version 04, dated 21 May 2026, from authors at Okta and Ping Identity, and it has no RFC number yet [6]. That is normal for OAuth work, and it is also a reason not to describe any of this as settled.
The two pieces about the agent are still drafts
DPoP is SEP-1932. It applies RFC 9449 to MCP so that a token is bound to a key pair the client holds, and every request carries a signed proof that the client still possesses the private key [4]. A copied token without the key becomes useless. That is the direct fix for the bearer problem above. The proposal makes DPoP optional for both sides, with servers able to require it through their protected resource metadata, and it offers three replay defences depending on how stateful a server is: tracking proof IDs, a time window of roughly five minutes, or server-supplied nonces [4].
Its open review points are not cosmetic. Reviewers have flagged drift between the proposal and the separate extension draft, missing detail on how the token endpoint binds tokens and refresh tokens to the key, unclear guidance for servers that must accept both DPoP and plain bearer tokens during a migration, and underspecified client behaviour when a server demands a fresh nonce [4].
Workload Identity Federation is SEP-1933. It lets an agent running in Kubernetes, SPIFFE or a similar platform present the short-lived, signed identity token that platform already issues, and exchange it for an MCP access token using RFC 7523 and OpenID Connect Discovery [5]. No pasted API keys, no separate credential lifecycle to manage. In the proposal's own framing, the point is to let MCP use credentials the platform already issues and remove the separate client identity lifecycle entirely [5].
On 28 April it moved from In Review back to Draft [5]. Reviewers have also asked whether tracking token IDs for replay protection should be mandatory, since the underlying RFC treats it as optional [5].
Both proposals were opened on 5 December 2025, by the same author [4] [5]. Both are still open more than nine months later.
To be fair to them, neither is abandoned. Both pull requests were updated within the last week, and SEP-1933 has conformance tests and SDK implementations in progress [5]. They are moving. They have not arrived.
Even when they land, the hardest sentence is still unwritten
Here is the part that matters most for anyone planning around this roadmap.
Suppose both proposals merge tomorrow. DPoP would prove the caller holds a key. Workload Identity Federation would prove the caller is a particular workload on a particular platform. SEP-1933 is explicit that it authenticates the calling platform and does not build user-level delegation chains [5].
Neither one expresses "this agent is acting for Maria, and only for the next hour, and only on her calendar." That delegation sentence belongs to the third item in the roadmap's list, "standard token exchange" [1], the RFC 8693 mechanism OAuth uses to represent one party acting on behalf of another. Of everything priority three names, it is the item with the least concrete MCP specification behind it today.
So the sequence is: human identity shipped, workload identity and key binding are in draft, and delegation between the two is the furthest out. That is a sensible build order. Delegation depends on having trustworthy identities on both ends first. It is also the reverse of the order in which most readers will assume the problems were solved.
The obvious pushback
The strongest objection is that this is exactly how standards work should go, and the maintainers are doing it right. The roadmap explicitly says it wants identity "built on existing standards" [1], and building on IETF drafts rather than inventing an MCP-specific scheme is the disciplined choice. Nine months is quick for anything touching OAuth. And Enterprise-Managed Authorization fixed the problem companies were actually complaining about first.
All of that is correct, and none of it is a criticism of the maintainers.
The risk is in how the news combines. A team that reads the June launch and then reads a roadmap headline promising agent identity can reasonably conclude that agent identity is handled. It is not. The mechanism that shipped identifies the human. The agent is still identified by whatever holds the bearer token.
What to do while you wait
Treat every MCP access token as a bearer credential, because it is one. Keep lifetimes short, never write tokens to logs, and never allow a tool or model to echo its own environment or headers back into a conversation.
If you run Enterprise-Managed Authorization, know which question it answers. It tells you which employee authorized access. If you need to know which agent made a call, record that yourself at your gateway, because the token will not tell you.
Stop pasting long-lived API keys into autonomous agents now. You do not need SEP-1933 merged to start using your platform's short-lived workload tokens at your own gateway. The proposal standardizes a pattern that already works.
Prepare for DPoP before it is required. Key generation, storage and rotation for every client is the slow part, and a server can switch to requiring it through metadata once the profile lands [4]. Teams that have keys ready will flip a setting. Teams that do not will face a migration.
Watch SEP-1932 and SEP-1933 directly. Roadmaps describe intent. Pull requests describe progress, and these two are the honest signal for when agent identity in MCP becomes real.
The roadmap chose the right words for priority three. It just described a destination, and at the moment, the only part of that destination you can actually use is the part that was built for people.
References
[1] David Soria Parra and Den Delimarsky, MCP Lead Maintainers — The New MCP Roadmap. Blog
[2] Model Context Protocol — MCP Specification 2026-07-28: Authorization. Documentation
[3] Paul Carleton, MCP Core Maintainer — Enterprise-Managed Authorization: Zero-touch OAuth for MCP. Blog
[4] PieterKas (author), D-McAdams (sponsor) — SEP-1932: DPoP Profile for MCP. Documentation
[5] PieterKas (author), D-McAdams (sponsor) — SEP-1933: Workload Identity Federation. Documentation
[6] Aaron Parecki, Karl McGuinness, Brian Campbell, IETF OAuth WG — Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant-04). Documentation