Agentic Commerce Fraud Guide: Fraud Controls When AI Agents Shop and Pay

When an AI agent shops and pays for a customer, the signals fraud teams have relied on for twenty years, a human at a keyboard, a familiar device, a typed card number, stop meaning what they used to. Merchants, payment service providers and issuers now see checkouts driven by software that carries a delegated credential, acts while the customer is offline and can be manipulated by text it reads on the way. This guide covers the fraud and dispute side of agentic commerce: agent tokens and mandates as fraud controls, telling a trusted agent from a hostile bot, the new fraud patterns, and how chargebacks on agent purchases are likely to be argued. It is written for fraud, payments and risk teams, and for executives deciding how fast to open checkout to agents. Authentication and identity design is covered in the Agentic Commerce Identity Guide, and the protocols themselves in the Agent Payments Protocols Guide; this page builds on both without repeating them.

Key takeaways

• Delegation blurs "authorised". Most fraud and dispute rules turn on whether the cardholder authorised a payment; an agent holding a credential the customer gave it sits awkwardly between authorised and unauthorised, so evidence of the customer's instruction becomes the deciding factor.
• Signed mandates are dispute evidence, not just security. AP2 Cart and Intent Mandates and Visa purchase instructions record what the customer actually approved; merchants that capture and keep them can show it in representment.
• Bot management must learn a third category. Traffic is no longer human or bad bot: a verified agent acting for a known customer needs its own policy, with cryptographic recognition replacing CAPTCHA and fingerprint heuristics.
• The agent is a new attack surface. Prompt injection, poisoned product listings, mispicks and stolen agent sessions produce losses that look like legitimate, authenticated orders.
• Velocity and value limits move to the mandate. Spending caps, merchant scope and time to live written into the customer's signed instruction are the cheapest fraud control available; enforce them at authorisation, not only in the agent.

Why agent purchases break existing fraud models

Card-not-present fraud scoring assumes a person in a browser session. Device fingerprint, typing cadence, mouse movement, session age, billing and shipping address match and the outcome of a 3-D Secure challenge all describe that person. An agent removes most of them. It may run in a cloud data centre, complete a checkout in seconds, reuse one browser profile for thousands of customers and never move a mouse. Applied unchanged, a rules engine will either decline good agent orders as bots or, once someone whitelists the agent platform, wave through everything that arrives from it.

The AP2 specification states the problem directly: existing payment protocols depend on direct human interaction, which has long served as a defence against online fraud, and agents weaken that defence. It also names three properties that are new for risk teams: user asynchronicity (the customer is not present when the payment runs), delegated trust (someone other than the cardholder initiates the transaction) and a temporal gap between when a credential or instruction was created and when it is used.

Agent tokens and mandates as fraud controls

The card networks and the AP2 project have converged on the same idea: give the agent its own credential, scoped by the customer, and send the network an explicit signal that an agent was involved. Each piece has a direct fraud use.

• Agent-specific network tokens: Visa Intelligent Commerce provisions tokens through the Visa Token Service, so the agent and merchant hold a token reference rather than the card number. Mastercard's Agent Pay announcement (April 2025) describes Mastercard Agentic Tokens built on its existing tokenisation. A token bound to one agent can be suspended without reissuing the customer's card.
• Purchase instructions: Visa's developer documentation describes consumer-approved purchase instructions that define what the agent may buy, carried as an encrypted payload. Fraud teams should treat the instruction as the authorisation boundary: an order outside it is suspect even if the token is valid.
• AP2 Intent Mandate: for human-not-present purchases the customer signs a mandate holding the chargeable payment methods, the shopping intent, a "prompt playback" (the agent's restatement of the request in natural language), a risk payload and a time to live. The time to live closes the temporal gap; the prompt playback is the record that the agent understood the task.
• AP2 Cart Mandate: for human-present purchases the merchant builds the cart and the customer signs it, typically with a hardware-backed device key. It fixes the exact items, price, payee and refund conditions.
• AP2 Payment Mandate: shared with the network and issuer alongside the authorisation message. The specification requires it to carry agent presence and transaction modality (human present or not), so the issuer can approve, decline or challenge with the knowledge that an agent is involved.
• Agent registration: Mastercard says agents must be registered and verified before they can transact; Visa requires credential providers and merchants to know which agent they are dealing with. For a merchant, registration status is an input to risk, not a guarantee of good behaviour by every session of that agent.

Merchants that already hold cards on file should note that the Visa Trusted Agent Protocol can pass a Payment Account Reference (PAR), allowing a merchant to link an agent purchase to the same underlying account the customer has used before without seeing the card number. That link is a strong first-party fraud signal: an account with a long, clean history behaves differently from a new card attached yesterday. For the cryptographic detail of tokens and mandates, see the Agent Payments Protocols Guide.

Telling a trusted agent from a hostile bot

Bot defences built for scalpers and credential stuffing will collide with legitimate agents. The answer is not to lower defences for anything that claims to be an agent: user agent strings are trivially spoofed. It is to recognise agents cryptographically and give recognised agents their own lane.

Visa's Trusted Agent Protocol, announced on 14 October 2025 with Cloudflare, uses HTTP Message Signatures (RFC 9421) aligned with the IETF Web Bot Auth work. Its documentation says each signature carries a timestamp, a unique session identifier, a key identifier and an algorithm identifier, and is bound to the merchant's domain and the specific operation (browsing or payment). That binding gives a merchant three checks it can run at the edge: is the key from a known agent directory, is the signature fresh and single use, and was it made for this site and this action.

OWASP API Security Top 10 2023 names this risk API6:2023 Unrestricted Access to Sensitive Business Flows: checkout, reservation and gift card flows that need protecting from automated abuse even when every request is technically valid. Agent lanes are an API6 control as much as a fraud one. See the Bot vs AI Agent Traffic Management Guide for edge policy and the Know Your Agent (KYA) Guide for agent due diligence.

New fraud patterns in agent-driven checkout

Most agent fraud does not look like stolen card fraud. The payment is authenticated and the token is valid; what is wrong is the instruction, the agent's interpretation of it, or who controls the agent.

The Chevrolet dealer chatbot incident is an early warning from the seller's side: users talked a website bot into "agreeing" to sell a car for one dollar. No sale completed because nothing connected the bot's words to a payment or contract system. In agentic commerce that connection exists by design, which is why the binding between signed customer intent and the final cart matters so much. See the Prompt Injection Guide and the AI-Driven Account Takeover Guide.

Chargebacks and disputes on agent purchases

Dispute rules were written for cardholders and merchants. Agent purchases add a third actor whose decisions may be the real cause of a loss, and the industry has not finished deciding where liability lands. The AP2 specification sets out a principle rather than a rulebook: accountability should stay close to existing regulation and dispute processes and, in most cases, rest with a real-world entity (the user, the merchant or the issuer). It publishes a table of scenarios, including first-party misuse, mispicks approved and not approved by the user, merchant non-fulfilment, account takeover and man-in-the-middle tampering, but says the table is a guide and each network sets its own liability terms.

The authorisation question

For card and debit disputes the first question is usually whether the cardholder authorised the transaction. In the United States, Regulation E (12 CFR 1005.2(m)) defines an unauthorised electronic fund transfer as one initiated by someone other than the consumer without actual authority and from which the consumer receives no benefit, and it excludes transfers by a person the consumer furnished with the access device, unless the consumer has told the institution that person is no longer authorised. How regulators and networks will apply ideas like this to an AI agent holding a delegated token is not settled; treat it as an open question and take legal advice for your jurisdiction. What is clear is that the outcome will turn on evidence of what the customer instructed.

Evidence to capture for every agent order

1. Agent identity: the verified agent key identifier, signature verification result and timestamp.
2. Customer instruction: the Intent Mandate or purchase instruction, including prompt playback, limits and time to live; or the signed Cart Mandate for human-present orders.
3. Cart binding: a hash of the final cart and proof it falls inside the instruction.
4. Authentication outcome: how the customer authenticated when signing (passkey, biometric, step-up) and any challenge result returned by the issuer.
5. Account link: PAR or customer account history showing prior good orders on the same underlying account.
6. Fulfilment: delivery confirmation to the address in the instruction, download or usage logs for digital goods.

The AP2 specification says merchants can present the cart, its hash and the mandates as evidence, and that an adjudicator would check whether the user approved the cart and whether the merchant delivered what was requested. If you cannot produce the six items above for an agent order, assume you will lose the dispute.

Refunds before disputes

Many agent errors are honest mispicks. A fast, agent-aware refund and return path (the AP2 Cart Mandate can state refund conditions) costs less than a chargeback and keeps the customer. Make it easy for the customer, or the customer's agent, to cancel an order placed in error, and log the reason so mispick rates per agent can be measured. The Air Canada chatbot ruling is a reminder that a business cannot simply disown what its own automated assistant told a customer; expect similar reasoning when agent behaviour causes a loss.

Decision guidance: how far to open checkout to agents

• Low-value, low-risk goods: accept verified agents with an Intent Mandate and caps; human-not-present is acceptable where refunds are cheap.
• High-value, resellable goods (electronics, gift cards, tickets): require a human-present Cart Mandate or customer step-up before payment; these are the goods fraudsters target.
• Digital goods and subscriptions: require explicit recurring scope in the mandate; recurring charges the customer did not expect are the most likely "my agent did it" disputes.
• Small merchants: rely on the payment service provider's agent recognition and token support rather than building signature verification in-house; insist that agent signals reach your fraud tool and dispute evidence store.
• Large merchants and marketplaces: verify agent signatures at the edge, build an agent lane in bot management, score per agent and publish clear terms on which agents and modalities you accept.
• Issuers: use the agent presence and modality signal in the Payment Mandate in authorisation models and in dispute intake, so customer service asks "did you instruct your agent?" before classifying a claim as fraud.

How to implement: a phased rollout

1. Inventory agent traffic. Measure how much checkout traffic already comes from declared agents and which platforms; separate signed from unsigned claims.
2. Add agent fields to the fraud data model. Agent identifier, verification result, modality (human present or not), mandate reference and limits. Without these fields no later control can be measured.
3. Verify signatures in monitor mode. Validate agent signatures and log results without changing decisions for two to four weeks; compare outcomes for verified, unverified and spoofed traffic.
4. Pilot an agent lane. For a small product set, let verified agents with valid mandates bypass CAPTCHA and score them on mandate fit and account history. Keep a kill switch per agent identifier.
5. Build the evidence store. Persist the six evidence items per order with the retention period your dispute windows require; test retrieval with a mock representment.
6. Tune and expand. Add categories, set per-agent velocity thresholds, and route high-risk agent orders to customer step-up rather than outright decline.
7. Roll back cleanly. If losses rise, disable the agent lane per agent or per category and fall back to standard bot and fraud rules; tokens bound to a misbehaving agent can be suspended without touching the customer's card.

Detection and measurement

• Agent fraud rate: confirmed fraud value on agent orders divided by agent order value, split by agent and by modality.
• Agent dispute rate: disputes per thousand agent orders, with the share classed as first-party misuse versus unauthorised versus mispick.
• Representment win rate on agent disputes: a direct test of whether the evidence store works.
• Mandate violation rate: carts rejected because they fell outside the signed instruction; a rising rate for one agent suggests injection or a faulty agent release.
• False decline rate for verified agents: good agent orders declined by legacy bot or fraud rules.
• Spoofed agent attempts: requests claiming agent status with missing or invalid signatures.

Alert on new mandates followed within minutes by a shipping address change, on a burst of orders from one agent key across many unrelated accounts, and on mandates with unusually long time to live or wide merchant scope.

Framework mapping

Common failure patterns

• Whitelisting an agent platform by user agent string. Anyone can claim to be a known agent; without signature verification the whitelist becomes a bypass for card testers. See the Card Testing and Carding Attacks Defence Guide.
• Blocking all agents as bots. Good customers move to competitors and the agent platforms route around you; the fraud is not prevented, only displaced.
• Enforcing limits only inside the agent. A compromised or injected agent ignores its own guardrails; caps must also be enforced by the token, the network or the merchant at authorisation.
• Not storing the mandate. Merchants verify the instruction at checkout, then discard it, and lose disputes they could have won.
• Classifying every agent complaint as fraud. Mispicks routed to fraud queues inflate fraud figures, trigger unnecessary card reissues and hide a product quality problem in the agent.
• Long-lived, open-ended mandates. An Intent Mandate with no meaningful time to live or merchant scope is a standing payment authority waiting to be abused. See the AI Agent Action Approvals and Spending Limits Guide.

Practitioner checklist

• Agent identifier, verification result, modality and mandate reference are fields in the fraud data model and dispute record.
• Agent signatures are verified against a key directory, with freshness, single use and domain and operation binding checked.
• Unsigned agent claims are treated as unverified automation and cannot pay.
• High-value and resellable goods require a human-present Cart Mandate or customer step-up.
• Mandate caps, merchant scope and time to live are enforced at authorisation, not only in the agent.
• The six evidence items are retained for every agent order for the full dispute window.
• Shipping address changes inside agent flows trigger step-up.
• Dispute intake asks whether the customer instructed an agent and routes mispicks to refunds, not fraud.
• Agent fraud, dispute, mandate violation and false decline rates are reported per agent.
• A per-agent kill switch and token suspension procedure is documented and tested.

Standards and references

• AP2 Project: Agent Payments Protocol Specification
• Visa: Trusted Agent Protocol (GitHub)
• Visa Developer: Visa Intelligent Commerce
• Mastercard: Mastercard Unveils Agent Pay
• IETF: RFC 9421 HTTP Message Signatures
• OWASP: API6:2023 Unrestricted Access to Sensitive Business Flows
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• CFPB: Regulation E 1005.2 Definitions

Related NHI Mgmt Group resources: Agentic Commerce Identity Guide · Agent Payments Protocols Guide · Agentic Commerce for Merchants · First-Party Fraud Guide · Payment Fraud Guide