TLDR: Authority in agentic commerce is about identity, delegation, and proof. Systems must verify who the agent is, who it represents, and what it’s allowed to do before money moves. Early approaches include scoped payment tokens, signed mandates, OAuth linking, and rules requiring agents to identify themselves.
Follow the series: Part 1 • Part 2 • Part 3 • Part 4 • Part 5 (this)
A traveller reaches the castle gate and asks for an audience with the king. The guards don’t begin with his message, but with him:
Who are you? Who sent you? Is your seal valid? Does the king accept messengers from your court? Are you allowed through the outer gate, inner gate, or the throne room itself?
That’s the authority problem in agentic commerce. It’s not just about whether an agent may buy butter or switch a mortgage, but about identity, authentication, delegation, payment binding, seller policy, sanctions screening, household permission, privacy, expiry, and audit.
This is part 5 of a series on agentic commerce.
- Part 1 covered what agents can buy.
- Part 2 covered the rails.
- Part 3 covered your preferences.
- Part 4 covered agentic judgement when preferences failed.
This piece covers how humans and merchants will handle agentic proof.
An agent-led purchase has to answer five questions before checkout means anything: who’s the agent, who built it, who sent it, which human or account sits behind it, and what proof says this action is allowed.
Today’s first systems point in that direction. OpenAI’s Instant Checkout uses tokens limited to specific amounts and merchants. Google’s AP2 uses cryptographically signed mandates.
UCP uses OAuth 2.0 for account linking, and Amazon’s seller terms now say AI agents must identify themselves as automated systems.
So the core question isn’t “can the agent transact?” (execution, infrastructure) but “what credential is it carrying, who issued it, and what does that credential allow?”
Your shopping agent needs a passport
Most commerce systems were built around humans clicking buttons, typing passwords, and approving payments.
Browser agents disturb that pattern because they can appear inside the same channels as people.
That’s why the Amazon–Perplexity dispute became an early marker. Amazon accused Perplexity of disguising automated activity as human browsing, and a federal judge temporarily blocked Perplexity’s shopping agent from Amazon before an appeals court later paused the lower-court order.
That fight exposed the first layer of authority: agent identification. A seller needs to know whether the visitor is a human, browser automation tool, consumer’s personal agent, merchant’s internal agent, scraper, or fraud system wearing a nicer coat.
A future agent passport might include the agent provider, model or system class, registration status, user delegation proof, payment capability, allowed actions, fraud score, and expiry date.
That sounds heavy, but the web already has parts of this. OAuth already supports token exchange where a system can act with a delegated token under RFC 8693, and richer authorization requests can carry fine-grained permission details under RFC 9396.
The new part is commercial intent. The seller doesn’t just need to know that a token exists; it must also know what the user meant the agent to do.
The mandate isn’t the payment
Cards prove a payment method can be charged. They don’t prove that a human authorized an agent to select the product, choose the merchant, accept substitutions, approve delivery fees, or bind the account to a recurring agreement.
This is where protocols like AP2, ACP, UCP, MPP, and x402 come in.
AP2 frames authority around signed mandates: one mandate can capture the user’s intent, another can bind the cart and payment. Its docs describe verifiable digital credentials, checkout mandates, payment mandates, and an audit trail that links intent to checkout and payment records.
ACP, developed by Stripe and OpenAI, handles checkout flows where a business can accept or decline an agentic checkout request, while payment tokens remain permissioned and logged.
UCP describes account linking, cart building, checkout, order management, and identity linking through OAuth 2.0.
MPP and x402 move toward machine-native payments, with x402 reviving HTTP 402 Payment Required for online agent payments.
Authority will probably sit across several rails, not one universal super-protocol.
OAuth helps with delegated access; AP2 helps with signed commercial intent; ACP helps the checkout conversation; UCP helps agents and merchants speak a shared commerce language; and x402 and MPP help machines pay online.
Privacy can’t mean blindness
There’s a privacy problem hiding inside agent authority. Should a merchant know the full legal name of the human behind every agentic transaction, or should it only receive a valid signed credential and payment token?
The answer will depend on the product, risk, law, and payment method.
For ordinary card commerce, merchants already handle some payment-related data. PCI defines cardholder data as the full primary account number, and it may also include the cardholder name, expiry date, and service code. Sensitive authentication data, including CVC data, can’t be stored after authorisation even if encrypted.
But some transactions need more than payment proof. Sanctions rules may require screening of parties, locations, intermediaries, documents, and transactions.
OFAC describes this as part of sanctions compliance controls, while UK financial sanctions apply to people in UK territory and UK persons wherever they are located.
Age-restricted goods, geo-restricted products, regulated finance, medicines, and cross-border delivery will all need stronger checks.
So the better model may not involve exposing everything, merely attribute proofs: over 18, lives in an allowed region, delivery address verified, payment instrument valid, not on a blocked list, authorized to use this account.
That fits the UK GDPR principle of data minimisation: share only what’s needed, not every detail available.
Households are delegation chains
Agentic authority gets messier inside a household. A child may ask the family agent, which has the father’s card, to buy a PlayStation.
The seller may see a valid payment credential, but that doesn’t answer the household question: did the cardholder authorize this child, this agent, this product, this price, and this delivery address?
There are precedents. Apple’s Ask to Buy, Google Play’s family payment method and purchase approvals system, and Microsoft’s family spending limits for Xbox and other accounts already separate the person asking from the person paying.
Agentic commerce can borrow that pattern. The seller shouldn’t have to verify whether the child is truly related to the father. The identity provider, wallet, bank, or platform can hold the family graph and return a signed result: approved, declined, capped, restricted, or pending.
That avoids turning every merchant into a family investigator. It also avoids the Netflix password-sharing problem, where access spreads through informal household use and the platform has to guess who belongs where.
Agentic authority should expire
Authority shouldn’t last forever, and it should be tied to scope:
- A grocery agent may need a rolling monthly mandate.
- A flight-booking agent may need authority for one trip.
- A bill-switching agent may need a single signed instruction.
- A child’s gaming purchase authority may need a weekend limit.
Open banking gives a useful precedent: the FCA says third-party providers need explicit customer consent at least every 90 days when accessing account information.
Agentic commerce may not copy that number, but it can copy the idea. Standing authority needs refresh, revocation, and review.
This also protects merchants. UK Finance reported remote purchase fraud losses of £423.5 million in 2025, while the FTC reported that people in the US lost about $16 billion to fraud in 2025—a 25% YoY increase.
Agentic commerce adds new surfaces for impersonation, account takeover, rogue agents, fake delegations, prompt injection, payment replay, and malicious merchant behavior like recommendation poisoning.
An agent’s identity should therefore be revocable, rotated, suspended, and reissued.
A bad agent should lose trust. A compromised agent should lose its credentials. And a user should be able to wipe a mandate without wiping their human account.
The gatekeeping layer of AI shopping agents
The long-term authority stack will likely include agent identity, developer identity, user identity or attribute proof, delegated mandate, payment token, seller policy, risk checks, sanctions screening, and audit logs.
FIDO has already begun work on standards for trusted AI agent interactions, including agent authentication and payments working groups.
That doesn’t mean one winner solves everything. There may be OAuth-style account links, AP2-style mandates, ACP-style checkout, UCP-style commerce calls, x402-style wallet payments, and network-level rules from Visa, Mastercard, Stripe, PayPal, banks, and merchants.
The point is the chain of proof.
Who pays when things go wrong?
Authority is the layer that answers the gatekeeper’s questions before money moves: who are you, are you who you say you are, and on whose behalf are you here?
But that raises the next set of questions. How do we insure AI agents or merchants who accept agentic payments? How do we handle chargebacks, auditing, and retail recovery?
That takes us into layer 6: liability.