Fraud and Authorisation in Agent Transactions: Bot or Authorised Agent?

How did the fraud question change for agent transactions?

In agent transactions the fraud question is no longer "is this card stolen" but "on whose behalf and with what authority is this agent acting". In classic e-commerce fraud the attacker was a person: they placed an order with someone else's card, the goods shipped, the cardholder disputed it with the bank, and the chargeback was billed to the merchant. That risk has not gone away; a new layer sits on top of it. There is now software that prepares the basket, triggers the payment and sometimes passes through checkout on your own site, and both its identity and its authority have to be verified separately.

This article is the January 2020 fraud control guide rewritten for the agent era. The classic defences against card fraud stay in place; the added layer is agent identity, mandates and the chain of accountability. Our thesis at Webtures: in the agent era the security question is not how to close access but how to recognise the legitimate agent and bound its authority; a store that blocks every bot blocks its own customers too.

How is agent identity verified?

The way to know who is behind a request is not the user agent string but a cryptographic signature. Web Bot Auth, led by Cloudflare and at IETF draft stage, has the agent sign its requests with Ed25519 and publish its verification key at a well-known address, so the server proves identity instead of guessing it. Cloudflare brought it into its verified bots programme in July 2025; the Anthropic, OpenAI and Perplexity agents sign their traffic, and AWS WAF, Vercel, Shopify and Akamai added support.

The practical consequence: a "only verified agents pass" policy is now technically possible. Applying it alone today is risky, because legitimate crawlers that do not sign yet still exist. The right setup is graduated: an open path for signed agents, permission for unsigned but known search bots, and rate limits for undefined heavy traffic. The mistake we see most often is the opposite: the firewall blocks a legitimate search or fetch bot and the brand quietly drops out of the agent ecosystem.

What does a mandate do on the payment side?

Identity answers "who", the mandate answers "what was allowed". AP2, which Google announced in September 2025 with more than 60 partners, defines three signed documents carried as W3C verifiable credentials:

• Intent Mandate: the user's intent and its limits. "You may buy from this category, up to this budget, until this date."
• Cart Mandate: the immutable final record of product and price. What the agent showed in the basket and what goes to payment must be the same.
• Payment Mandate: the signed record of the payment step, the document the network and the bank can audit.

The card networks fill that envelope on their own rails. Visa's Trusted Agent Protocol treats the agent as a constrained intermediary, Mastercard's Agent Pay as a delegated token holder. Both are identity-verification frameworks designed to anchor where liability sits. What changes for the merchant is what it can show in a chargeback: a signed Intent Mandate proves the scope of the purchase was authorised, a Payment Mandate that the payment fell within that scope. The argument shifts from "was this transaction authorised" to "was the authorisation well specified".

How do you set up fraud control for the agent era?

1. Keep the classic layer. Card verification, address mismatch, velocity rules, thresholds for high-risk categories and amounts, blocklists. The agent layer does not replace these; it sits on top.
2. Recognise the legitimate agent. Write a rule that validates the Web Bot Auth signature; apply a separate rate limit and logging for signed agents. Do not block a verified agent like ordinary bot traffic.
3. Validate the mandate. In an AP2-enabled flow check the signature, scope and validity period of the Intent and Cart Mandates; reject transactions outside scope and log the rejection.
4. Lock the basket to the payment. The product, quantity and price shown in the Cart Mandate must match the payment request exactly; any difference stops the transaction.
5. Define an approval threshold. Up to what amount may an agent transact without human approval? Our assessment set asks this directly: a written approval and authority matrix by transaction type, with monetary and unit ceilings.
6. Write and test the rollback procedure. Cancellation, refund and correction steps for a faulty agent transaction should be written down and tested at least once.
7. Record the chain of accountability. Which transaction was made by which agent, under which authority, at what time? Without logs there is nothing to show in a chargeback.
8. Write anomaly rules around agent behaviour. Agent traffic does not look like human traffic: fast, repetitive, at odd hours, many pages in one session. Classic velocity rules can block a legitimate agent by mistake.

What are the most common mistakes?

• Blocking every bot. A blanket block in the firewall also closes search and fetch bots, and the brand drops out of agent recommendations. That can cost more revenue than the fraud it prevents.
• Trusting the user agent string. It is trivially spoofed; without signature validation, "ChatGPT came" is a guess.
• Leaving authority for later. Opening an agent integration and postponing "what may it do" is like leaving the admin panel without a password.
• No approval threshold. An agent with unlimited authority can open a large transaction on one faulty prompt.
• Keeping no logs. If signed mandates are not stored, no evidence can be produced in a dispute.
• Treating agent traffic as a fraud signal. High-speed, repetitive access alone is not evidence of fraud; it should be read together with signature and mandate context.

What changes for cross-border brands?

Cross-border selling adds three topics. First, payment infrastructure: if you will accept agent payments, ask whether your payment provider supports the AP2 envelope and the card networks' agent protocols. Second, law: consumer rights, withdrawal periods and where liability sits in an agent transaction differ by target market; in our assessment set this is the question of whether target-market regulation is being tracked. Third, operations: has fulfilment and fraud team capacity been tested against a sudden agent-driven spike in orders?

In our own export matrix, agent procurement in B2B-heavy markets such as Germany runs through APIs and the authority matrix is part of the contract; in B2C markets such as the United States and the United Kingdom the card network protocols decide. In the Gulf, agent payment is still early, but a brand that builds the identity verification layer now will be ready in the first wave.

You can find where the trust and payment layer sits in the protocol map and how your site opens to agents in the protocol-ready web guide; the measurement side of agent traffic is in dark AI traffic. You can assess your authority matrix and agent access policy with the Agentic Commerce Readiness scan and test whether your firewall blocks legitimate agents with our Agent Experience team.