Agentic Fraud: Fraud by Agents, and Fraud Against Agent Commerce

A shopping agent that has bought groceries once a week for three months suddenly tries to buy six gift cards in four minutes, from a merchant it has never used. Is that fraud? If a person did it, a fraud model would see a new device, an odd hour, a fast checkout. With an agent, the device is a server, every checkout is fast, and the hour means nothing.

The useful question is different: is this agent behaving like itself? Answering that needs a per-agent history, and a view of the last few minutes that is current when the payment is authorized.

This page separates the two kinds of agentic fraud, explains why existing signals degrade, and shows how to build per-agent baselines that hold up when agents act in bursts.

What Is Agentic Fraud?

Agentic fraud is fraud that involves AI agents on either side of a transaction. It includes fraud run by agents, where attackers use autonomous AI to scale scams, bots and fake merchants, and fraud against agent commerce, where legitimate shopping or payment agents are deceived, hijacked or used as a pretext to dispute genuine purchases.

The distinction matters because the defenses differ. Fraud by agents is an attacker productivity problem. Fraud against agent commerce is a new attack surface: a delegated buyer that can be lied to, and a new excuse for disputes.

Fraud by Agents

Visa described the first kind in a November 2025 article on agentic commerce threats. Visa’s PERC team identified “a more than 450% increase in dark web community posts in underground channels mentioning ’AI Agent’” over six months compared with the prior six, in a PERC analysis the article dates June 2025. Citing Visa Account Attack Intelligence, the article also says Visa “saw a 25% increase in malicious bot-initiated transactions over the past 6 months, with the US experiencing a 40% increase.”

The same article describes what agents do for attackers: “automating workflows necessary to design and deploy scams, tailoring social engineering tactics, and rapidly creating convincing criminal infrastructures.” It also describes a network of scam sites that each ran a conversational AI agent posing as customer support, which could “dissuade victims from contacting their bank,” keeping them engaged “over days or weeks.”

For a fraud team, fraud by agents mostly looks like familiar attacks run faster and more convincingly: card testing, account takeover, synthetic merchants, scams. Existing controls still apply. They have to keep up with volume.

Fraud Against Agent Commerce

The second kind targets legitimate agents.

Counterfeit merchants built for agents. Visa’s article describes storefronts “engineered specifically to exploit” shopping agents. Such a storefront may “pass automated security checks, and offer prices far below market rate. Then, once the AI agent completes the purchase using stored credentials, the malicious merchant can harvest payment data.”

Injected instructions. An agent that reads web pages can be steered by text hidden in them. In August 2025, Brave disclosed an indirect prompt injection vulnerability in Perplexity’s Comet browser agent. In its proof of concept, instructions hidden behind a spoiler tag in a Reddit comment ran when the user asked Comet to summarize the page: the agent found the user’s email address, requested a one-time password, read it from the user’s logged-in Gmail and posted both in a reply to the comment.

Stolen agent credentials. An agent’s keys or tokens are a credential like any other. Whoever holds them transacts as the agent.

Disputes using the agent as cover. A user disputes a purchase their agent made correctly, claiming the agent went rogue. Worldpay calls this “friendly fraud with a new excuse.” See agentic chargebacks for the dispute side.

In the first three, the agent passing an identity check is not the end of the question. A legitimate, verified agent can be the one making the bad purchase. That is why Know Your Agent has to be followed by limits and behavior checks.

Why Card-Not-Present Signals Degrade

Worldpay’s article describes the shift: “Payments fraud has spent fifteen years answering one question: Are you trustworthy? Device metadata, behavioral biometrics, typing speed, mouse movement – all of it built to catch a human pretending to be someone else.” With an agent, those signals “are becoming less effective or disappearing altogether.”

Several standard features change meaning when the buyer is an agent:

Networks are adding agent-specific signals. Mastercard announced in 2026 “a probability score indicating the likelihood that a transaction was initiated by an AI agent.” That tells an issuer how likely it is that an agent is involved. It does not tell anyone whether this agent is acting normally.

Don’t Decline the Good Agents

Controls built to stop bots now meet bots that are customers. Worldpay’s guide for merchants, republished from Ravelin, warns: “If you – or your fraud prevention partner – don’t adapt your e-commerce fraud strategy, you are likely to see a substantial rise in blocked false positives.” Legacy tools, it explains, are likely to flag shopping agents as bots. The same article is clear that most of the toolkit survives: “An estimated 80% of fraud signals will remain the same,” and it lists billing and delivery address, card velocity checks, location data and consortium data among the features that still help.

Signed agent traffic gives merchants a way to stop treating every agent as an attacker. Visa’s Trusted Agent Protocol and Mastercard Agent Pay both use Web Bot Auth, in which an agent signs each request with a key registered in the network’s directory, per Cloudflare. A merchant can let a signed, registered agent past its bot defenses and send unsigned automation to the usual checks. Know Your Agent covers how the signatures work.

Letting an agent in is not approving its purchase. A registered agent can still be hijacked or out of pattern, which is why the next check compares it with itself.

New Keys for an Agent: Identity, Token and Intent

A per-agent baseline needs a stable key: you can only compare an agent with itself if you recognize it next time. The device fingerprint used to play that role for people. Three newer identifiers can play it for agents.

Agent identity. A Web Bot Auth signature names the agent’s registered key, its keyid, on every request.

Agent payment tokens. Under Visa’s April 2026 rules, an agentic payment provider using a stored credential must obtain a token directly from Visa or an Agentic Payment Enabler, and may not aggregate several agent purchases into a single transaction, so each purchase is its own transaction.

Intent identifiers. American Express’s Intent Intelligence framework is built around a Create Intent API, an Intent ID and a Proof of Intent Token, which tie a purchase to the instruction behind it.

Key the baseline on these, not on a device. Mastercard’s score says an agent is probably involved; these identifiers say which agent, and under which instruction.

Per-Agent Baselines: Compare the Agent With Itself

The signal that survives is the agent’s own history. A per-agent baseline holds, for each agent and mandate, what normal looks like:

Purchase rate. Purchases per hour and per day, and the burst size it normally reaches.

Ticket size. The usual range, and how far this purchase sits from it.

Merchant set. Merchants it has used before; the share of first-time merchants.

Category mix. Groceries agents rarely buy gift cards.

Retry pattern. How often it repeats the same order after a failure.

Each purchase is then scored on the gap between the last few minutes and the baseline. A grocery agent placing its sixth gift-card order in four minutes, at a merchant created last week, is out of pattern on four features at once, whatever its identity check said.

The two halves have different freshness needs. The baseline is stable: a 30-day profile can be recomputed every few minutes or every hour without losing anything. The recent window cannot lag. An agent that has been hijacked acts in bursts, and a velocity count refreshed every five minutes lets a five-minute burst through untouched.

A Worked Failure: A Burst Inside the Refresh Interval

The numbers below are illustrative.

A fintech issues virtual cards to customers’ shopping agents. Its fraud service reads per-agent velocity from a feature store refreshed every five minutes by a streaming job, and declines when an agent exceeds three purchases in ten minutes or a single ticket exceeds five times the agent’s median.

At 13:00:10 an agent reads a product page carrying injected instructions and begins buying $200 gift cards. Its median ticket is $45, so each purchase sits just under the ticket rule. The feature store shows zero purchases in the last ten minutes, because its last refresh ran at 13:00:00.

Between 13:00:30 and 13:04:30 the agent completes nine purchases at three storefronts. Each authorization reads the same velocity count: zero.

At 13:05:00 the refresh runs and the velocity feature reads nine. By then $1,800 is gone.

Every rule was reasonable. The velocity rule never saw the burst it was written for.

Computing the Recent Window at Authorization

The fix is to compute the recent window on demand against committed payment events, and join it to the precomputed baseline, inside the authorization.

-- Run inside the authorization; :agent_id, :merchant_id, :amount from the request.
WITH recent AS (
  SELECT count(*)                              AS purchases_10m,
         count(DISTINCT merchant_id)           AS merchants_10m,
         coalesce(sum(amount), 0)              AS spend_10m
  FROM   agent_payments
  WHERE  agent_id   = :agent_id
    AND  status NOT IN ('declined', 'voided')     -- pending, authorized or settled
    AND  created_at > now() - interval '10 minutes'
),
merchant_seen AS (
  SELECT EXISTS (
    SELECT 1 FROM agent_payments
    WHERE  agent_id = :agent_id AND merchant_id = :merchant_id
      AND  status NOT IN ('declined', 'voided')
      AND  created_at < now() - interval '1 day'
  ) AS known_merchant
)
SELECT r.purchases_10m,
       r.merchants_10m,
       r.spend_10m,
       m.known_merchant,
       :amount / NULLIF(b.median_ticket, 0) AS ticket_ratio,  -- NULL until a baseline exists
       b.p95_purchases_per_hour
FROM   recent r
CROSS  JOIN merchant_seen m
LEFT   JOIN agent_baselines b ON b.agent_id = :agent_id;

agent_baselines can be a view or table refreshed on a schedule; it is allowed to lag, and the LEFT JOIN keeps a new agent with no baseline from dropping out of the check. recent must include every payment committed before this one, whatever its settlement stage. Counting pending payments matters: in a burst, most of the agent’s purchases have not settled yet.

A read on its own does not stop two purchases from the same agent that arrive at the same instant: each reads the window before the other has committed. If one agent can send concurrent authorizations, run the check in a transaction that first locks a per-agent row (SELECT 1 FROM agent_limits WHERE agent_id = :agent_id FOR UPDATE), then runs the window query, then inserts this payment as pending. Under PostgreSQL’s READ COMMITTED, each statement takes a new snapshot, so a purchase that waited on the lock counts the one ahead of it.

If you run this at low volume on Postgres with an index on (agent_id, created_at), it works, and you should start there. It gets harder as agent volume grows: the window query runs on every authorization while every agent is inserting into the same table, the baseline lives in a different system from the events, and the fraud service, the limit check and the dispute log each keep their own copy of “recent activity,” refreshed at different moments. That divergence is how one service approves what another would have declined.

Where Tacnode Fits

The Tacnode Context Lake™ gives the authorization accurate context. Payment events from your ledger or processor arrive by change data capture or a stream and land in Tacnode alongside the baselines. The recent window is computed on demand against the latest ingested events, and when the authorization service also writes each decision there, the window counts its own approvals before the processor’s events arrive. The baseline is an incremental view refreshed on a schedule you set in SQL, typically every few seconds, so each feature gets the freshness it needs, from one system and one snapshot. The fraud service, the limit check and the dispute log read the same state instead of three copies. The authorization itself still happens where it does today; Tacnode enforces nothing inside a card network’s, issuer’s, processor’s or merchant’s ledger.

The decision’s own output is state you own. Per-agent limits, holds placed on a suspicious agent and decision records held in Tacnode are covered by full ACID transactions, so a hold written by the fraud service is visible to the next authorization for that agent. That closes the context gap for agent payments the same way it does for real-time fraud detection on human traffic. For how limits are modeled, see agent spend limits.

FAQ