AI Shopping Agent Authorization: Mandates, Tokens, Passkeys, And Liability

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.

AP2 pairs each mandate with a signed receipt from whoever verified it: a Checkout Receipt from the merchant, a Payment Receipt from the payment processor, each carrying a success or error status and a hash of the mandate it answers. That matters for the evidence record below, because AP2’s own dispute procedure is not “produce the mandate,” it is produce the mandate and its receipt on both the checkout and the payment side, then recompute the hashes independently. If you are designing a log, design it to hold both. 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 the most concrete pledge, protecting card members from charges resulting from registered agent error, but that covers one closed-loop network rather than the market.

It is worth being precise about what the standards do here, because it is often overstated. AP2 does not assign liability. Its own executive summary lists accountability as an open question, asking whether the user, the agent’s developer, the merchant, the network, or the PSP should answer for a bad transaction. What AP2 sets out to do is narrower and more useful: “provide supporting evidence that helps payment networks establish accountability and liability principles.” Its specification then puts dispute resolution, retention, and retrieval explicitly out of scope. So a mandate is proof of what was authorized. It is not a promise about who pays.

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, any signed receipt returned for it, 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 pledged to protect card members from charges resulting from registered agent error, but there is not yet one cross-network rulebook, and AP2 deliberately produces evidence rather than allocating liability.

What should merchants log? Authorization, the signed receipt for it, agent identity, constraints, cart, price, taxes, shipping, policy links, payment artifact, order status, and exceptions.