E-commerce’s entire anti-fraud infrastructure rests on one assumption: a human is behind the session. Browser fingerprinting, behavioral biometrics, 3-D Secure, and CAPTCHAs fail by design against a software agent, which produces none of the expected signals. Blocking all bots indiscriminately also shuts out legitimate shopping agents, along with the revenue they bring.
> 1B
HTTP 402 responses sent every day by sites behind Cloudflare to bots and crawlers
Cloudflare, 2026
77 %
of companies deploying AI have no agent-specific security policy
Industry studies cited by Sumsub/PYMNTS, 2026
⚠️
Three questions, three workstreams
The first workstream is identification: establishing which agent the requests come from. The second is the mandate: stating what that agent is allowed to do. The third is accountability: determining who is responsible when the transaction is disputed. Each agentic protocol answers these three questions only in part.
The Amazon v. Perplexity dispute (2025–2026) illustrates the first workstream: the Comet agent presented itself as an ordinary Chrome browser. The judge found that this access, even when directed by the user, took place “without authorization” from the site. The ruling weakens the legal footing of stealth agents and favors agents that are declared and signed.
Identifying an agent: signatures and credentials
Web Bot Auth, now going through standardization at the IETF, is the basic identification layer. The agent cryptographically signs its HTTP requests with a private key and publishes the matching public key in a directory. The merchant, or its CDN, verifies the signature and determines which agent sent the request. Visa (Trusted Agent Protocol, October 2025) and Mastercard (Agent Pay) both use it as their authentication layer, with Cloudflare as the third-party verifier.
Signed agent request (simplified HTTP headers, Web Bot Auth style)
Verifying an agent at the merchant site’s front door
AI agent
Sends a signed request
Signature + agent ID + intent (browse or pay)
➜
CDN / WAF
Verifies the signature
Public key looked up in the directory of registered agents (networks, Cloudflare)
➜
Merchant
Applies its policy
Allows, restricts (read-only), or blocks, depending on the agent and its declared intent
➜
Payment network
Links the agent to the consumer
The registered agent is tied to a cardholder identity and a payment token
HTTP signatures: prove where each request comes from, and can be revoked instantly if the agent is compromised.
Verifiable Credentials (W3C): signed, portable attestations such as “this agent belongs to provider X” or “this agent acts for verified user Y.” AP2 uses them for its mandates.
Agent directories: registries run by the networks (Visa, Mastercard) and by infrastructure providers (Cloudflare), which act as trust authorities.
ℹ️
Identification ≠ reputation
Identification establishes which agent sent the request, but says nothing about whether it behaves properly. Mature setups therefore add per-agent behavior scoring, based on dispute rate, adherence to scope, and velocity, much like the scoring that exists today for merchants and cardholders.
Advertisements
Mandates and limits: what the human actually authorized
In AP2, a mandate is a signed, tamper-proof, timestamped object that records the authorization a human gave. Three mandates chain together during a purchase. Together they form a complete cryptographic audit trail, from the stated need to the executed payment.
📝
Intent Mandate
Captures the task and its boundaries: “buy tickets for this concert, €150 budget, before Friday.” Signed by the user, it lets the agent search, even when the user is not present.
🛒
Cart Mandate
Locks in the exact cart (items, prices, currency), approved in real time by the human, or automatically if the Intent Mandate allows it. What the merchant charges is exactly what was signed.
💳
Payment Mandate
Passed to the payment rail, it proves to the issuer and the network that an agent is involved and that the transaction matches a valid mandate. Risk scoring can then be adjusted.
Parameter
Example
Role
Per-transaction limit
€100 per transaction
Caps exposure if the agent runs out of control
Cumulative limit
€300 per week
Contains drift over the life of the mandate
Merchant scope
“Electronics” category, allowlist of sites
Blocks off-topic purchases
Expiration
72 hours
A mandate with no end date is a security hole
Approval mode
Automatic under €50, human confirmation above
Balances convenience and control (“human present” vs. “human not present”)
Revocability
Immediate revocation in the app
The cardholder must be able to cancel the mandate the way they would block a card
Typical settings for a purchase mandate
🔑
The mandate is the new consent
In Europe, the signed mandate fits the logic of PSD2, acting as strong customer authentication delegated over time. The closest parallel is the exemptions for recurring payments and trusted beneficiaries. In 2026, regulators (the EBA, the Banque de France) are examining how these mandates fit with SCA, and the final framework has yet to be written.
Delegated tokens: the networks’ answer
On card rails, the agentic network token is a variant of the standard network token used by Apple Pay and click-to-pay. It is bound to an agent rather than to a device. Mastercard calls it Agentic Tokens, and Visa issues it through Intelligent Commerce. The agent never holds the PAN. It presents a narrowly scoped token along with the mandate.
Visa
Mastercard
Framework
Intelligent Commerce (Apr. 30, 2025)
Agent Pay (Apr. 29, 2025)
Agent identification
Trusted Agent Protocol (Oct. 14, 2025), co-designed with Cloudflare, public specifications
Web Bot Auth + registry of verified agents
Instrument
Agent-specific payment tokens tied to the cardholder
Agentic transaction pilots in 2025; stablecoin settlement at a $7B annualized run rate (Apr. 2026)
First live agentic transaction on Sept. 29, 2025; Agent Suite in Q2 2026
Visa vs. Mastercard on agentic commerce (as of July 2026)
The issuer benefits directly. A transaction carried by an agentic token and a signed mandate is richer in context than a standard e-commerce payment. Fraud scoring can check that the amount matches the mandate, that the agent is registered, and that the merchant falls within the authorized scope. These checks let issuers approve transactions that a fraud engine would once have declined as “bot behavior.”
KYA: Know Your Agent
KYA (Know Your Agent) means verifying an agent’s identity, ownership, and permissions on an ongoing basis. The discipline took shape in 2025–2026, modeled on KYC (Know Your Customer). Verification cannot stop at enrollment, because an agent is software: it gets updated, switches underlying models, and can be compromised overnight.
🆔
Identity
Verification covers the agent, its provider, its model, and its version, all tied to a persistent identifier and cryptographic keys.
👥
Link to a human
The agent acts on behalf of an identified user who has passed KYC. This agent-human link is the precondition for any accountability, so much so that some already talk about “Know Your Human.”
🎚️
Permissions
The exact scope of the mandate: amounts, merchants, categories, duration. Checked on every transaction, not just when it is granted.
🔁
Continuity
Monitoring behavior over time: drift, abnormal velocity, disputes. Trust is recalculated continuously.
For PSPs and acquirers: KYA is becoming an onboarding requirement, because accepting payments from an unknown agent means accepting an undocumented risk.
For issuers: combining KYA with the mandate makes it possible to automate approvals without a surge in fraud.
For merchants: a list of trusted agents, just as lists of approved bots exist for SEO.
ℹ️
No regulation requires KYA as such yet (as of mid-2026). Existing AML requirements still apply, and any institution processing an agent-initiated payment must still know on whose behalf the money is moving.
Advertisements
Liability: who pays when the agent gets it wrong?
The question of who bears the loss arises as soon as an agent buys 12 tickets instead of 2, or orders from a fraudulent merchant. General agency law applies as a starting point: the principal is liable for the acts of its agent. How liability is then split among the user, the agent provider, the merchant, and the bank depends on what failed.
Scenario
Failure
Likely liable party
The agent exceeds the mandate’s limit
Agent bug or hallucination
The agent provider (the deviation from the signed mandate can be proven cryptographically)
The human disputes a purchase that complied with the mandate
Buyer’s remorse
The user: the signed mandate protects the merchant as proof of authorization
Mandate obtained through manipulation (prompt injection, booby-trapped page)
Agent security
The agent provider, or even the attacking site; a gray area if the user ignored safeguards
The merchant delivers a nonconforming product
Standard commercial dispute
The merchant (the cardholder’s dispute and chargeback rights remain)
Agent token stolen and replayed
Technical compromise
Depends on the compromised link: agent provider, wallet, or network (allocation rules still being defined)
Dispute scenarios and likely liability (analysis, as of 2026)
⚠️
Lawmakers have started to rule
In California, AB 316, in force since January 2026, explicitly bars the defense that “the AI acted autonomously.” Whoever deploys the agent is liable for its acts as the principal. In Europe, how PSD2 and PSD3 apply, specifically the line between an “authorized” and an unauthorized transaction, is still under discussion in 2026, as is the future AI liability regime.
Payments professionals should adopt one habit right away: archive mandates. In an agentic dispute, the signed mandate and the AP2 audit trail play the role that 3-D Secure evidence plays today in allocating liability between issuer and acquirer.
New fraud vectors
Every trust layer added to the agentic chain opens a new attack surface. The first fraud patterns specific to agents were documented in 2025–2026. They target the agent itself, its declared identity, its mandate, or the merchants it visits.
💉
Prompt injection
A booby-trapped site slips hidden instructions into a product page. The agent reading it then starts to “prefer” the fraudulent merchant or to inflate the cart. This is the leading attack against shopping agents.
🎭
Fake agents
Bots pose as well-known agents to get past WAFs, scrape prices, or test stolen cards. The defense lies in Web Bot Auth signatures and directories: without a verifiable signature, nothing distinguishes a legitimate agent from an impostor.
📜
Mandate theft or abuse
An overly broad mandate, with no expiration or limit, obtained through social engineering (“just authorize your assistant, it’s easier”) and then exploited. It is the agentic equivalent of authorized push payment (APP) fraud.
🕸️
Ghost merchants optimized for agents
Fake stores with flawless schema.org markup, designed to win over recommendation algorithms rather than humans. SEO spam goes agentic.
Require limits and expiration dates on every mandate. Never allow an unlimited mandate.
Isolate the agent from untrusted content (sandboxing, filtering instructions embedded in pages).
Combine KYA + mandate + transaction scoring: all three together, because any one alone falls short.
Monitor velocity per agent the way you monitor velocity per card.
⚠️
The agent paradox
A properly mandated, signed agent carries less risk than a human operator: it doesn’t get tired, standard phishing doesn’t work on it, and it leaves a complete audit trail. A poorly governed agent is worse, because fraud then runs at machine speed, around the clock. What separates the two is the governance rules applied to the agent.
