AI Shopping Agent Authorization: Mandates, Tokens, Passkeys, And Liability
Depth · Core
AI shopping agent authorization is the proof that a user allowed software to buy something on their behalf. The safest designs avoid handing an agent a raw card number. They use signed mandates, scoped payment tokens, passkeys, registered agents, and audit logs so the buyer, merchant, issuer, and network can see what was authorized.
Short answer
For an AI agent to pay safely, three things must be true: the user authorized the action, the payment credential is scoped so it cannot be reused broadly, and the merchant can keep evidence of the transaction. The industry is converging on mandates, tokenization, and strong authentication to solve those problems.
The authorization problem
Normal ecommerce assumes a human is present at checkout. Agentic commerce breaks that assumption. A user may ask an agent to act now, or may delegate a future purchase under constraints. That creates a hard question: did the agent have permission to make this exact purchase at this exact price from this merchant?
Good authorization answers that question before a dispute. Weak authorization tries to infer it after the fact.
Four authorization mechanisms
| Mechanism | What it proves | Where it appears |
|---|---|---|
| Mandate | The user delegated or approved a specific action or constraint set | AP2 |
| Shared Payment Token | The payment credential is scoped to a merchant and cart total | ACP and Instant Checkout |
| Network token | A card-network credential is bound to an agent, device, merchant, or use case | Visa, Mastercard, and related programs |
| Passkey or device-bound approval | The human used strong authentication to approve or delegate | Mastercard Agent Pay, AP2-style flows |
These are not mutually exclusive. A future transaction may combine an AP2 mandate, a tokenized payment credential, and a checkout protocol such as ACP or UCP.
Mandates: proof of delegated intent
AP2, the Agent Payments Protocol, is the clearest attempt to standardize agent authorization. Its core object is a mandate: a signed, tamper-evident credential that records what the user authorized. A closed mandate authorizes one specific action. An open mandate sets constraints for a later action, such as a spending cap, merchant, recurrence, product type, or time window.
The practical value is non-repudiation. If a customer later says “I did not authorize that,” the merchant or issuer should not be relying on a log note or a screenshot. It should be able to verify a signed authorization chain. For implementation detail, see AP2 mandates in practice.
Tokens: payment without card exposure
Tokenization limits what an agent can do with a payment credential. Instead of exposing a card number, a processor or network issues a token that is useful only within the intended scope.
In the ACP and Stripe/OpenAI flow, the payment service provider issues a Shared Payment Token. The token is passed to the merchant and is scoped to the merchant and cart total, so it cannot be reused as a general-purpose card credential. Card-network programs use related tokenization patterns, tied to registered agents and customer controls.
For the broader payment map, see how AI agents pay.
Passkeys and strong customer approval
Passkeys and device-bound keys help prove the human approved an action or delegated authority. Mastercard has tied Agent Pay to payment passkeys and tokenization. AP2 uses cryptographic credentials and key binding. The point is the same: authorization should be anchored to something stronger than “the agent said the user wanted it.”
Strong approval is especially important when a purchase is human-not-present. If the user is not watching the final checkout, the earlier delegation must be narrow enough and verifiable enough to trust.
Liability is still unsettled
The technical patterns are clearer than the liability rules. There is no single cross-network rulebook that settles every fraud, chargeback, “wrong item,” or “not as described” dispute for agent-made purchases. American Express has made a concrete consumer-protection pledge for purchases made by registered agents, but that does not settle the whole market.
Merchants should not treat this as a reason to ignore agentic commerce. They should treat it as a reason to read terms carefully and keep evidence.
What merchants should require
Before accepting agent-initiated purchases at scale, require:
- scoped authorization, not broad permission;
- tokenized payment credentials, not exposed card details;
- logs that connect the user’s authorization to the cart and payment;
- clear dispute terms from platforms, processors, and networks;
- customer-service workflows for agent errors and exceptions;
- reporting that separates agent-driven orders from ordinary web orders.
Use the RFP questions to make vendors answer these directly.
The evidence record
A defensible transaction record should include the user’s authorization, the agent or platform identity, the constraints, the cart and total, the shipping and tax state, policy links, the payment artifact, the order state, and any later refund or dispute event. This is why authorization is not only a payment problem. It is also a logging, customer-service, fraud, and governance problem.
FAQ
How does an AI shopping agent prove authorization? With a signed, scoped record of authorization. AP2 calls this a mandate; ACP uses a Shared Payment Token for the payment handoff; network programs use registered agents, tokenized credentials, and customer controls.
Is giving an agent a card number safe? The safer model is not to give the raw card number to the agent. A scoped token limits reuse and keeps card details out of the agent’s hands.
Who is liable if an agent buys the wrong thing? The rules are not settled across the industry. Merchants should read terms and keep transaction evidence. American Express has made an explicit protection pledge, but there is not yet one cross-network rulebook.
What should merchants log? Authorization, agent identity, constraints, cart, price, taxes, shipping, policy links, payment artifact, order status, and exceptions.