MCP's New Roadmap Puts Agent Identity Ahead of Tool-Calling

What you need to know

• Five priority areas, published 22 August 2026. Agentic messaging primitives; HTTP-native transport unification and hardening; agent identity and enterprise-ready security; improved primitives for tool calling and result handling; and improved SDK developer experience.
• The security framing has shifted. The roadmap describes the problem as moving from "which user approved this server?" to "which workload or sub-agent is calling, for whom, and with what delegated authority?"
• Four named technologies carry that work: DPoP, the ID-JAG grant supporting Enterprise-Managed Authorization, Workload Identity Federation, and standard token exchange — positioned explicitly against long-lived API keys.
• Tasks is being promoted. The Tasks extension, SEP-2663, is targeted for maturing into the specification proper. A new Multi Round-Trip Requests pattern has replaced server-initiated requests.
• Polling is on the way out. Server-initiated events — webhooks and channels — are prioritised "so clients aren't left polling for results".
• The previous roadmap has largely shipped. March's four areas mostly landed in the 2026-07-28 specification release, which is why this reads as a fresh set rather than a progress report.

Roadmaps are usually the least interesting document a protocol produces. This one is worth twenty minutes because of what it demotes. Tool calling — the thing most people still think MCP is — appears fourth. Above it sits an entire priority area about proving which piece of software is on the other end of a connection.

From four priorities to five

The March 2026 roadmap set four areas: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. Most of that work landed in the 2026-07-28 specification release, which is the honest reason a new roadmap exists at all — the old one had been consumed. We covered the March edition in MCP's 2026 roadmap: server cards, SSO auth, real scale.

The mapping below is editorial rather than the roadmap's own; the two documents do not claim a one-to-one correspondence.

Theme	March 2026 roadmap	August 2026 roadmap
Transport	Transport evolution and scalability	HTTP-native transport unification and hardening
Agent-to-agent work	Agent communication	Agentic messaging primitives
Enterprise and security	Enterprise readiness	Agent identity and enterprise-ready security
Governance	Governance maturation	Not a standalone priority area; the Working Groups carry it
Core primitives	Not a standalone priority area	Improved primitives — tool calling and result handling
Developer experience	Not a standalone priority area	Improved SDK developer experience

Two things stand out. The transport wording tightened from "evolution and scalability" to "unification and hardening" — the language of a protocol that has stopped exploring and started consolidating. And developer experience earned its own line, which usually happens when a specification has grown faster than the SDKs implementing it.

The question has changed from "which user" to "which workload"

The roadmap's own framing of the security shift is the sentence worth quoting in your next architecture review. The problem has moved from "which user approved this server?" to "which workload or sub-agent is calling, for whom, and with what delegated authority?"

That is three separate demands. Which workload is an identity question — the caller is a process, not a person at a browser. For whom is a delegation question — the human whose authority is being exercised may have gone home hours ago. With what delegated authority is a scoping question — the sub-agent should hold less power than whatever handed it the job, and you should be able to demonstrate that.

An OAuth flow built around a consent screen answers exactly one of those, and only at the moment a human clicks. Everything after that click is inference. Tolerable when an agent is a chat window with three tools attached; not tolerable when a reconciliation agent in a Bengaluru GCC spawns four sub-agents overnight, each touching a system of record.

The identity toolkit, and what each piece is actually for

Four technologies carry the identity work. None are new inventions; the roadmap's contribution is choosing among existing standards and saying which combination MCP intends to lean on. It also references engagement with OAuth standards work through the IETF and the WIMSE working group — a useful signal that this is being built inside the standards process rather than beside it.

Technology	The problem it addresses	Status in the roadmap
DPoP — Demonstrating Proof of Possession	A bearer token is useful to anyone who holds it. DPoP binds a token to the client that legitimately possesses it, so interception alone is not enough.	Named as needing finalisation and broader adoption — the gating item, not a finished one.
ID-JAG grant	Enterprises need authorisation decisions made centrally rather than server by server.	Named as supporting Enterprise-Managed Authorization.
Workload Identity Federation	A workload needs an identity of its own, and a defined way to delegate a narrower slice of authority onward.	The roadmap says it establishes "an opinionated path for agent identity and delegation".
Standard token exchange	Each hop should swap its credential for a narrower one rather than passing its own along unchanged.	Named as a standard mechanism the identity work builds on.
Long-lived API keys	Nothing — this is the incumbent the roadmap positions the four above against.	Explicitly the thing being moved away from.

The word doing the most work there is "opinionated". Standards bodies usually publish options and let implementers argue; an opinionated path means the specification intends to say do it this way — inconvenient if you have already chosen differently, enormously helpful if you have not chosen at all.

That is the shape of the coming problem, and it is not hypothetical for regulated buyers. An NHS trust procuring an agent that touches patient records, a UK fintech under consumer duty obligations, an Indian GCC running processes for a parent company's regulated entity — all three will eventually ask for a delegation chain, not a list of API keys. Teams that already issue least-privilege credentials per hop will produce that chain from existing logs. Teams sharing one service account across an agent fleet will produce a spreadsheet and an apology.

Messaging primitives and the end of polling

The first priority area, agentic messaging primitives, is where the day-to-day engineering lands. Three items matter.

Tasks is being promoted out of extension status

The Tasks extension is tracked as SEP-2663, and the roadmap targets maturing it so it can move into the specification proper. Extensions are optional; specification primitives are not. When Tasks makes that jump, "accepts long-running work under an identifier you can poll and cancel" stops being something you build and becomes something you can assume of any compliant server.

Multi Round-Trip Requests replaced server-initiated requests

A design correction rather than a feature. A server that can initiate arbitrary requests back into a client inverts the trust relationship in a way that is hard to reason about and harder to audit. Framing the same need as a multi round-trip request keeps the client in control. If you built against the older server-initiated shape, read this item carefully.

Webhooks and channels, so clients are not left polling

The roadmap prioritises server-initiated events — webhooks and channels — so that clients are not left polling for results. Polling is the default because it is easy, and quietly expensive: a client checking every two seconds for a job that takes eleven minutes makes 330 requests to learn one fact. Multiply by a fleet and it becomes a line on an infrastructure bill.

Beyond SEP-2663, the roadmap references SEP-2575, SEP-2567, SEP-2549, SEP-2322 and SEP-2133. It was developed by the Core Maintainers together with the wider community of maintainers and Working Groups, with four groups named: Agents, Transports, Triggers & Events, and Server Card. If you want to influence this rather than receive it, those groups are the door.

Builder angle: five things worth doing this quarter

None of this forces a migration today. It does make one set of habits progressively more expensive, and the cost is deferred rather than avoided. Five things that are cheap now and awkward later, whether you build in Pune, Hyderabad, Bristol or London.

1. Inventory where your agents hold credentials. Not where they are stored — where they are held: environment variables, config files, a secrets manager, a hard-coded header in a script somebody runs manually. One row per credential, answering "who or what does this represent, and what can it reach". Most teams find at least one entry where they cannot answer the first half.
2. Stop minting long-lived keys for sub-agents. The highest-leverage change, because it is a policy decision rather than an engineering project. Existing keys can stay for now; new ones should be short-lived and scoped to the job, even if you expire them with a cron while you wait for token exchange to land in your SDK.
3. Make delegation legible in your logs today. You do not need a standard to record which agent invoked which sub-agent on whose behalf. A correlation identifier plus an originating principal at every hop gives you the audit artefact whatever the token format turns out to be. Retrofitting that into a year of history is not possible.
4. Track SEP-2663 and shape work as tasks now. If your server accepts long-running work under an identifier the caller can poll and cancel, you are structurally ready when Tasks moves into the specification. If it holds an HTTP connection open for eleven minutes, you are not — and the transport hardening work makes that pattern less viable regardless.
5. Design for inbound events, not outbound polls. Make results addressable by a stable identifier and make your result handler idempotent. Do both and swapping a polling loop for a webhook is an afternoon. Skip them and it is a refactor, because idempotency is what bites when an event arrives twice.

What the roadmap does not promise

Some honest limits, because it is easy to read a document like this as a delivery schedule.

There are no dates. Priority areas are ordering, not commitment, and the item the roadmap itself flags as needing finalisation and broader adoption — DPoP — is the one everything else leans on. Adoption of a token-binding mechanism needs identity providers, gateways and SDKs to move roughly together, and they historically do not.

The IETF and WIMSE work moves on its own schedule too. Engaging with a standards body is the right thing to do and also the slower thing to do. Expect a long middle period in which the direction is settled and the implementations are not — the same period the A2A and MCP governance consolidation is currently in.

And identity is necessary rather than sufficient. Knowing precisely which workload made a call, on whose authority, does not make the call correct. The 143,000 findings across 25,000 MCP servers were mostly not identity failures; they were ordinary software defects in servers written quickly. A perfect delegation chain to a vulnerable server is a well-documented incident.

Still, the ordering is right. A protocol that settles identity before it optimises tool schemas is being designed by people who have shipped into an enterprise and been asked awkward questions afterwards. If you are on an older revision, migrating to the stateless spec first remains the cheaper order of operations — and then the useful work is the unglamorous kind: write down who your agents are, and on whose authority they act.