The [Model Context Protocol roadmap](https://modelcontextprotocol.io/development/roadmap) was last updated on 22 August 2026 and names five priority areas for the next specification release. Payments is not one of them. The closest the document comes is priority area three, Agent Identity and Enterprise-Ready Security, and that work is about proving which agent is calling and under whose authority. Identity answers who. It never answers how much.
If you're building agents that buy things on MCP, that gap is your problem to solve, and the roadmap is unusually clear about why.
What's actually on the roadmap?
Five priority areas for the next specification release, and none of them is payments. They are agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and SDK developer experience. Here is what each one commits to for this period.
| Priority area | This period's deliverables |
|---|---|
| Agentic Messaging Primitives | Server-initiated events including webhooks; a composition review across the Agents, Transports and Triggers & Events working groups. Continued work on Tasks (SEP-2663). |
| HTTP-Native Transport Unification and Hardening | Streamable HTTP over stdio using HTTP/2 as a single transport binding; caching extended to ETags, building on ttlMs and cacheScope from SEP-2549. |
| Agent Identity and Enterprise-Ready Security | Finalise DPoP; agent identity and delegation via Workload Identity Federation (SEP-1933), the ID-JAG grant used by Enterprise-Managed Authorization, and RFC 8693 token exchange. |
| Improved Primitives | Redesign the tools/call return shape; progressive discovery so clients learn a server's tools as needed; a decision on primitive annotations (SEP-2200). |
| Improved SDK Developer Experience | Define the extension contract; generate a candidate Tier 1 SDK from the specification and validate it against the conformance suite. |
Search that page for "payment", "billing", "price" or "invoice" and you get nothing.
The maintainers didn't overlook it. They scoped it out, and the reasoning is worth reading in their own words.
Why does the roadmap treat identity as the urgent problem?
Because the assumption underneath MCP authorization broke. The roadmap states it plainly: "MCP authorization assumes a person with a browser at consent time." Agents now call these servers with nobody sitting in front of them, so the consent step the whole model was built around is missing exactly when it is needed.
That assumption held when a developer clicked through an OAuth screen and the agent inherited the resulting token. It stops holding when the caller is a cloud workload with its own identity, acting for a user who isn't at a keyboard, spawning sub-agents that should carry narrower authority than their parent. The roadmap is candid about where that leaves most deployments today: "Existing MCP servers lean on pasted API keys and long-lived refresh tokens."
DPoP fixes part of that by binding a token to a key the caller has to prove it holds, so a stolen bearer token stops being enough. Workload Identity Federation removes the pasted key. RFC 8693 token exchange gives a parent agent a way to hand a sub-agent something weaker than what it holds itself.
All three are the right work, and the Agent Identity working group was still forming when the August 2026 roadmap went out, so none of it is finished.
Why isn't a valid token a spending control?
Because an agent holding a perfectly correct credential can still buy the wrong thing. Authentication settles which agent is calling and which class of operation it may perform. Nothing in that check knows what a purchase costs, which merchant is on the other end, or whether anyone budgeted for it.
Picture a research agent with a DPoP-bound token, a properly federated workload identity, and a scope that says it may call the procurement MCP server. Every one of those checks passes. The agent then reads a poisoned document, decides it needs a $4,000 annual licence from a vendor nobody at your company has heard of, and calls the tool it's entitled to call. Nothing in the authorization layer was wrong. The token did exactly what it was issued to do.
That's the shape of the failure. Identity systems answer whether the caller is who it claims to be and whether it holds the scope for this class of operation. The amount, the merchant, the time window and the approval threshold are business facts that live in your finance function, change when your budget changes, and have to be evaluated against a specific transaction rather than a class of them. The [hallucinated-purchase write-up](/blog/ai-agent-hallucinated-purchases) walks through how a valid credential turns into a purchase you didn't want.
| The question | Where MCP answers it | Where it gets answered otherwise |
|---|---|---|
| Which agent is calling? | DPoP, Workload Identity Federation (SEP-1933) | your IdP |
| On whose behalf? | ID-JAG, RFC 8693 token exchange | your IdP |
| May it call this tool? | OAuth scopes | your MCP server |
| May it spend $4,000 at this merchant, right now? | nowhere on the roadmap | the payment rail |
| What did it buy, and can you prove it? | nowhere on the roadmap | the payment rail |
Where does the money question get answered?
At the rail, and August 2026 was a busy month for it. AWS made [AgentCore payments generally available](https://aws.amazon.com/about-aws/whats-new/2026/08/bedrock-agentcore-payments-ga/) on 18 August, enforcing configurable payment limits at the infrastructure layer for agents running in Bedrock AgentCore. Rain launched the Agentic Payments Alliance the same day with 26 founding members including Visa and Mastercard, naming agent identity and authorization as its early work. Both are answers to a question the protocol layer is not asking.
Shatale issues agent-scoped virtual cards and evaluates your policy at the authorization moment, while the merchant is still waiting for a decision. A purchase outside policy is blocked or escalated to a person for approval, and every decision is written to an immutable per-agent record. None of that depends on which identity standard your MCP servers settle on, which is the point: the two layers compose because they answer different questions.
If you're on the other side of this, charging agents rather than paying them, the pricing mechanics are in [how to price MCP tools](/blog/how-to-price-mcp-tools).
What to ask
- If our agent's token is valid and its scopes are correct, what stops a purchase we didn't intend?
- Where does our spending policy live, and can finance change it without an engineering deploy?
- At what moment in the transaction is that policy evaluated?
- Does a blocked purchase reach a person, or does it fail silently?
- Is the record of what each agent bought immutable and scoped per agent?
FAQ
Does the Model Context Protocol support payments?
No. The MCP roadmap last updated 22 August 2026 lists five priority areas: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise-ready security, improved primitives, and SDK developer experience. Payments, billing and monetization appear in none of them.
What is MCP doing about agent identity?
Priority area three covers it. The deliverables for this roadmap period are finalising DPoP for proof-of-possession tokens, and agent identity and delegation through Workload Identity Federation (SEP-1933), the ID-JAG authorization grant, and RFC 8693 token exchange, coordinated with the IETF OAuth and WIMSE working groups.
Is agent identity the same as agent authorization?
They answer different questions. Identity establishes which agent is calling and on whose behalf. Payment authorization decides whether one specific transaction, at one specific merchant, for one specific amount, is permitted right now.
Can I control agent spending through OAuth scopes?
Scopes decide which operations an agent may perform, so they can gate access to a purchasing tool. They carry no amount, no merchant and no time window, so they can't distinguish a $12 purchase from a $12,000 one through the same tool.
---
The [Agentic Payments Alliance piece](/blog/agentic-payments-alliance-standards) covers the other half of August 2026, where the money question is being argued. Early access is free for publishers.
Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).