The Agent Protocol Stack in 2026: What MCP, A2A, and ACP Each Solve

TL;DR

MCP, A2A, and ACP sit at different layers, and none of them can say who authorized an action or how to take that authority back. A gap analysis that scores five agent protocols against a six-dimension governance taxonomy puts every one of them at 2 out of 12 or worse, with voting, dissent preservation, and human escalation absent from all five.

The adoption numbers people cite to settle this argument measure something else entirely. Hundreds of millions of monthly MCP downloads and 150-plus organizations behind A2A say people are installing these protocols, not that the protocols can express delegation, constraint, or revocation.

This isn't a claim that MCP or A2A are broken, or that they should have shipped a governance layer of their own. It's a scoping decision the maintainers made on purpose, which is why the gap doesn't close on its own.

Practically: MCP is settled enough to just build on. A2A earns its cost once agents cross an organizational boundary, not before. We'd treat ACP, AP2, and x402, still Beta, still a testnet registry, still disputed adoption figures, as worth watching rather than building against, unless an agent already needs to move money.

Overview

The agent protocol conversation still gets framed as a competition: MCP versus A2A, open standards versus vendor lock-in, pick a winner. That framing has been wrong for about eighteen months. The three protocols that matter sit at genuinely different layers, and they compose more cleanly than the discourse suggests.

The reason isn't obscure once you look at what each protocol actually transports. This agent is acting for that human, under these constraints, and this authority can be withdrawn is a sentence none of them has a wire format for. They can carry a governance decision as an opaque payload; none can interpret it, validate it, or enforce it. A systematic gap analysis in the literature now says so with numbers, which is the closest thing this argument has to independent confirmation.

Two existing posts here cover adjacent ground and should not be confused with this one. Multiagent Patterns and From Centralized AI to Decentralized Agentic Ecosystems are about architecture: how to arrange agents so the system works. This post is about the wire protocols and their governance semantics: what the specifications actually require, what they explicitly decline to specify, and where authorization context is destroyed as a request crosses from one protocol to another.

Three Layers

The layering is cleaner than it looks from the outside, because each protocol answers a different question.

MCP answers "what can this agent reach, and how." It is a client-server protocol between a host application and a tool provider. Its primitives are tools, resources, and prompts. The 2026-07-28 revision made it a stateless HTTP protocol: no handshake, no session id, every request self-describing, any request routable to any server instance. Governance moved to a Linux Foundation directed fund, the Agentic AI Foundation (co-founded by Anthropic, Block, and OpenAI in December 2025), with maintainers retaining technical autonomy. The specification is now genuinely mature: the release announcement cites close to 500 million monthly downloads across Tier 1 SDKs, with the TypeScript and Python SDKs each past a billion cumulative.

A2A answers "how do two agents that do not share a codebase collaborate." It reached v1.0.0 under Linux Foundation stewardship on 2026-03-12, with v1.0.1 following on 2026-05-28, and the project reported more than 150 supporting organisations at its one-year mark in April 2026, up from roughly 50 a year earlier, with AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow named and five production SDKs. Its primitives are the Agent Card, the task, and the message. Its design principle is deliberate opacity: agents collaborate "without needing to share their internal thoughts, plans, or tool implementations." That principle is the source of both its usefulness and its governance problem.

ACP and its neighbours answer "how does value move when an agent transacts." The Agentic Commerce Protocol, maintained by OpenAI and Stripe and still marked Beta, defines an agentic checkout, a product feed, delegated authentication over OAuth 2.0, and a delegated payment primitive, the Delegate Payment API, which mints a narrowly scoped token the agent hands to the merchant for the merchant to charge through any compatible processor. Its versions are date-stamped; the 2026-04-17 release added cart, feed, orders, authentication, and MCP integration. Alongside it sit AP2 (Google, 60+ launch partners in September 2025; its mandates, now a Checkout Mandate and a Payment Mandate rather than the launch vocabulary of Intent and Cart, are signed and carried as verifiable digital credentials), x402 (originated at Coinbase, now an x402 Foundation project under the Linux Foundation; HTTP 402 stablecoin settlement, with Coinbase's own reporting claiming roughly 165 million agent transactions and independent measurement disputing most of it), and on-chain identity work in ERC-8004, whose January 2026 spec update put the reference registries on Ethereum Sepolia testnet. The ERC itself is still Draft.

Not all three deserve the same attention this year. MCP is the one to just build on: it's stable, it has the most rigorous authorization model of the three, and an agent with no tools isn't much of an agent, so skipping it was never really an option. A2A earns its cost once agents live in different organizations and need to collaborate without sharing a codebase; inside a single org it is usually solving a problem an internal API already solved. We'd put ACP, AP2, and x402 in a different bucket: Beta status, a registry that lives on a testnet, and adoption figures that independent measurement doesn't support. They also answer a question, how value moves when an agent rather than a person initiates the transaction, that most teams building agents this year haven't been asked yet. Track that layer. Building against it early buys you very little.

peer agent (other org) -- MCP --> tool server |-- MCP --> tool server |-- ACP / AP2 / x402 --> merchant / payment rail '-- (dotted) NOT SPECIFIED ANYWHERE: delegated authority provenance, constraint expression, revocation semantics, approval as a protocol state, shared audit format -->

Figure 1 — The layered stack. Everything above the dotted line is standardised. Everything below it is left to each implementation.

What Each Actually Specifies

The specifications are more precise about their own boundaries than the marketing is, and reading them side by side is clarifying.

Three entries in that table deserve more than a row.

MCP's authorization model is the most rigorous of the three, and it is deliberately about one hop. The server must validate that a token was issued for it specifically, and if it calls an upstream API it MUST NOT forward the token it received. That is correct security engineering. It prevents confused-deputy abuse and keeps audit trails honest on both sides. It also means that by design, the identity that reaches the second hop is the MCP server's, not the user's. MCP does not carry a delegation chain because MCP is not trying to.

A2A's non-specifications are stated outright. It defines the interaction framework: operations, data model, bindings, an eight-state task lifecycle. Security, capability negotiation, and business logic are left to each agent. There is an AUTH_REQUIRED task state, but read carefully: that is a callee telling a caller "authenticate to proceed." It is not a mechanism for expressing that the caller holds delegated authority from a human, nor for the callee to verify such a claim.

ACP is the layer where delegated authority is closest to being real, because payments forced the issue. A delegated payment token is narrowly scoped by construction. Stripe's Shared Payment Token is the first processor implementation of the primitive, and the scoping is the point of it. AP2 goes further than any other protocol in the stack: every agent operates under a mandate, a Checkout Mandate and a Payment Mandate, each with an open stage carrying the user's constraints and a closed stage bound to one finalised transaction. Both are signed and carried as verifiable digital credentials specifying spending limits, allowed instruments, and validity periods. That's delegated authority with provenance, constraints, and an expiry, and it exists because nobody was willing to let an agent spend money without it. We'd ask why the same bar doesn't apply to an agent deleting records.

Composition and Overlap

Where these protocols genuinely compose, they compose well. An agent uses A2A to hand a task to a specialist agent at another organisation; that agent uses MCP to reach its own tools; if the task ends in a purchase, ACP negotiates the cart, AP2 proves the human authorised it, and x402 or a card rail settles. Nothing about that chain is contrived, and the ACP 2026-04-17 release explicitly added MCP integration, which is a maintainer acknowledging the same picture.

The duplication is real too, and mostly harmless.

Task lifecycles exist twice. A2A has had tasks with eight states since v1.0. MCP graduated Tasks into an official extension (io.modelcontextprotocol/tasks) in the 2026-07-28 revision, with five states and a poll-driven tasks/get / tasks/update / tasks/cancel loop. They are not interchangeable: A2A tasks are units of delegated work between peers, MCP tasks are long-running tool invocations. A system using both still maintains two task state machines and two sets of terminal-state semantics, and anyone building a unified operations view will feel it.

Discovery exists three times, with three trust models. MCP has a registry that verifies namespace ownership and, by its own documentation, delegates code scanning to npm and PyPI. A2A has Agent Cards fetched from a well-known path, optionally signed, with no registry requirement at all. ERC-8004 puts identity, reputation, and validation registries on-chain. These answer different questions: "where is this server," "what can this agent do," "has this agent behaved." None of them answers "should this agent be allowed to participate here," which is the question an enterprise actually asks.

Extension mechanisms exist everywhere and are barely used for governance. MCP formalised extensions with reverse-DNS identifiers, delegated maintainer repos, and independent versioning. A2A has declared extensions on the Agent Card, with a required flag and an A2A-Extensions request header, since before the protocol's v1.0.0 release. ACP added an extension mechanism in January 2026. The capacity is there. What has been built on it is UI rendering, long-running work, payment mandates, and enterprise SSO. Not governance.

What None of Them Can Express

The most rigorous treatment of this is a preprint posted on 2026-06-30 by Richard Kang and Yudho Diponegoro, Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express (arXiv:2606.31498). It has no venue yet, so read it as an argument rather than a settled result. It is a systematic gap analysis rather than commentary, though, and worth engaging with on its own terms.

The authors derive a six-dimension governance taxonomy from organisational theory, multi-agent systems literature, and enterprise governance standards: membership (who is admitted), deliberation (structured exchange of reasoning), voting (preference aggregation), dissent preservation (recording disagreement), human escalation (routing a decision to a person with authority), and audit/replay. They then read five specifications against it, classifying each capability as Supported, Partial, or Absent, and score coverage out of twelve.

Voting, dissent preservation, and human escalation are absent from all five. Nothing scores above 2 out of 12. The paper's conclusion is the part that matters. Governance messages travel fine and land meaningless: current protocols "can transport these messages as opaque payloads (e.g., via A2A task messages or MCP tool calls), but cannot interpret, validate, or enforce their governance semantics," and agent community governance therefore "constitutes a missing architectural layer above current interoperability standards, not a missing feature within them."

The paper's most damning individual finding is not about a specification at all. A2A's extension framework explicitly supports governance primitives, and in more than six months of availability, zero governance extensions have been proposed. The mechanism is not the constraint. Attention is.

Two things should be said in the specifications' defence, and one against.

In their defence: the paper analysed MCP v1.1 (schema 2025-11-25, protocol 2025-06-18), which predates the current revision. And its taxonomy comes from organisational governance, which asks about deliberation and voting among peer agents. Most enterprises are not running agent parliaments, so absent voting is not obviously a defect for a protocol connecting an agent to an ERP.

Against: re-reading the 2026-07-28 revision against the same taxonomy barely moves the needle, and it moves it in exactly one place. The new revision reserves three _meta keys (traceparent, tracestate, baggage) and pins their values to the W3C Trace Context and Baggage formats when they are present. Propagation is opt-in rather than required, which makes this a modest strengthening of the audit dimension, and it's enough to justify keeping MCP's Partial rating rather than upgrading it. Nothing was added for membership, deliberation, voting, dissent, or governance-scoped escalation. MCP's own 2026 roadmap says the quiet part plainly: it expects "most of the enterprise readiness work," which it defines as "audit trails, SSO-integrated auth, gateway behavior, and configuration portability," "to land as extensions rather than core spec changes." That's a defensible scoping decision for a protocol. It's also a decision that the enterprise governance layer is somebody else's problem.

The four gaps that matter most in practice are narrower than the paper's six, and each traces to a specific specification choice:

• No delegated authority provenance. MCP forbids token passthrough, so the identity at hop two is the server's. A2A defers authorization entirely and has no field asserting "I hold authority delegated from user X." RFC 8693 has modelled exactly this since 2020: an exchanged token carrying the user as sub, the acting party as a nested act claim, and may_act gating who may act for whom. No agent protocol requires it.
• No constraint expression. Nothing in MCP or A2A lets a caller attach "read-only," "EU data only," or "under €5,000" to a request in a way the callee must honour. AP2's mandates are the exception, and they only cover payments.
• No revocation semantics. None of the three defines a message that withdraws previously granted authority. Revocation happens out of band, at the identity provider, on a different timeline than the agents are operating on.
• No approval as a protocol state. MCP has elicitation, delivered inline via multi-round-trip requests, and Tasks has an input_required status. A2A has TASK_STATE_INPUT_REQUIRED. All three express "I need input to continue." None expresses "this action must not proceed without approval from a principal holding authority Y." That's the difference between asking and requiring.

Where Authority Dies Between Hops

The abstraction becomes concrete when you trace one action end to end. A treasury analyst asks an internal finance agent to settle a disputed supplier invoice. The finance agent delegates the reconciliation to a specialist agent operated by the company's outsourced accounting provider over A2A. That agent calls its own MCP server, which holds a connection to the shared ledger and writes an adjustment.

Finance agent (Org A) [has user identity + scopes] --> A2A task --> Recon agent (Org B) X user identity not carried; no constraint; no approval requirement --> MCP tools/call --> MCP server (Org B) X token audience = server; principal = Org B service --> Ledger write Ledger log attributes the write to Org B's service account. No hop records that a named human asked for it. -->

Figure 2 — A single action across two protocols. Authorization context is lost at both boundaries, for different and individually defensible reasons.

Neither loss is a bug. A2A does not carry the user because it defines no authorization model to carry it in. MCP does not carry the user because forwarding the analyst's token to a third-party server would be exactly the token-passthrough anti-pattern the specification forbids. Both decisions are locally correct. The composition is what fails: by the time the write reaches the ledger, the only recorded principal is a service account belonging to a different company, and the ledger's audit trail cannot answer "who asked for this."

The mechanism to fix it has existed for years, and the contrast is worth drawing precisely.

Figure 3 — The delegation chain that OAuth can already express, next to what the agent protocols carry.

What to Build Instead of Waiting

If governance is a missing layer rather than a missing feature, the practical consequence is that it has to be built above the protocols, and it will be non-standard for a while yet.

Carry the principal yourself, and make it a hop invariant. Every cross-agent and cross-tool call should carry both the acting agent's identity and the originating human's identity, with a correlation identifier that survives every boundary. MCP's reserved Trace Context keys give you a standard place to put the correlation identifier on the tool hop, but propagating it is opt-in, so you still have to require it; A2A gives you not even the field, so put it in the message metadata and enforce it at your own gateway. The test is simple: pick any write in a system of record and see whether you can name the human within one query.

Enforce constraints at a chokepoint, because the protocol will not. Since neither MCP nor A2A can express "read-only" or "under this threshold" as a wire-level obligation, the enforcement has to live somewhere both hops pass through. Default-deny at that point, with the effective permission set computed as the intersection of what the agent is allowed and what the user is allowed, is the only arrangement that fails safe when a delegated hop forgets to narrow anything.

Treat approval as your own protocol state. Until a specification defines "requires approval by a principal holding authority Y," that state has to exist in your control plane, and the agent has to be unable to route around it. Elicitation and input_required are not substitutes, because both are the callee asking politely rather than the system requiring.

This is the layer Agentic Fabriq operates at: two identities carried on every request, the agent's and the user's; default-deny role-based access from organisation to team to member; an effective tool list computed as the intersection of user and agent scopes; action-level permissions enforced in the backend rather than described in a tool definition; credentials held in a vault and injected into the outbound call; and an audit trail that records who asked as well as what ran. None of that is standardised, which is precisely the point: the protocols made a scoping decision, and something has to sit above them until they revisit it.

Conclusion

The layering works, and we think that's the part worth saying plainly instead of relitigating. MCP is a mature, well-specified agent-to-tool protocol with the most rigorous authorization model of the three and a formal deprecation policy behind it: build on it now. A2A is a stable agent-to-agent protocol with real multi-vendor adoption and an extension mechanism that could carry almost anything: adopt it once agents actually need to cross an organizational boundary. ACP and its payment neighbours are the youngest and, in one specific respect, the most advanced: AP2's signed mandates are the only place in the entire stack where delegated authority is expressed with provenance, constraints, and an expiry. They're also solving a problem most teams don't have yet, which is reason enough to watch them rather than build against them before you do.

What none of them expresses is the thing enterprises actually need: a durable statement of who authorised what, under which limits, and how that authority is withdrawn. The gap analysis puts every protocol at 2 out of 12 or worse against a six-dimension governance taxonomy, and finds voting, dissent preservation, and human escalation absent everywhere. The 2026-07-28 MCP revision improves audit propagation slightly and changes nothing else on that scorecard, and MCP's own roadmap places audit trails outside the core specification by design.

The most useful correction to make is to stop reading protocol maturity as governance maturity. A stable, widely adopted, rigorously specified protocol can still be silent about authority, and MCP, A2A, and ACP are, individually and together, exactly that.

Sources

• Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express — arXiv:2606.31498 (Kang & Diponegoro, June 2026)
• The 2026-07-28 Specification — Model Context Protocol Blog
• MCP Specification 2026-07-28 — Authorization
• MCP Specification 2026-07-28 — Authorization Security Considerations (token passthrough forbidden)
• The 2026 MCP Roadmap — Model Context Protocol Blog
• MCP joins the Agentic AI Foundation — Model Context Protocol Blog
• The MCP Registry: Trust and Security
• A2A Protocol Specification
• A2A Protocol Surpasses 150 Organizations… — Linux Foundation press release, 9 April 2026
• Agentic Commerce Protocol — specification repository (OpenAI + Stripe)
• Agentic Commerce Protocol — Stripe documentation
• Agent Payments Protocol (AP2) — Specification (Checkout Mandate, Payment Mandate, VDC formats)
• ERC-8004: Trustless Agents (status: Draft)
• RFC 8693 — OAuth 2.0 Token Exchange (act, may_act)
• A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP — arXiv:2505.02279