The human-buyer assumption is breaking down.
For years, fraud frameworks assumed a human was involved in the transaction: buyer, victim, or operator. Fraud defense was built around familiar objects: accounts, cards, credentials, identities, devices, merchants, and transactions.
In agentic commerce, those are no longer the only objects under attack.
When agents search, authenticate, and purchase on users' behalf, the fraud surface shifts. The actor may not be the account holder. The credential may be a scoped token. The abuse may not target the payment instrument directly.
It may target the delegated authority itself.
This is no longer a forecast. Across 2025 and 2026, every major payment network shipped a protocol that made delegated authority an explicit, signable object and, in doing so, an explicit, attackable one.
The Shift: From Accounts to Mandates
In traditional models, a valid token and a legitimate account were often considered sufficient trust signals.
In agentic systems, a technically authorized transaction can still be abusive if the mandate is misused.
The permission layer becomes a fraud surface:
- Forged mandates
- Over-scoped consent
- Escalated spending authority
- Persistent token abuse
- Mandate pooling across agents or workflows
This changes the classification challenge.
Fraud defense now needs language for delegated authority, scoped consent, agent identity, token lifespan, mandate boundaries, and machine-speed abuse.
| Traditional objects | Agentic objects |
|---|---|
| Accounts | Intent & Cart mandates |
| Cards & payment instruments | Scoped tokens |
| Credentials | Delegated authority |
| Devices | Agent identity |
| Merchants | Mandate authorization chains |
| Transactions | Machine-speed behavior |
Two inventories of what fraud targets — before, a human was near the transaction; after, authority acts on its own. Columns are parallel, not a row-by-row mapping.
The Objects Are No Longer Hypothetical
When FT3 first named delegated authority as an abuse surface, the objects it described were conceptual. They are not anymore. Each major network has shipped a concrete protocol object that maps directly to a vector under FT3-ABUSE-007:
- Google’s Agent Payments Protocol (AP2) signs intent as W3C Verifiable Credentials, an Intent Mandate (the conditions under which an agent may buy in a human-not-present flow), and a Cart Mandate (the user’s explicit approval of one specific cart). A forged or replayed mandate is a form of forged or replayed authority, not a stolen card. [1]
- Mastercard’s Verifiable Intent (VI) encodes that authority as a layered SD-JWT chain: L1 binds the user identity, L2 expresses the purchase intent, and L3 — present only in autonomous mode — carries the agent’s short-lived, key-bound credential. Each layer is a distinct object that can be over-scoped, escalated, or persisted past its intended scope. [2]
- Stripe’s Agentic Commerce Protocol (ACP) issues a shared payment token scoped to one merchant, one currency, one maximum amount, and an expiry measured in minutes. The allowance constraint is the object, and pooling or stretching it across workflows is the abuse. [3]
- Visa’s Intelligent Commerce binds a tokenized credential to an agent identity under scoped spend controls. The agent’s authority to transact, not the underlying funding source, is what’s exposed. [4]
| Protocol / network | Concrete object shipped | FT3-ABUSE-007 vector |
|---|---|---|
| Google AP2 | Intent / Cart Mandate — signed W3C credential | Forged or replayed mandate |
| Mastercard VI | L1 · L2 · L3 SD-JWT chain — layered authority | Over-scoped, escalated, or persisted |
| Stripe ACP | Shared payment token — merchant + amount + minute expiry | Pooled or stretched authority |
| Visa Intelligent Commerce | Agent-bound token — scoped spend controls | Escalated spend authority |
These are the real-world objects FT3-ABUSE-007 was built to classify. The taxonomy anticipated them before the protocols shipped. The point is this: when forged mandates, over-scoped consent, and persistent-token abuse have names in a protocol spec, defenders need matching names for the abuse.
The Three-Axis Coordinate System
Flat taxonomies struggle here because they force early collapse.
A scoped-token abuse can look like account abuse, authorization fraud, payment fraud, or agentic system abuse, depending on the evidence. The event becomes clear only when the model separates the three questions:
- Tactic
When the behavior occurs in the campaign lifecycle.
- Authorization
Who or what was authorized to act.
- Abuse Family
What object, system, or authority was abused.
That third axis matters because agentic commerce changes not only who acts but also what can be attacked.
(FT3-ABUSE-004 and FT3-ABUSE-007 are example technique ID's)
Delegated Authority as an Abuse Object
FT3 does not bolt on agentic support. It treats delegated authority as a first-class abuse surface.
Under the Abuse Family axis, FT3 identifies the Delegated-authority / mandate grant. This coordinate describes a delegation mandate, scoped consent, or spending authority held by an agent or automated workflow that is forged, over-scoped, escalated, persisted, or pooled.
That lets defenders distinguish between:
- a compromised human account
- an abused session or token
- a manipulated agentic mandate
- an over-scoped delegated authority
- a transaction that was technically authorized but behaviorally abusive
This is an important distinction. If the model cannot separate who acted from what was abused, investigations collapse into generic labels.
“But Scoped Tokens Already Solve This”
The strongest objection to this framing is that the protocols already handle it.
ACP tokens are merchant-scoped, amount-capped, and expire in minutes before routing through Stripe Radar. VI binds every layer to a key. AP2 produces a non-repudiable, cryptographically signed audit trail. If the permission layer is hardened in code, why does it need a fraud taxonomy?
Scoping limits the blast radius of a stolen instrument but does not address the confused deputy.
A confused deputy is a privileged actor tricked by a less-privileged one into misusing the authority it legitimately holds. In agentic commerce, the agent is the deputy. Its token can be perfectly scoped, its mandate chain valid, and the transaction still abusive because the agent’s goal was hijacked by prompt injection, the mandate was manipulated before signing, or the human never intended the specific outcome. The tooling validates the credential but not the intent behind it.
This is not theoretical. Unit 42 has documented agentic shopping flows as highly susceptible to indirect prompt injection, with the Cart Mandate named as a target object. [5] The credential is real. The authorization is valid. The abuse rides inside both.
Scoped tokens shrink the instrument problem but do not close the authority problem. That gap is exactly what FT3-ABUSE-007 names.
FT3 Is the Classification Layer, Not a Competing Standard
It is worth being precise about where FT3 fits.
FIDO, AP2, and Verifiable Intent define how authority is granted: how a user authorizes an agent, how that authorization is signed, and how it is enforced at the protocol layer. FIDO’s new Agentic Authentication working group — seeded by contributions from Google’s AP2 and Mastercard’s VI — is standardizing exactly that grant. [6]
FT3 defines how to classify the abuse when that authority is exploited.
These are complementary layers, not competing ones. Protocol designers built the lock. FT3 gives defenders the language to describe how the lock was picked, bypassed, or handed to the wrong actor, which link in the mandate chain failed, and whether the authority was forged, over-scoped, escalated, persisted, or pooled. A grant standard tells you the authorization was valid. A classification standard tells you why a valid authorization was still abused.
(FT3-ABUSE-004 and FT3-ABUSE-007 are example technique ID's)
The Defender Agenda
As agentic commerce scales, the distance between human intent and machine execution becomes exploitable.
Fraud, CTI, detection engineering, and attacker engineering teams need a machine-readable language that can reason over delegated authority at the protocol layer.
The new detection surface includes:
- Delegation scope lifecycle
Real-time changes to token inheritance, execution boundaries, mandate scope, and authority persistence.
- Mandate authorization chains
Continuity from the originating human or business identity to the agent, workflow, token, and transaction.
- Protocol identity verification
Fingerprinting autonomous actors separately from the user sessions they represent.
- Agent goal integrity
Detection of goal hijacking, prompt injection, catalog manipulation, and context poisoning that causes an agent to act outside its intended scope.
- Cross-agent behavior
Patterns that indicate mandate pooling, delegated authority chaining, or coordinated behavior across agents and workflows.
Agentic commerce does not just create new fraud techniques. It changes the object of fraud.
If agents become customers, fraud does not just get faster.
It changes shape.