What evidence is required to let software buy autonomously without turning possession of a payment credential into unlimited commercial authority?
- 01
Agent recognition, user authorization and payment settlement solve different problems and should remain separate control layers.
- 02
A useful mandate must constrain merchant, amount, time and purpose while remaining revocable before execution.
- 03
The auditable unit is not a transaction hash; it is a chain from user intent to quote, authorization, settlement and outcome.
This note evaluates emerging agent-commerce protocols as control primitives. AP2 is still an early specification, x402 addresses a narrow HTTP payment flow, and Visa Trusted Agent Protocol focuses on merchant recognition. None should be read as a complete enterprise authorization system on its own.
A valid signature answers the wrong first question
When an agent controls a wallet or card credential, a valid signature proves that the credential approved a message. It does not prove that the user wanted this product, allowed this merchant, accepted this final price or had not revoked the agent's authority. Key custody and commercial authorization are related, but they are not interchangeable.
The control problem becomes sharper when the agent can compose tools. A model may select a merchant, negotiate a quote and trigger settlement in one run. If the only policy is a wallet balance, every upstream mistake inherits the ability to spend the full balance.
- Separate credential access from policy evaluation and approval state.
- Default-deny when a material quote term differs from the approved intent.
Three protocols, three different jobs
Google describes AP2 mandates as typed, signed records connecting an intent mandate, a cart-specific payment mandate and a receipt. Coinbase's x402 uses an HTTP 402 response to communicate payment instructions, after which a client submits a payment payload for verification and settlement. Visa Trusted Agent Protocol uses signed request metadata so a merchant can recognize a trusted agent and mitigate replay or tampering.
These mechanisms are complementary only if their boundaries remain visible. x402 can tell software how to pay for an API resource without proving that a principal approved the purchase. A trusted-agent signature can authenticate the agent-to-merchant interaction without proving that the final cart fits the user's budget. An AP2-style mandate can carry intent without replacing the underlying settlement rail.
- Model recognition, authorization and settlement as separate statuses in logs and user interfaces.
- Do not market protocol compatibility as end-to-end delegated-spend safety.
The minimum viable authority envelope
A reusable mandate should identify the principal, the acting agent and the policy version; constrain merchant or merchant category, currency, per-transaction amount, cumulative amount and validity window; and define whether substitutions, tips, recurring charges or partial fulfillment are allowed. Item or purpose constraints become necessary when a category limit is too broad.
Revocation must be checked at execution, not only when a mandate is issued. A quote that expires, a merchant that changes, or a price that crosses a tolerance should force re-authorization. Idempotency is equally important: an agent retry after a timeout must not create a second purchase.
- Bind the approved cart digest and total to the payment authorization.
- Use explicit expiry, revocation and idempotency identifiers on every execution attempt.
Receipts are policy evidence
A blockchain receipt proves that value moved. A card authorization proves that an issuer responded to a network message. Neither alone proves that the correct goods arrived or that the mandate was followed. A defensible record links intent, merchant quote, policy decision, user step-up if any, credential used, settlement reference and merchant outcome.
The open issue is liability. Protocols can make delegation legible, but they do not by themselves decide who bears loss when an agent misinterprets intent, a merchant misdescribes an item or a credential is compromised. Product teams should define that allocation before increasing autonomous limits, not after the first dispute.
- Retain machine-readable reason codes for approvals, declines and step-up requests.
- Test refunds, partial capture, duplicate execution and merchant non-delivery—not only successful checkout.
Primary sources
- Google Developers — Developer's Guide to AI Agent Protocols ↗
Documents AP2's intent mandate, payment mandate and receipt model, while explicitly describing the protocol as v0.1.
- Coinbase Developer Platform — x402 overview ↗
Defines the HTTP payment request, payment-signature and facilitator flow; it supports settlement analysis, not user-intent claims.
- Visa Developer — Trusted Agent Protocol specifications ↗
Documents signed agent requests, nonce and replay checks, and merchant verification behavior.
This analysis is general information, not legal, investment or trading advice. Source conditions may change after publication.