Fraud Prevention When the Buyer Is an Agent — Stripe Radar, Adaptive Acceptance, and Agent-Specific Risk Signals.

Auth Passed, Payment Cleared — It's Still Fraud.

Traditional fraud prevention assumes a human at the keyboard. A card-present signal, a behavioral biometric, a CAPTCHA challenge, a 3DS step-up — all of these rely on biological latency and physical context. When the buyer is an agent, those assumptions collapse entirely.

Consider the threat model after a principal has successfully completed OAuth + PKCE authorization: valid access token, authorized scopes, spending limit intact, Stripe payment method on file. The transaction will clear. But the token leaks — intercepted from an insecure agent environment, logged to stdout, stored unencrypted in agent memory, or exfiltrated via prompt injection against the agent's tool chain. The attacker now has everything they need, and standard fraud signals offer nothing useful in response.

Agents do not move a mouse. They do not pause before checkout. They do not produce browser fingerprints, device sensor readings, or human typing cadence. Radar's passive behavioral signals — the ones that catch human fraudsters — produce null or anomalous readings for legitimate agents and fraudulent token replays alike. Worse: agents retry harder than humans. A soft decline that causes a human to abandon checkout becomes a programmatic retry loop. Stripe's Adaptive Acceptance ML was trained predominantly on human patterns; the retry-aggressiveness signal that flags a human fraud attempt may appear as normal agentic behavior.

This is the structural problem: fraud does not disappear when authentication is good. It shifts. The attack surface moves from pre-auth to post-auth. The attacker's goal is no longer to steal credentials — it is to steal or misuse the downstream artifact of successful authentication: the access token, the payment session, the Shared Payment Token.

Post-Auth Attack Taxonomy

Three Radar Tiers — Only One Works for Agent Commerce.

Stripe Radar is trained on data from merchants processing more than $1.9 trillion in payments annually. Stripe reports a 92% probability that any card presented has been seen before on the Stripe network — dense cross-merchant signal that standalone fraud tools cannot replicate. But the base tier gives you ML scoring without the ability to inject the context that makes agent transactions distinct. For agent commerce, Radar for Fraud Teams is the operative tier.

Radar Tier Comparison

Custom Rules Syntax

Radar for Fraud Teams rules follow the structure {action} if {attribute} {operator} {value}. Actions are Block, Review, Allow, and Request 3D Secure.

Standard attributes use single colons: :risk_score:, :amount_in_usd:, :ip_country:, :card_country:, :minutes_since_customer_was_created:. Metadata attributes use double colons: ::agent_token_age_minutes::, ::principal_typical_mcc::, ::is_agent_flow::. Customer metadata: ::[customer:field_name]::. Compound conditions use AND, OR, NOT.

Block if ::is_agent_flow:: = 'true' AND :amount_in_usd: > 50 AND :minutes_since_customer_was_created: < 60

Review if :ip_country: != :card_country: AND ::is_agent_flow:: = 'true'

ML Scoring and Risk Thresholds

Every transaction receives a risk_score from 0 (least risky) to 100 (riskiest). Default thresholds: ≥65 = elevated, ≥75 = highest. These are adjustable in Risk Settings for Fraud Teams accounts. Custom rules can target :risk_score: directly: Block if :risk_score: > 85. The Fraud Teams tier also exposes :bot_score:, :fraudulent_dispute_score:, and :early_fraud_warning_score: as rule attributes.

For agent commerce, consider lowering the elevated threshold from 65 to 60. Agent flows generate no behavioral biometric signal — the absence of those signals artificially deflates the risk score on what may be a fraudulent replay.

Velocity Attributes Built into Radar

How Agents Break the Retry Model.

Stripe's Adaptive Acceptance uses ML to identify false declines and retry them with optimized parameters — message format, routing, postal code normalization — invisibly, before the customer sees the decline. In 2024, Adaptive Acceptance recovered a record $6 billion in falsely declined transactions, a 60% year-over-year increase in retry success rate. Stripe recently migrated from a gradient-boosted XGBoost model to a TabTransformer+ deep neural network architecture, achieving 70% greater precision in identifying legitimate declined transactions.

The Agent-Specific Retry Problem

Adaptive Acceptance's retry signal is tuned on predominantly human behavioral patterns. Legitimate agents retry programmatically — there is no human abandonment signal after a soft decline. Fraudulent token reuse also retries programmatically. From the ML's perspective, both look similar. This creates two concrete operational risks:

1. Over-retry fines. Mastercard allows 35 retry attempts per card per rolling 30-day period; Visa allows 15. Exceeding these can result in fines from acquirers. Agents that implement their own retry logic outside of Stripe's managed flows may inadvertently hit these limits. Use Stripe's Smart Retries rather than raw retry loops.
2. False-negative pressure on fraud detection. The retry-aggressiveness signal that flags a human fraud attempt may appear as normal agentic behavior, reducing Radar's effective detection rate on fraudulent token replays.

Eight Signals Base Radar Cannot See Without Your Metadata.

Spending Cap Probing in Detail

Classic card testing involves running many small transactions across stolen cards to identify which are active. In the agent context the attack adapts: the attacker holds a valid token with a known max_amount embedded in the RAR authorization_details. Rather than probing card validity, they probe for three things:

• Authorization server enforcement boundaries — does the AS actually reject charges above max_amount, or does it pass them through?
• Merchant-side rate limits — how many transactions per hour does the platform allow before triggering a review?
• Risk score calibration — do small transactions below a threshold go through without Radar review?

The signal is a cluster of agent-attributed transactions from the same principal, same card, same time window, all just below either the RAR spending cap or the apparent Radar block threshold. Radar's velocity attribute :authorized_charges_per_email_hourly: will catch high-volume probing. For sophisticated low-velocity probing, the time-window anomaly is the more reliable signal.

Under Visa's VAMP program, even 300,000 combined approved + declined authorization attempts per month can trigger acquirer scrutiny — counts, not just dollar losses, matter. Agent-generated micro-transactions aggregate toward these thresholds faster than human ones.

Required Metadata Fields — Pass on Every Agent Charge

{
  "is_agent_flow": "true",
  "agent_token_age_minutes": "45",
  "principal_home_country": "US",
  "principal_typical_mcc": "5734",
  "spending_cap_usd": "200",
  "rar_reference_id": "txn-ref-abc123",
  "transaction_hour_principal_tz": "14",
  "retry_count": "0"
}

Shrinking the Fraud Blast Radius — RFC 9449 Token Binding.

DPoP (Demonstrating Proof of Possession), standardized as RFC 9449 in September 2023, binds OAuth access and refresh tokens to a public/private key pair held by the client. An attacker who exfiltrates the access token without the matching private key cannot use it — the resource server rejects the DPoP proof verification. For agent commerce, this is the single highest-leverage auth-layer fraud mitigation against token exfiltration.

DPoP Flow for Agent Commerce

The client generates an asymmetric key pair (P-256/ES256). On every token request and every resource request, the client signs a fresh proof JWT containing the HTTP method, endpoint URL, current timestamp (iat), and a jti nonce. The authorization server computes the SHA-256 thumbprint of the public key and embeds it in a cnf claim in the access token. The resource server verifies the DPoP proof on each API call — including the payment call to Stripe's charge endpoint — confirming the presenting client holds the private key matching the bound public key.

Non-extractable key generation is essential: use crypto.subtle.generateKey with extractable: false in browser environments; use hardware-backed secure enclaves in native agent runtimes. A DPoP key pair that can be extracted provides no more security than a bearer token.

Server-issued nonces (RFC 9449 §8) narrow the proof validity window, preventing even millisecond-scale replay of intercepted proofs. Configure your authorization server to issue nonces and require clients to persist the latest DPoP-Nonce response header for subsequent proofs.

OAuth 2.1 and the Model Context Protocol both list sender-constrained tokens — DPoP or mTLS — as recommended hardening for public clients, which now explicitly includes AI agents. FAPI 2.0 (the open-banking security profile) names DPoP as one of two acceptable sender-constraining mechanisms.

RAR + Introspection — Spending Limits the AS Actually Enforces.

Rich Authorization Requests (RFC 9396) allow OAuth clients to embed structured, transaction-level permission details in the authorization request via the authorization_details parameter. For agent commerce, this delivers spending caps, MCC restrictions, single-use authorization references, and location binding — all embedded at token issuance time.

Four RAR Controls for Agent Commerce

Two-Layer Enforcement Architecture

RAR enforcement happens at the authorization server and resource server — not at Stripe. If the merchant's own API does not validate the introspected authorization_details before calling stripe.charges.create(), RAR provides no protection at the payment layer. The two layers must be explicitly wired together.

1. Principal authorizes via OAuth + PKCE + RAR:
   authorization_details = {
     "type": "agent_purchase",
     "max_amount": 200,
     "currency": "USD",
     "allowed_mcc": ["5734"],
     "single_use_ref": "txn-ref-abc123"
   }

2. Agent calls merchant API with access token + DPoP proof.

3. Merchant RS introspects token → extracts authorization_details:
   - Validates: amount <= max_amount (200)
   - Validates: requested MCC in allowed_mcc (["5734"])
   - Validates: single_use_ref not in consumed-ref registry
   - Marks single_use_ref as consumed atomically

4. Merchant passes authorization_details as Stripe charge metadata:
   metadata = {
     "is_agent_flow": "true",
     "rar_max_amount": "200",
     "rar_allowed_mcc": "5734",
     "rar_reference_id": "txn-ref-abc123",
     "agent_token_age_minutes": "38"
   }

5. Stripe Radar rules fire against that metadata — second enforcement layer.
   If merchant API has a logic error and passes a charge above max_amount,
   Radar catches it here before it clears.

Agent-Initiated Purchases — The Merchant Bears the Liability.

Standard card network chargeback rules apply to agent-initiated purchases. Stripe does not currently carve out a separate liability regime for agent commerce. (Re-verify before launch: Stripe's Agentic Commerce Protocol (ACP) and Shared Payment Token (SPT) documentation does not explicitly address chargeback liability allocation as of this writing.)

Current Liability Framework

Under Visa and Mastercard rules, a Visa 10.4 or Mastercard 4837 chargeback reason code — "No Cardholder Authorization" — is the primary vector for fraud disputes. The issuing bank credits the cardholder and debits the merchant. Stripe charges a $15 dispute fee per chargeback on US cards (re-verify; fee structures vary by country and account type).

For agent-initiated purchases, the merchant must demonstrate valid principal authorization at the time of purchase, plus proof the transaction was initiated by a party the cardholder authorized. Without the artifacts below, the chargeback will succeed and the merchant absorbs the loss.

Merchant Defense Evidence Package

Platform-Breach Liability

Atomic Transaction Evidence Record — Schema

{
  "stripe_charge_id": "ch_3Px...",
  "stripe_customer_id": "cus_...",
  "oauth_grant_id": "grant_abc123",
  "rar_reference_id": "txn-ref-abc123",
  "token_issued_at": "2026-06-03T14:22:00Z",
  "principal_id": "user_xyz",
  "amount_cents": 4999,
  "currency": "usd",
  "mcc": "5734",
  "agent_platform_id": "platform_abc",
  "dpop_jkt": "sha256_thumbprint_of_public_key",
  "radar_risk_score": 28,
  "charge_timestamp": "2026-06-03T14:23:18Z",
  "retain_until": "2028-01-01T00:00:00Z"
}

Five Complete Rules for Agent Commerce.

All rules below assume you pass the metadata payload from §4 on every agent-initiated charge. All rules are complete and deployable — no truncation. Start every rule in Review mode and backtest against six months of data before switching any to Block.

Rule 1 — Block New Token + High Amount + MCC Mismatch (Composite Risk)

Block if ::is_agent_flow:: = 'true'
  AND ::agent_token_age_minutes:: < 60
  AND :amount_in_usd: > 50
  AND NOT (::principal_typical_mcc:: = :mcc:)

Catches: freshly leaked token being rushed into use in the wrong merchant category before the principal notices. The composite condition (all three must be true) dramatically reduces false positives — a legitimate agent will rarely have a brand-new token, a high transaction, AND a category mismatch simultaneously.

Rule 2 — Flag Spending Cap Probing

Review if ::is_agent_flow:: = 'true'
  AND :authorized_charges_per_email_hourly: > 5
  AND :amount_in_usd: < 10

Catches: micro-transaction probing pattern against the enforcement boundary. Five successful sub-$10 charges from the same principal email within one hour is an unusual cluster for legitimate agent workflows.

Rule 3 — Flag Cross-Border Anomaly on Agent Traffic

Review if ::is_agent_flow:: = 'true'
  AND :ip_country: != ::principal_home_country::

Catches: token reuse from attacker infrastructure in a different country from the principal's registered home country. Pass principal_home_country as ISO alpha-2 from your principal profile at charge time.

Rule 4 — Flag Late-Night Agent Transactions

Review if ::is_agent_flow:: = 'true'
  AND ::transaction_hour_principal_tz:: < 4

Catches: transactions between midnight and 4 AM in the principal's local timezone — unlikely to be principal-scheduled legitimate workflows. Compute the principal's local hour server-side before the Stripe call and pass it as transaction_hour_principal_tz (integer 0–23).

Rule 5 — Flag New Payment Instrument Used Immediately in Agent Flow

Review if ::is_agent_flow:: = 'true'
  AND :minutes_since_per_payment_instrument_fingerprint_first_seen: < 1440

Catches: newly added card (less than 24 hours since Stripe first saw the card fingerprint across its network) being immediately used via agent. This is the card-on-file compromise pattern — attacker adds a stolen card to the principal's account and routes the agent to use it before the principal notices.

How This Plugs Into OAuth + RAR + DPoP + Agents Page.

Fraud prevention does not stand alone. Each layer in the agent-ready commerce architecture catches a different slice of the threat model. The table below maps what this spoke owns versus what the OAuth spoke and the Agents Page spoke own.

4-Layer Agent-Ready Model Integration

The 4-Layer Agent-Ready Model — Structured Data → API Endpoint → MCP Tool Description → UCP Compatibility — intersects with fraud prevention at each layer:

• Structured Data layer: Product catalog + pricing metadata must include MCC codes and authorization policy fields that agents can read before initiating a purchase, enabling pre-purchase authorization checks and reducing MCC-drift fraud.
• API Endpoint layer: The payment endpoint is where Stripe metadata gets attached and Radar rules fire. Instrument here. RAR introspection validation belongs here too.
• MCP Tool Description layer: MCP tool schemas should declare expected spending ranges and merchant categories so agents can surface these to principals for upfront consent, reducing post-purchase disputes.
• UCP Compatibility layer: UCP compatibility signals include fraud policy declarations — refund policy, dispute process, authorization scope requirements — that honest agents use for routing and that fraud detection systems can validate against post-transaction.

Eight ways agent fraud prevention breaks in production.

1. Relying on Stripe's base Radar ML without custom rules

The base ML tier has no mechanism for agent-specific signals. It cannot know the token was issued 45 minutes ago, or that the principal's typical MCC is 5734, unless you pass that data. Without Fraud Teams and custom metadata rules, Radar treats agent transactions as unusual-but-unclassified CNP traffic and will miss the most dangerous attack vectors. Fix: upgrade to Radar for Fraud Teams. Pass is_agent_flow, agent_token_age_minutes, principal_typical_mcc, and principal_home_country on every agent-initiated charge.

2. Passing RAR authorization_details to the AS but not forwarding enforced parameters to Stripe

Operators often implement RAR at the OAuth layer (good) but then call stripe.charges.create() without propagating the max_amount or MCC constraints as metadata. Radar has no visibility into what the AS authorized. The two layers are disconnected. Fix: at the merchant API layer, extract authorization_details from the introspection response and attach the relevant fields as Stripe charge metadata before the payment call.

3. Not logging OAuth grant artifacts at charge time

Fraud happens. When a chargeback arrives, you need the OAuth grant timestamp, the token's sub claim, the RAR authorization_details, and the Stripe charge ID — all linked to the same transaction record. If you log these separately, you may not be able to reconstruct the chain in time to contest the dispute. Fix: at charge creation time, write a single atomic record linking all of these identifiers to durable storage.

4. Using DPoP without server-side nonce enforcement

DPoP without nonces is vulnerable to replay within the proof's validity window (typically a few minutes). An attacker who intercepts a DPoP proof in transit can replay it within that window. Fix: configure your authorization server to require DPoP nonces per RFC 9449 §8. Clients should persist the latest nonce from the server's DPoP-Nonce response header and include it in subsequent proofs.

5. Not backtesting Radar rules before enabling Block action

A rule like Block if :ip_country: != ::principal_home_country:: will block every principal who travels or uses a VPN. Running it in Block mode without a backtest will produce false positives at scale. Fix: enable all new rules in Review mode first. Backtest against the last six months of transactions using Radar's backtest interface. Graduate to Block only after confirming the false positive rate is acceptable.

6. Treating agent velocity the same as human velocity

An agent that legitimately processes 50 transactions per hour for a principal running a bulk-purchasing workflow will trigger standard hourly velocity rules calibrated for human shoppers. Fix: tier your velocity rules by agent type. Pass a principal_authorized_tps metadata field reflecting the RAR-authorized transaction rate. Write Radar rules that allow higher velocity for principals who explicitly authorized high-rate workflows.

7. Assuming a soft decline means no fraud

Agents retry soft declines programmatically. Stripe's Smart Retries and Adaptive Acceptance will attempt to recover the transaction. A fraudulent token that generates a soft decline on the first attempt may succeed on retry. Fix: write a Radar rule that places an agent-attributed charge in Review after a first soft decline within the same session. Pass a retry_count metadata field incremented by your application and escalate disposition when ::retry_count:: > 1.

8. No principal notification on agent purchase completion

Even with perfect fraud controls, principals may not recognize legitimate purchases the agent made on their behalf — leading to first-party chargebacks (friendly fraud). Fix: send a push notification or email to the principal for every agent-completed purchase above a threshold (e.g., $25). Include item description, amount, timestamp, and a dispute-prevention link. This alone reduces first-party chargeback rates materially.

Frequently asked questions.

The 30-day rollout, in five steps.

Each step mirrors the HowTo JSON-LD at the top of this page word for word.

Step 1 — Instrument every agent-initiated charge with structured metadata

Before any rules can work, Stripe needs the context. Add the following fields to every stripe.paymentIntents.create() or stripe.charges.create() call on your agent-originated payment path: is_agent_flow (string 'true'), agent_token_age_minutes (integer minutes since OAuth grant was issued), principal_home_country (ISO alpha-2 from principal profile), principal_typical_mcc (comma-separated MCC list from authorization history), transaction_hour_principal_tz (0–23 integer, principal's local time), and rar_reference_id (the unique reference from RAR authorization_details). This is the foundation all downstream rules depend on.

Step 2 — Upgrade to Radar for Fraud Teams and configure risk thresholds

Navigate to the Radar settings in the Stripe Dashboard. Enable Radar for Fraud Teams (re-verify pricing at stripe.com/radar/pricing). Set your base risk threshold — for agent commerce, consider lowering the elevated threshold from 65 to 60 given the absence of behavioral biometric signal on agent traffic. Select the risk setting ("conservative," "balanced," or "aggressive") that aligns with your acceptable false positive rate. Enable early fraud warnings.

Step 3 — Deploy the compound agent fraud rules in Review mode, then backtest

Add each rule from Section 8 of this document starting with Review (not Block) disposition. Use Radar's backtest feature to see how the rules would have performed against the last six months of your transaction data. Identify the false positive rate for each rule. Rules with >1% false positive rate on known-legitimate traffic need threshold adjustment before graduating to Block. Use Stripe Sigma to cross-reference disputed transactions against the rules that would have caught them to measure true positive rates.

Step 4 — Implement DPoP on your authorization server for agent client registrations

Require DPoP for all OAuth clients registered as agent runtimes. Generate ES256 key pairs in hardware-backed secure storage (non-extractable). Enforce server nonces (RFC 9449 Section 8). Propagate the DPoP JWK thumbprint to your transaction logging layer so it can be included in chargeback evidence. Update your token introspection response to include the cnf claim so resource servers can verify binding. Cross-reference /agentmall_spoke_oauth for AS configuration specifics.

Step 5 — Build a durable transaction evidence record and principal notification flow

At the moment each agent-initiated charge is confirmed by Stripe (on payment_intent.succeeded webhook), write an immutable record containing: stripe_charge_id, stripe_customer_id, oauth_grant_id, rar_reference_id, token_issued_at (from introspection), principal_id, amount_cents, currency, mcc, agent_platform_id, dpop_jkt (if DPoP implemented), radar_risk_score, and charge_timestamp. Simultaneously dispatch a push/email notification to the principal with charge details and a one-click dispute flag. This evidence package is your chargeback defense and your principal-trust mechanism. Retain for a minimum of 18 months (chargebacks can arrive up to 120 days post-transaction; arbitration extends this further).

The complete trust layer.