MCP's hardest problem: proving which agent asked for what

The Model Context Protocol — the open standard that lets AI assistants plug into tools and data sources, the plumbing under nearly every agent you've met — published a fresh roadmap on Friday. Across its five priority areas, one stands out less for its novelty than for how long it has been quietly dodged: agent identity. Today MCP can tell you which person handed a tool to a model. It cannot yet tell you which agent is on the other end, what it is allowed to touch, or whether the model carrying the credential is the one that earned it. That gap is what the maintainers are finally taking on directly — and it is the difference between AI agents staying a developer's toy and becoming infrastructure your company lets loose on production systems.

The roadmap, briefly

The update, published by lead maintainers David Soria Parra and Den Delimarsky, organizes the next specification release (and beyond) into five working priorities: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise security, improved primitives, and SDK developer experience. Each area is owned by named core maintainers and one or more working groups, and — tellingly — proposals that fall inside these areas get expedited review, while everything else waits in line. That prioritization is itself a quiet statement about where the scarce resource sits: not in ideas, but in the attention to review them.

Walking through the list, the threads that matured off the previous roadmap's "on the horizon" shelf into full priorities are exactly the ones the chat-era design never handled. Agentic messaging means servers that can push events and run long tasks rather than answer one request and stop. Transport unification means consolidating on a single Streamable HTTP mode even for local servers, so your MCP stack behaves like the ordinary HTTP API you already run. Improved primitives means a single unambiguous contract for tool results, plus a "progressive discovery" effort so a server with a hundred tools doesn't make the model pay for the full catalog before it has asked a single question. And SDK developer experience acknowledges that a growing share of MCP clients and servers are now written by pointing a coding agent at the libraries — so clear APIs have become load-bearing, not cosmetic.

If you want the large picture first, we explained what MCP is and why it exists in AI 101 — What is MCP?. Today's update does not change the basics; it changes what the protocol reaches for.

The centerpiece: who is the agent?

The identity work is the part with real stakes. Today, MCP's authorization assumes a human in a browser approving access — an interactive flow where a fingerprint, an SSO prompt, or a token exchange ends with a person clicking yes. That model breaks the moment the caller is not a person at all. Increasingly, the clients calling MCP servers are cloud workloads running on behalf of a user who is not present, or delegating narrower authority down to sub-agents. A pasted API key or a long-lived static token is a fragile stand-in for "this specific agent, this specific scope, for this specific job" — and it is what enterprises are refusing to bless.

The roadmap's answer is to build on existing authentication standards rather than invent new ones. That includes Demonstrable Proof of Possession (DPoP, RFC 9449), which binds an access token to a cryptographic key held by the client, so a stolen token is worthless on its own; Workload Identity Federation (SEP-1933), a path for servers to trust an identity minted by an agent's own runtime; and an enterprise-managed authorization mechanism that issues scoped, short-lived authority and supports standard token exchange for delegation to sub-agents. The maintainers also say they are coordinating with the IETF's OAuth and WIMSE working groups to make sure the underlying standards evolve with agent needs. The throughline is deliberate: a credential that dies without its holder, is scoped by default, and can be handed down a delegation chain with the boundaries intact.

This connects to a live issue we've covered before: trust on the internet increasingly runs on whether software can prove what it is, and agents are discovering the same wall web agents hit when they get fingerprinted. MCP is trying to build the identity layer so that being an agent is something you prove, not something you hide.

Why it matters, and who feels it

For enterprises, agent identity is the gate between a pilot and production. No serious organization is going to let a headless model reach customer records, billing systems, or code hosts on a long-lived credential attached to nobody. The companies that solve "which agent asked for this, and is it allowed to" are the ones that let agent fleets actually touch money and data. So the winners here are the enterprises that get a paved, standard path to scope agent access, along with platform and identity vendors whose products slot into a protocol they no longer have to invent. The losers are two kinds of operations: teams still living on pasted API keys and long-lived tokens, and startups whose entire value proposition was a proprietary gateway that made agent auth work — because the thing they were selling is exactly what is being standardized away.

There is also a quiet economic argument hidden in "progressive discovery." A server exposing a hundred tools forces the model to ingest the whole surface on every call, which costs tokens and degrades tool selection as the list grows. Narrowing the catalog as the conversation narrows isn't just ergonomics; it is a direct cut to inference spend — a real reason the maintainers call it out.

What the skeptics will say

Roadmaps are plans, and the MCP project is careful to label them non-binding: "The ideas presented here are not commitments. Some items may not materialize at all." Worth holding in mind, because the agent identity problem is genuinely hard, and the protocol is not the only actor. Agent delegation is a known trap — the classic "confused deputy" where a sub-agent inherits more authority than it should because its parent was over-privileged. Even mature identity standards struggle to model chains of authority cleanly, and MCP is working alongside, not ahead of, that debate. There is also a plausible fragmentation risk: if each major cloud implements workload identity a little differently, "one protocol for agent identity" could quietly split into several. And the practical test is unforgiving — a protocol is only as protective as the clients that implement it. The Hacker News thread on the announcement was still thin hours after posting, which is its own signal: the people this matters to most are the ones who've already hit the identity wall in their own stack, and they will judge this by what ships, not what's planned.

What to watch

Two concrete markers: whether the Tasks extension clears into the next formal specification release; and — more importantly — whether major MCP clients adopt DPoP and workload identity the day they're available. The second is the real tell, because collaboration is alphabetical in a spec catalog but binding only in implementation. Beyond that, watch the IETF's WIMSE working group, since MCP's answer is only as good as the underlying standards keep up, and keep an eye on whether progressive discovery actually changes how teams think about exposing tool catalogs — and whether the servers that get "found" first start to look suspiciously like the ones that were best at being visible.

For the distinction that gets this whole conversation started, see AI 101 — What is an AI agent? — because once software acts on its own behalf, "who were you acting for, and with what permission" stops being a theoretical question.

Should a stolen agent credential be worthless by design, or is that the operator's problem? Tell us in the comments.

Sources: Model Context Protocol Blog · MCP Roadmap — official docs · RFC 9449 — Demonstrable Proof of Possession · MCP Tasks extension · Hacker News discussion