Trust in Depth for AI Agents
The Landscape

Protocol Landscape

Four major protocols define how AI agents conduct commerce. They all solve the same problem — and they all defer the same things.

Four major protocols now define how AI agents conduct commerce on behalf of humans. Each was created by a different coalition of technology and payments companies. Each addresses a genuine need. And each, whether explicitly or by omission, defers the same structural questions.

The Four Protocols

ProtocolCreatorsCore Mechanism
Verifiable Intent (VI)MastercardSD-JWT credential chain binding human intent to agent actions
Universal Commerce Protocol (UCP)Google, Shopify coalitionREST API with composable commerce capabilities
Agent Payments Protocol (AP2)GoogleVerifiable Digital Credentials for agent-to-agent trust
Agentic Commerce Protocol (ACP)OpenAI, StripeAPI-driven checkout sessions with payment delegation

These are not competing standards in the way that VHS competed with Betamax. They operate at different points in the commerce stack and address different aspects of the same lifecycle. VI focuses on the delegation chain from human to agent. UCP focuses on the merchant integration surface. AP2 focuses on trust establishment between agents. ACP focuses on the checkout moment itself.

Together, they collectively address the purchase transaction lifecycle: discovery, negotiation, cart building, authorization, payment, verification, fulfillment, and post-purchase tracking.

The Right First Problem

The question all four protocols answer is: how does an AI agent buy something on behalf of a human?

This is the right first problem to solve. It is concrete, economically motivated, and has clear success criteria — did the correct item arrive at the correct address for the agreed price? The payments industry has decades of infrastructure for handling this kind of transaction, and extending it to AI agents is a natural evolution.

It is also the smallest problem in the space.

What They Share

Beyond the specific mechanisms, the four protocols share an implicit assumption: the commitment is a transaction. A moment. A single exchange. One party pays, another delivers, and the interaction is complete.

This assumption is correct for a large class of commerce. It is insufficient for everything else.

What They Handle

Lifecycle PhaseVIUCPAP2ACP
Discovery--/.well-known/ucp manifestAgent Cards/.well-known/acp.json manifest
AuthenticationSD-JWT credential chainHTTP Message Signatures (RFC 9421)OAuth2 + VDCsBearer tokens
Cart / CheckoutL3 Checkout MandateComposable cart + checkoutIntent / Cart MandateCheckout sessions
Payment AuthorizationL3a Payment MandatePSP integrationPSP integrationStripe delegation (SPTs)
Fulfillment Tracking--Order lifecycle webhooks--Session state lifecycle
Constraint VerificationL2 → L3 bounds checking----Capabilities negotiation
Merchant Commitment--JWS merchant_authorization----
Delegation ProofL1 → L2 → L3 chain--VDC chain--

Each protocol is strong where its creators have domain expertise. Mastercard built the delegation and payment authorization layer. Google and Shopify built the merchant integration surface. Google built the agent trust layer. OpenAI and Stripe built the checkout API.

What They All Defer

The structural gaps are remarkably consistent across all four protocols.

Dispute Resolution

No protocol defines a dispute mechanism beyond acknowledging that disputes will occur.

  • VI (Section 2.4): "VI does not define how disputes are initiated, routed between parties, escalated, or resolved."
  • AP2: "Disputes follow existing regulations; innovate only where necessary."
  • ACP: Silent on disputes entirely.
  • UCP: No dispute mechanism beyond order lifecycle webhooks.

This is not a criticism. Dispute resolution is genuinely hard, and deferring it was a reasonable decision for first-generation protocols focused on enabling the transaction. But the deferral creates a gap that widens with every increase in transaction complexity, value, and autonomy.

Persistent Identity

All four protocols scope identity to the session or transaction. VI's L1 credential has a longer lifetime (~1 year), but it binds to Mastercard's card network identity — it does not create a persistent, protocol-agnostic identity that an agent carries across interactions with different merchants, different payment networks, and different jurisdictions.

Entity Authority

None of the protocols verify organizational authority for high-value commitments. When an AI agent acts on behalf of a corporation, who authorized it? Under what bylaws? With what spending limits? The protocols assume this has been handled elsewhere.

Agreement Lifecycle

None support obligations that extend beyond the transaction — multi-year service contracts, subscription agreements with renewal terms, licensing arrangements with usage-based pricing. The commitment model is a single exchange, not an ongoing relationship.

Jurisdictional Linkage

All four protocols are jurisdiction-agnostic by design. This is a feature for global commerce and a gap for legal enforceability. When a dispute arises between a buyer in Germany and a seller in Japan with an AI agent hosted in the United States, which law applies? None of the protocols answer this question. None attempt to.

Sequential, Not Competing

The commerce protocols and Integra are not competing layers. They are sequential layers in a stack.

The protocols handle Phase 1: the purchase transaction. The moment of exchange. This is necessary infrastructure and it is being built well.

Integra handles what comes after: persistent identity that spans protocols, enforceable agreements that outlast sessions, structured dispute resolution that connects digital commitments to legal systems, and jurisdictional linkage that makes enforcement possible.

The question is not whether agents can buy things. The protocols are solving that. The question is what happens when the thing that was bought does not arrive, or arrives broken, or was not what was agreed to, or was agreed to by an agent that exceeded its authority, or involved parties in jurisdictions with conflicting consumer protection laws.

That is the problem space this documentation explores.