Architects are being asked to pick between MCP, A2A, AP2 and ACP as if they were competing standards, when they solve different problems and carry very different security properties. MCP connects an agent to tools and data, A2A connects agents to other agents, AP2 proves that a user authorised an agent's payment, and the Agentic Commerce Protocol lets agents complete checkout with merchants using delegated payment tokens. The acronym ACP has also been used for IBM's Agent Communication Protocol, which has since merged into A2A. This guide compares the four on identity, authorisation, message integrity, discovery and failure modes, using each project's current official specification as checked on 27 October 2026: MCP revision 2026-07-28, A2A 1.0, AP2 specification v0.2 and Agentic Commerce Protocol version 2026-04-17. It is for architects and security reviewers designing agent systems that use more than one of them.
Key takeaways
- They are layers, not rivals. A shopping agent can call tools over MCP, delegate to a merchant agent over A2A, check out through the Agentic Commerce Protocol and carry AP2 mandates as proof of user intent.
- Only the payment protocols sign intent. MCP and A2A rely on transport security and OAuth-style bearer tokens; AP2 and the Agentic Commerce Protocol add signed mandates, bound keys or tightly constrained tokens because money moves.
- A2A leaves authorisation to you. The A2A specification makes per-request authentication mandatory but states that authorisation logic is implementation-specific, and that the
TASK_STATE_AUTH_REQUIREDstate is not itself an authorisation. - AP2 assumes the agent may be hostile. Its security considerations treat prompt injection as unpreventable and include every LLM and agent in the threat model, which is the right default for all four.
- Maturity varies widely. MCP and A2A have dated or versioned stable releases; AP2 is at v0.2 and the Agentic Commerce Protocol describes itself as beta. Pin versions and expect change.
What each protocol is for
| Protocol | Problem it solves | Steward | Version checked | Typical parties |
|---|---|---|---|---|
| Model Context Protocol (MCP) | Agent or host to tools, resources and prompts | Model Context Protocol project (open source) | Revision 2026-07-28 (latest) | Host and client, MCP server, authorisation server |
| Agent2Agent (A2A) | Agent to agent task delegation across vendors and frameworks | Linux Foundation project, contributed by Google | 1.0.0 (12 March 2026), patch 1.0.1 | Client agent, remote agent (A2A server) |
| Agent Payments Protocol (AP2) | Verifiable proof that a user authorised an agent's checkout and payment | Open source project in the google-agentic-commerce organisation | Specification v0.2 | User and trusted surface, shopping agent, merchant, credential provider, payment processor, network |
| Agentic Commerce Protocol | Agent-driven checkout with merchants and delegated payment credentials | Maintained by OpenAI and Stripe; status beta | API version 2026-04-17 | Agent (buyer's application), merchant, payment service provider |
| Agent Communication Protocol (IBM BeeAI) | Agent to agent messaging | Now part of A2A under the Linux Foundation | Migrated | Treat existing deployments as A2A migration candidates |
AP2 describes itself as an extension for A2A, MCP and the Universal Commerce Protocol, and operates as a security feature within a commerce protocol rather than defining catalogue or checkout APIs itself. The Agentic Commerce Protocol, in contrast, defines the checkout, delegated payment and feed APIs, and since 2026-04-17 publishes an MCP binding.
Identity and authentication compared
| Property | MCP | A2A | AP2 | Agentic Commerce Protocol |
|---|---|---|---|---|
| Who authenticates to whom | Client to MCP server with OAuth 2.1 style access tokens from an authorisation server | Client agent to remote agent using schemes declared in the Agent Card | User signs mandates on a trusted surface; agent signs closed mandates with a key bound in open mandates | Agent to merchant and to payment provider with bearer tokens; request signatures recommended |
| Credential types | OAuth access tokens bound to the server by RFC 8707 resource indicators | API key, HTTP auth, OAuth 2.0 (authorisation code with PKCE, client credentials, device code), OpenID Connect, mutual TLS | Verifiable digital credentials: OpenID4VP with SD-JWT VCs (ES256), key binding via cnf | Authorization: Bearer; optional detached Signature with Timestamp (Ed25519 or ES256 advertised out of band) |
| Server identity | TLS; server identifies itself in result _meta and via server/discover | TLS certificate validation SHOULD; Agent Card MAY carry JWS signatures | Merchant-signed checkout JWT; signed receipts | TLS and merchant API endpoints |
| Client registration | Client ID Metadata Documents preferred; Dynamic Client Registration deprecated in 2026-07-28 | Out of band, per declared scheme | Trust lists of agent providers or user credentials | Out of band onboarding between agent, merchant and PSP |
- MCP: servers MUST validate that tokens were issued for them and MUST NOT pass client tokens through to downstream APIs. Revision 2026-07-28 adds RFC 9207 issuer validation against mix-up attacks and requires clients to key stored credentials by issuer. See the MCP Authorisation Specification Guide.
- A2A: production deployments MUST use HTTPS or TLS (TLS 1.3 recommended), and servers MUST authenticate every request. A2A 1.0 removed the OAuth implicit and password flows and added device code and PKCE. See the A2A Protocol Security Guide.
- AP2: verifiers always receive closed checkout and payment mandates. In human-present mode the user signs them; in human-not-present mode the agent signs them with a key the user's open mandate authorised, and constraints in the open mandate let the verifier check the purchase matches intent.
- Agentic Commerce Protocol: the delegate payment endpoint issues a vault token that is usable only within an allowance (reason, maximum amount in minor units, currency and expiry), with a mandatory
Idempotency-Key.
Authorisation and delegation
The biggest practical difference is how each protocol expresses what an agent may do on someone's behalf.
| Question | MCP | A2A | AP2 | Agentic Commerce Protocol |
|---|---|---|---|---|
| How is scope expressed? | OAuth scopes with step-up challenges via WWW-Authenticate | Implementation-specific: skills, actions, data policies, OAuth scopes | Mandate constraints over checkout and payment (amounts, payees, references) | Allowance on the delegated payment token |
| Mid-task authorisation | Step-up OAuth; URL mode elicitation for third-party authorisation | TASK_STATE_AUTH_REQUIRED, credentials received out of band | Return to trusted surface for a new signed mandate | Consumer authentication such as 3DS outcomes in checkout |
| Multi-hop delegation | Not defined; token passthrough forbidden | A client agent may push AUTH_REQUIRED up its own chain; in-band credentials SHOULD be bound to and encrypted for the requesting agent | Agent-to-agent delegation of mandates defined in the spec | Not defined |
| Evidence afterwards | Logs only | Task history and logs | Signed mandates and receipts usable in disputes | Idempotency records, signed requests where used |
A2A's own text is explicit that the protocol does not define the scope, validity or revocation semantics of credentials obtained during AUTH_REQUIRED, and that such a credential must not be assumed to authorise later messages unless your implementation says so. That gap is where most multi-agent authorisation failures will come from. See the Multi-Agent and A2A Security Guide for delegation patterns across hops.
Discovery and integrity of metadata
- MCP: servers are found through configuration, registries such as the official MCP Registry, and
server/discover. Tool definitions are not signed, so tool poisoning and rug pulls are controlled by review, pinning and gateways. See the MCP Registry and Server Publishing Security Guide. - A2A: Agent Cards are served at
/.well-known/agent-card.json, through registries, or by direct configuration. Cards MAY be signed with JWS (RFC 7515) over a JSON Canonicalization Scheme (RFC 8785) form, withalg,typandkidin the protected header and an optionaljku. Because signing is optional, clients must decide whether to require it. - AP2: the merchant signs the checkout JWT, and the payment mandate is bound to it by hash. The specification requires a non-deterministic signature scheme such as ECDSA for the checkout JWT to prevent rainbow table attacks on the hash.
- Agentic Commerce Protocol: discovery and product feeds are merchant-to-agent APIs; the 2026-04-17 Feed API is a push model in which merchants send catalogue data to agent-hosted endpoints.
Threats each protocol does and does not address
| Threat | MCP | A2A | AP2 | Agentic Commerce Protocol |
|---|---|---|---|---|
| Prompt injection steering the agent | Not prevented; mitigated by consent, scopes and client controls | Not prevented; remote agent output is untrusted input | Assumed to happen; mandates limit what an injected agent can buy | Not prevented; allowance limits spend |
| Token theft and replay | Audience binding, short-lived tokens, no passthrough | Depends on scheme; mTLS or sender-constrained tokens reduce replay | Key-bound mandates (cnf, sd_hash) | Allowance expiry, idempotency keys, optional signatures |
| Impersonated endpoint | TLS; registry namespace checks | TLS; optional Agent Card signatures | Merchant-signed checkout; verifier checks | TLS; onboarding |
| SSRF | Documented in OAuth discovery; client MUST consider | Push notification webhook URLs SHOULD be validated against private ranges | Not a primary concern | Not specifically addressed in the RFCs read |
| Disputes and non-repudiation | None in protocol | None in protocol | Core purpose: mandates and receipts as dispute evidence | Partial: signed requests and receipts where implemented |
Choosing and combining protocols
- Agent needs tools or data you control: use MCP, behind a gateway, with per-server credentials.
- Agent needs another organisation's agent to do work: use A2A, require signed Agent Cards from external partners, and define authorisation per skill yourself.
- Agent will spend money: do not rely on MCP or A2A tokens alone. Use a payment protocol that limits the credential (Agentic Commerce Protocol allowances) or proves user intent (AP2 mandates), and keep a human-present path for high-value purchases.
- Small organisation: standardise on MCP for internal tools and adopt A2A only for named partners; let payment providers carry payment protocol complexity.
- Large or regulated organisation: run an internal catalogue for both MCP servers and A2A agents, require mTLS or sender-constrained tokens between agents, and log protocol versions per connection.
Rollout approach
- Inventory which protocols are already in use, including SDK defaults that enable them silently.
- Write a protocol profile per protocol: allowed versions, required authentication schemes, signing requirements, logging fields.
- Pilot with one internal MCP use and one partner A2A use, with gateways in observe mode.
- Enforce the profiles at gateways; block unknown protocol versions.
- Review the profiles each time a protocol publishes a new version; rollback means pinning the previous version at the gateway, not disabling authentication.
Worked example: one purchase across the stack
A user asks a travel assistant to book and pay for a hotel within a budget. Following the request through each layer shows where identity and trust change hands.
- Tools over MCP: the assistant queries a calendar and a loyalty programme through MCP servers. Each server receives a token issued for that server only; the loyalty server must not forward the assistant's token to the loyalty provider's API but use its own credential. Risk: tool output from a compromised server injects instructions.
- Delegation over A2A: the assistant asks a hotel group's booking agent to find rooms. It fetches the Agent Card from the hotel group's well-known URL, verifies the JWS signature against the expected key, and authenticates with the scheme the card declares, for example OAuth client credentials or mutual TLS. Risk: the booking agent's replies are untrusted input to the assistant's model.
- Mid-task authorisation: the booking agent needs the user's loyalty number confirmed and moves the task to
TASK_STATE_AUTH_REQUIRED. The assistant obtains the confirmation out of band and does not treat the state change as permission for anything else. - Checkout: through the Agentic Commerce Protocol the assistant creates a checkout session with the merchant and requests a delegated payment token whose allowance caps the amount at the budget, in the right currency, expiring in minutes.
- Proof of intent: where AP2 is supported, the user's open mandate sets constraints (merchant, maximum price, dates) and the agent signs closed checkout and payment mandates that verifiers check against those constraints. The receipts become dispute evidence.
Across the five steps there are at least four distinct credentials, and none of them should be usable at another step. Designing so that a stolen MCP token cannot pay and a stolen payment token cannot exceed its allowance is the core architectural control.
Detection and measurement
- Log per connection: protocol and version, peer identity (server name, Agent Card URL and signature status, merchant ID), authentication scheme, scopes or allowance, and trace IDs. MCP 2026-07-28 reserves
traceparentin_metafor OpenTelemetry propagation. - Alert on: unsigned Agent Cards from external partners, Agent Card key changes, MCP tokens used against the wrong resource, A2A tasks stuck in or repeatedly entering
AUTH_REQUIRED, payment tokens presented after expiry or above allowance.
Metrics
- Share of external A2A partners with signed and verified Agent Cards.
- Share of agent-initiated payments covered by AP2 mandates or constrained delegated tokens.
- Number of protocol versions in production per protocol (target: one or two).
- MCP and A2A connections passing through a gateway, as a share of all observed connections.
Framework mapping
| Control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Agent and server authentication | IA-9 Service Identification and Authentication; IA-8 Identification and Authentication (Non-organizational Users) | PR.AA-01, PR.AA-03 |
| Transport integrity and Agent Card signatures | SC-8 Transmission Confidentiality and Integrity; SC-23 Session Authenticity | PR.DS-02 |
| Delegation limits between agents | AC-4 Information Flow Enforcement | PR.AA-05 |
| Signed mandates and receipts | AU-10 Non-repudiation | PR.DS-02 |
| Partner and protocol supplier risk | SR-3 Supply Chain Controls and Processes | GV.SC-07 |
Relevant threat references: MITRE ATT&CK T1557 Adversary-in-the-Middle and T1528 Steal Application Access Token for token and transport attacks, and MITRE ATLAS AML.T0051.001 for indirect prompt injection carried between agents.
Common failure patterns
- Using A2A authentication as authorisation. A valid OAuth token from a partner agent says who is calling, not which skills or data it may use.
- Treating AUTH_REQUIRED as consent. The specification forbids it; credentials gathered mid-task need explicit scope and expiry.
- Passing tokens down a chain. MCP forbids token passthrough; in A2A, in-band credentials crossing several agents are exposed to every hop unless bound and encrypted for the requester.
- Letting a tool protocol move money. An MCP tool that charges a stored card with a broad API key skips every protection the payment protocols add.
- Accepting unsigned discovery data. Unsigned Agent Cards and unpinned MCP tool lists let an attacker who controls DNS or a registry entry redirect agents.
- Running legacy ACP without a migration plan. IBM's Agent Communication Protocol has merged into A2A; unmaintained deployments will drift from security fixes.
Practitioner checklist
- Record which of MCP, A2A, AP2 and the Agentic Commerce Protocol each agent uses, with versions.
- Write a security profile per protocol covering authentication, signing, logging and allowed versions.
- Enforce audience-bound tokens and no passthrough for MCP; require issuer validation in clients.
- Define per-skill authorisation for every A2A server and require signed Agent Cards from external partners.
- Validate A2A push notification webhook URLs and authenticate webhook calls both ways.
- Route agent payments through mandates or allowance-limited tokens, never broad stored credentials.
- Propagate trace context across protocols so one user request can be followed end to end.
- Migrate any Agent Communication Protocol deployments to A2A.
Standards and references
- Model Context Protocol: Specification revision 2026-07-28
- A2A Protocol: Agent2Agent Protocol Specification
- AP2: Agent Payments Protocol specification and repository
- Agentic Commerce Protocol: Specification repository
- BeeAI: Agent Communication Protocol (now part of A2A)
- A2A Protocol: Changelog (v1.0.0 and later)
- AP2: Security and Privacy Considerations
- Model Context Protocol: Security Best Practices
Related NHI Mgmt Group resources: Multi-Agent and A2A Security Guide · MCP Security Guide · Agent Payments Protocols Guide · Agentic Commerce Identity Guide