Agent Protocols Compared: Security Properties of MCP, A2A, AP2 and ACP

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_REQUIRED state 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

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

• 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.

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, with alg, typ and kid in the protected header and an optional jku. 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

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

1. Inventory which protocols are already in use, including SDK defaults that enable them silently.
2. Write a protocol profile per protocol: allowed versions, required authentication schemes, signing requirements, logging fields.
3. Pilot with one internal MCP use and one partner A2A use, with gateways in observe mode.
4. Enforce the profiles at gateways; block unknown protocol versions.
5. 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 traceparent in _meta for 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

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