Agentic commerce fraud is a third party abusing the payment authority an AI shopping agent legitimately holds, not a third party stealing the card number itself. That distinction is the whole threat model: the fraud doesn't happen because a credential leaked in the traditional sense — it happens because the delegation an agent was given to transact on a user's behalf becomes the mechanism an attacker rides to defraud a merchant, and neither classic card-fraud detection nor classic agent-security controls were built to catch it.

The threat model: hijacking delegated authority, not stealing the card

The attack surface here is delegation, not the card number. When a user authorizes an AI shopping agent to make purchases on their behalf, that authorization is a standing grant — a scope, a session, a token — that lets the agent transact without asking permission for every individual purchase. Compromise that grant, or abuse the automated checkout path it opens, and an attacker gets repeatable, high-volume purchasing power without ever touching the underlying card number directly.

This is structurally different from traditional card-present or card-not-present fraud, where the attacker's goal is to extract value from a single stolen card before it gets flagged and canceled. Here, the target is the agent's standing purchasing capability — an automated, always-on channel that, if abused, keeps producing fraudulent transactions until someone notices the pattern, not until a single card gets blocked.

It also means the usual advice for card fraud — monitor the card, watch for the specific stolen number, cancel and reissue — doesn't reach the actual point of failure. The card number in an agentic commerce fraud case may never be compromised in the traditional sense at all; what's compromised, or simply abused, is the mechanism that lets an agent spend without a human confirming each transaction. Defending the card protects the wrong asset.

Carding at agent speed

HUMAN Security has documented AI agents autonomously running carding attacks — testing stolen card numbers against live checkout flows to find which ones are still valid — a task that used to require either manual human effort or purpose-built bot scripts, and now can be delegated to a general-purpose agentic system. Carding at machine speed changes the economics of the attack: an agent doesn't get tired, doesn't need to solve a CAPTCHA manually, and can attempt far more validation cycles per hour than a human operator working through the same checkout by hand.

The mechanics of what's being tested haven't changed — carding has always been about finding which stolen card numbers still clear before the issuing bank catches on. What's changed is who's doing the testing and how fast. An agent built to complete a checkout flow reliably is, from a purely mechanical standpoint, extremely well suited to running the same flow thousands of times with different card numbers, which is exactly the capability carding fraud needs.

Why existing fraud models miss it

Fraud-detection models were trained to flag trial-and-error patterns: multiple failed attempts, small test transactions before a large one, inconsistent shipping and billing information typed by someone improvising. An agent-driven fraudulent order doesn't produce that signature. It completes a checkout the same clean, consistent way every time — correct field formatting, no fumbled retries, no telltale hesitation between steps — because it's the same automated flow executing repeatedly rather than a human working through unfamiliar friction.

That cleanliness is the blind spot. A fraud model trained on human carding behavior is looking for signs of struggle, and an agent doesn't struggle. The order that clears looks, to a model built on those assumptions, like a legitimate, well-informed customer completing a routine purchase — which is precisely the outcome an attacker using an agent for carding is trying to produce.

Merchant-side vs. agent-operator-side controls

Responsibility for closing this gap splits across two different parties, and conflating them is a common mistake — a merchant tightening checkout friction cannot fix a control that belongs upstream at the agent's wallet, and an agent operator tightening spend limits cannot fix a merchant fraud model still tuned for human shopping behavior.

Merchant-side controls need to evolve past behavioral fraud signals built for human shoppers. Agent-aware detection means treating consistently "too clean" checkout behavior as a signal worth scoring rather than a signal of legitimacy, watching for velocity across accounts and payment methods that would be implausible for a human but routine for an automated agent, and building explicit agent-identification signals into checkout — knowing when a transacting party is an autonomous agent rather than a person typing, so different risk models can apply.

Agent-operator-side controls are about the payment authority itself, not the checkout flow. Scoped credentials — payment tokens limited to a specific merchant, category, or spend ceiling — contain the blast radius of a compromised or abused delegation the way a single shared card number cannot. AP2 is the clearest public example of scoping payment authority at the protocol level, through signed mandates that bind an agent's purchase to what the user actually authorized rather than to an open-ended standing grant. Credit wallets for agent payments covers the mechanism for issuing agents purpose-scoped, revocable spending instruments instead of raw card numbers — the direct fix for the "delegated authority" half of this threat model.

What to instrument before you give an agent payment authority

Before granting any agent standing purchase authority, instrument for the failure mode described above, not just for the happy path of a completed transaction:

  • Hard spend ceilings per merchant and per time window — not a monthly total, but a rate that would make a carding sweep across many low-value validation attempts visibly abnormal even if each individual transaction looks clean. Budget policies and hard spend caps covers enforcing this at the point of transaction rather than after the fact.
  • Scoped, revocable payment tokens per agent — never a raw shared card number an agent (or anything that compromises the agent) can use against any merchant indefinitely.
  • Velocity and pattern monitoring on the agent side, not just the merchant side — an agent attempting checkouts against many different merchants in rapid succession is itself a signal worth alerting on, independent of what any individual merchant's fraud system sees.
  • A clear kill switch for the payment grant — the ability to revoke an agent's standing purchase authority immediately, without having to cancel and reissue an underlying card, once abuse is suspected.

That last point is also where this threat model diverges most clearly from a cost-control problem. Denial-of-wallet attacks describe an attacker running up your own agent's bill against your own budget — the damage lands on you directly, and the fix is a spend cap. Agentic commerce fraud is the opposite direction: the agent's payment authority is used to defraud a merchant, with your organization as the unwitting conduit rather than the direct financial victim — and the fix is authority scoping and revocation, not just a spend ceiling, because a fraud sweep can stay well under any reasonable budget cap while still being entirely illegitimate. The FinOps for AI agents guide is the starting point for building both kinds of control into an agent payment stack rather than treating spend caps as sufficient on their own.

Common questions

Is agentic commerce fraud the same as an agent stealing a card number? No. The attack targets the delegated payment authority an agent holds — a standing grant to transact — not the card number itself. An attacker abuses that authority rather than extracting a single card to use elsewhere.

Why do fraud-detection models miss agent-driven carding? They were trained to flag human trial-and-error signatures — failed attempts, inconsistent input, hesitation. An agent executes the same checkout flow cleanly and consistently every time, which reads as legitimate to a model built on human behavioral assumptions.

How is this different from a denial-of-wallet attack? Denial-of-wallet runs up your own agent's spend against your own budget — you're the financial victim. Agentic commerce fraud uses your agent's legitimate payment authority to defraud a merchant — you're the conduit, and a spend cap alone won't stop a fraud sweep that stays under it.

Who is responsible for stopping agentic commerce fraud — the merchant or the agent operator? Both, but for different halves of the problem. Merchants own detecting agent-driven checkout patterns their fraud models weren't trained on; agent operators own scoping and revoking the payment authority an agent holds so a compromised or abused delegation has a small, contained blast radius rather than an open-ended one.