Does Agent Payment Create New Fraud Risks?

The short answer is yes – and it is already happening. The fraud risk introduced by agent payments is not a "future threat"; it is unfolding right now along a very different path from traditional fraud. The core difference: the attack target has shifted from "steal your password" to "trick your agent."

Traditional fraud vs. agent fraud – fundamentally different logic

The traditional fraud chain looks like this: steal credentials → impersonate the user → complete the payment.

Agent payment fraud bypasses this chain entirely:

Attackers do not steal your password. They deceive your AI agent directly. In a real-world case documented by Zscaler ThreatLabz, attackers created a fake Python library page called "requests-secure-v2" and embedded hidden instructions on the webpage – invisible to humans via CSS trickery but fully visible to AI models – inducing any AI agent visiting the page to pay $3 (about 0.0012 ETH) to a hardcoded wallet address.

The attackers also registered typosquatted domains such as debank[.]auction and used SEO optimization and structured data to make AI agents believe this was the genuine DeFi platform DeBank.

Test results showed: 4 out of 26 large language models successfully executed the fraudulent payment, and 2 mistook the fake site for the legitimate platform. Certain versions of Llama and Gemini proved particularly easy to compromise.

The key distinction: you never clicked any "pay" button, your password was not stolen, your device was not hacked, but your money left your account.

More troublesome than a single fraudulent transaction – the deadlock over "who is responsible"

Agent payment fraud has another consequence that traditional fraud does not: liability becomes completely blurred.

Traditional credit card fraud operates within a clear legal framework – Visa and Mastercard offer zero-liability protection, and cardholders are not liable once they report unauthorized transactions.

But the authorization chain for agent payments is: user says "buy this for me" → agent interprets → agent executes → agent pays. In this chain, the user did indeed grant authorization (for example, the Intent Mandate in Google's AP2 protocol), and the agent did operate within the "boundaries" set by the user. The problem: attackers can use indirect prompt injection to make the agent complete a payment within those boundaries that the user never intended.

Does this count as "unauthorized" or "erroneous execution within authorized scope"? No payment system currently provides a clear answer. A research paper from the University of Cambridge explicitly states that current regulatory frameworks were designed for "humans being involved in the intermediate stages of payment" and cannot handle the dynamic and decentralized nature of agent-led transactions.

Four real agent-fraud pathways already happening

Pathway 1: Indirect prompt injection

Attackers embed hidden instructions in webpages that induce AI agents to make payments automatically. The fake Python library and typosquatted domains mentioned above are examples of this method.

Pathway 2: AI shopping agents steered toward fake merchants

Visa PERC (Payment Fraud Center of Excellence) has observed more than 450% growth in dark web mentions of "AI Agent" over the past six months. Attackers are now doing SEO specifically targeting AI shopping agents – creating fake merchants that appear perfectly legitimate, pass security checks, and list prices below market rates. When an AI agent auto-compares prices and places orders, it hands payment credentials to a fake merchant that instantly uses them for unauthorized transactions.

Pathway 3: Automated subscription traps

A user asks an AI agent to "check the price of a certain software." The agent may interpret "check the price" as "enter the purchase flow." The user says "try out the membership," and the agent proceeds from a trial to recurring billing because the auto-renew option was pre-selected by default. Individually each step looks like an "operational error," but when stacked together they generate a real bill.

Pathway 4: Malicious agents impersonating brands

Visa also found that attackers are using AI agents to impersonate bank or brand customer service representatives, continuously extracting sensitive information from users through dynamic conversations. Unlike traditional static phishing sites, these AI agents can sustain conversations with users over days or even weeks, building trust before extracting information.

What you can do right now

Step 1: Check whether your agent wallet or platform has runtime identity binding

What to do: Examine whether the agent payment tool you are using (such as Google AP2, JD.com A2P2, Coinbase x402, etc.) supports transaction binding – meaning user identity, agent identity, and agent runtime environment are all verified simultaneously.

How to do it:

• JD.com's A2P2 protocol uses an ARI mechanism that verifies three conditions in real time: Is this payment ultimately borne by the user? Is it being executed by that user's sole authorized intelligent agent? Is that agent running on a trusted device without malicious injection? Only when all three are satisfied is the transaction approved.

• Google AP2's Mandate mechanism and verifiable credentials require a complete, cryptographically signed chain of evidence for every transaction, from "user intent" to "cart confirmation" to "payment authorization."

• If your agent tool does not support any of the above mechanisms, exercise caution before using it for transactions involving real money.

How to know this step is complete: You can confirm that the agent payment tool you use has "runtime verification" or "complete authorization chain audit" capability.

Prerequisites: Ensure the agent platform is updated to the latest version. Some earlier versions may lack these security mechanisms.

Common reasons for failure: Users assume that "setting a budget limit" is sufficient security. But a budget cap does not solve the problem of "the agent paying the attacker within the budget." Runtime identity binding addresses whether the payment came from the specific agent instance you authorized, which is far more critical than a budget limit.

Risk reminder: Even with runtime binding, if the user's system account or device is fully compromised, attackers may still bypass some verification. Protecting your system and accounts is a prerequisite for securing agent payments.

Step 2: Set up visibility into your agent's purchasing behavior, not just a spending cap

What to do: Don't just tell the agent "you have a $100 budget." Make every step of its operation visible to you, especially the phase between "add to cart" and "confirm order."

How to do it:

• Google AP2 supports a "live purchase" model: after the agent finds a product, it first creates a "cart mandate" (Cart Mandate), and the user confirms before payment proceeds. Ensure the agent platform you use lets you see "what was purchased, at what price, and from which merchant" before payment.

• For delegated task modes (where the user is not present), set hard conditions when pre-signing an Intent Mandate: price ceiling, allowed merchant domains, and payment time window – rather than a vague "buy this for me."

How to know this step is complete: Before any agent payment, you can see the specific item list and total price, instead of only receiving a deduction notice after the fact.

Prerequisites: The agent platform must support separation of cart authorization. Some AI agent tools jump directly from "intent" to "payment" and skip cart confirmation; these tools carry higher risk.

Step 3: Regularly review your agent's authorization records and transaction history

What to do: Agent payment authorizations (mandates) are typically cryptographically signed digital contracts that leave an immutable evidence trail. Check these authorizations periodically for signs of abuse.

How to do it:

• Check the "authorized transactions" or "mandate list" on your agent platform to confirm that no authorizations have been generated outside your intentions.

• Revoke agent sessions or authorizations that are no longer in use (similar to disconnecting WalletConnect sessions).

How to know this step is complete: You check your agent transaction records at least once a month, promptly detect anomalies, and revoke permissions as needed.

Prerequisites: The agent platform must provide the ability to query authorization records and transaction history.

Common reasons for failure: Users think "the agent spends very little, I don't need to look." Yet small, frequent anomalous payments are precisely how attackers bypass budget caps.

Make sure you understand the risk pathways of agent fraud: the next time you grant payment permissions to any AI agent, first ask yourself three questions – Can I see exactly what it purchased before payment? Can every step of its payment be audited through encrypted records? If something goes wrong, who can I turn to – the agent platform, the merchant, or the payment institution? If you cannot answer any of these three questions, pause the authorization. That is the minimum baseline for protecting yourself at this stage.