Agent Payments Protocol (AP2): The Security Risks Merchants Should Plan For
AP2 gives merchants a cryptographic record of what a shopper authorized an AI agent to buy. It also creates new ways for that proof to be forged or abused, and it does not settle who eats the loss. Here is the merchant view.
Google’s Agent Payments Protocol (AP2) hands merchants something genuinely useful: a cryptographic, non-repudiable record of exactly what a shopper authorized an AI agent to buy. It also hands them new problems. The same protocol that proves intent creates fresh ways for that proof to be forged, replayed, or abused, and it does not settle who eats the loss when an autonomous agent buys the wrong thing. If you sell online, AP2 security risks are about to become a line item, not a thought experiment. The World Economic Forum projects that by 2028, one in four enterprise breaches could stem from AI-agent exploitation (World Economic Forum5). Agents are also about to move real money: McKinsey estimates agentic commerce could orchestrate up to $1 trillion in U.S. retail revenue by 2030, and $3 trillion to $5 trillion globally (McKinsey6). I build agent-verification tooling at RankShield, and the pattern I already see is merchants treating AP2 as a payments upgrade when it is really a trust-and-liability shift. What most explainers leave out is the merchant’s exposure: which risks land on you, who is liable when an agent misfires, and what to actually put in place. That is what this guide covers. One honest caveat up front: no protocol removes fraud. AP2 changes where fraud lives and who has to prove what.
What is the Agent Payments Protocol, and how do mandates work?
AP2 is an open protocol Google announced on September 16, 2025 with more than 60 payments and technology partners, including Mastercard, PayPal, American Express, Coinbase, and Adyen (Google Cloud1). It lets an AI agent pay on a user’s behalf using mandates: tamper-proof, cryptographically signed records of what the user actually authorized. AP2 is built as an extension of the Agent2Agent (A2A) protocol and the Model Context Protocol (MCP), so it rides on top of how agents already talk to tools and to each other.
The protocol works in two signed steps. First an Intent Mandate captures the scope and constraints of a request, for example "buy white running shoes, size 10, under $150," which sets the rules the agent must stay inside. Then, once the agent assembles a specific cart, the shopper’s approval signs a Cart Mandate that locks the exact items and price so what the shopper saw is what they pay (Google Cloud1). Each mandate is signed by verifiable credentials, and the chain from intent to cart to payment produces a non-repudiable audit trail.
For a merchant, the useful part is that this audit trail is evidence you can hold. AP2 is explicitly designed to answer three questions: was the agent authorized, does its request reflect the user’s true intent, and who is accountable if the transaction is wrong (AP2 Protocol2). That is a real upgrade over an anonymous bot hitting your checkout. It also means the mandate, not the card, becomes the thing worth attacking, which is where the risk section starts.
What new security risks does AP2 create for merchants?
The risks cluster around forging or abusing mandates, not stealing card numbers. The Cloud Security Alliance’s analysis of AP2 names mandate spoofing (forging a signed mandate), agent coercion (a compromised or prompt-injected agent bypassing its own constraints), session hijacking, and identity-linking that correlates a shopper across merchants (Cloud Security Alliance3). Google itself frames the open problem as accountability when a fraudulent or incorrect transaction occurs (Google Cloud1).
The practical one to watch is prompt injection. An agent that can be tricked into signing a Cart Mandate it should have refused turns the whole "proof of intent" model against you, because the signature is valid even though the intent was manipulated. The Cloud Security Alliance maps this to workflow hijacking, where injected content redirects what the agent delegates and approves (Cloud Security Alliance3). Containing prompt injection at the agent layer is a prerequisite for trusting anything the agent signs.
Real attacks are already taking shape. Palo Alto Networks’ Unit 42 documents fraud that hides gift-card line items inside purchase mandates, where a shopper skims past the extra charge as a tax or fee, and returns fraud that hijacks the state machine to trigger instant refunds without proof of return, at a scale where bot farms can initiate 10,000 returns in a single hour (Unit 424). Here is the honest part: the cryptography is sound. The soft spots are the agent’s decisions and your verification step, not the signature.
Who is liable when an agent payment goes wrong?
AP2 is built to make accountability answerable, not automatic. Its non-repudiable audit trail shows what the user authorized and what the agent did, which gives everyone a shared record to assign responsibility against (Google Cloud1). That is a meaningful improvement over disputes where no one can prove intent. But a signed mandate proving a shopper asked for "running shoes under $150" does not resolve a fight over whether the agent picked the right shoes, and those intent disputes tend to land on the merchant.
It helps to separate the layers. Authorization, meaning did the user permit an agent to act, is now provable in a way it never was before. Authenticity of intent and responsibility for downstream damage are the harder questions, and AP2 gives you evidence toward them rather than a verdict. This is the same problem we cover in who is liable when an AI agent makes a mistake: clear logs narrow the argument, they do not end it.
Card-network schemes push some fraud liability around through tokenization, but the merchant still owns the chargeback and the customer relationship when a purchase is disputed. The move that protects you is keeping your own tamper-evident record of intent at the moment of sale, rather than relying solely on the agent’s account of what the shopper wanted. That is exactly what pre-settlement intent attestation is built to produce: evidence you control, on your side of the transaction.
How does AP2 compare to Mastercard Agent Pay, Visa Trusted Agent, and ACP?
AP2 is the broad, open, payment-method-agnostic layer built on W3C Verifiable Credentials, and the card networks built narrower schemes that plug into it. Mastercard announced Agent Pay on April 29, 2025, using Agentic Tokens that bind a tokenized card to a specific agent, merchant scope, and consent, so a model can check out without ever holding the raw card number (Mastercard8).
Visa took the identity angle. It unveiled the Trusted Agent Protocol on October 14, 2025, co-developed with Cloudflare, which adds a cryptographic agent identity to the ordinary HTTPS request so a merchant can verify an agent against a Visa-operated directory instead of guessing from a user-agent string (Visa7). OpenAI and Stripe’s Agentic Commerce Protocol (ACP), which powers ChatGPT’s Instant Checkout, is another intent-and-checkout layer in the same space.
These are layers, not just competitors. Network tokens fund the transaction, while AP2 or ACP carry the intent and authorization, and Visa’s protocol adds agent identity. The likely reality for merchants is multi-protocol: you will support more than one. The through-line across all of them is the same, verifiable agent identity plus provable consent, which is the thing to build toward no matter which standard wins the most volume.
How should merchants prepare for agent-led payments?
Prepare by treating agent traffic as identity-first: require agents to prove who they are and what they are authorized to do, verify the mandate and consent at checkout, and keep your own record of the transaction rather than trusting the agent’s account of it. The Cloud Security Alliance’s recommended controls point the same direction: hardware-backed keys, decentralized allowlists, strong customer authentication, short mandate lifetimes, and DID-based agent identity (Cloud Security Alliance3).
Start with visibility. Most merchants do not know whether agent traffic is already reaching checkout, which is the same blind spot behind shadow AI agents inside a company. You cannot set a policy for traffic you cannot see. Akamai reported that AI bots already make up 47.9% of commerce traffic, with agentic traffic up 7,851% year over year, so this is present tense, not a forecast (Akamai9).
Then get specific. Do not block all automation, because that turns away real buyers arriving through AI; instead distinguish a verified agent from an anonymous bot. Capture verifiable intent at the moment of purchase so a dispute has evidence, and verify agent identity rather than trusting a self-reported label that a bad actor can spoof. My honest opinion after building this tooling: the merchants who win will be the ones who can say yes to a verified agent and no to an anonymous one, fast. That is what RankShield’s agentic payment security and its verifiable AI layer are built to do.
What should merchants do about AP2 now?
Treat AP2 as a trust-and-liability shift, not a payments upgrade. It gives you something real: a signed, non-repudiable chain from intent to cart to payment that finally makes authorization provable. It does not remove fraud; it moves it to forged mandates, coerced agents, and the verification step you own. The risks that matter are mandate spoofing, prompt-injected agents signing carts they should refuse, and refund abuse at machine speed, and the honest answer to "who is liable" is still contested, with intent disputes landing on the merchant.
So build toward the thing every standard is converging on: verifiable agent identity and provable consent, plus your own tamper-evident record of intent at checkout. Get visibility into agent traffic first, verify identity rather than trusting a label, and keep evidence on your side of the transaction so a dispute has proof. AP2 gives you evidence, not immunity. If you want to allow the agents you can verify and refuse the ones you cannot, see how RankShield secures agent payments.
Questions, answered.
What is the Agent Payments Protocol (AP2)?
AP2 is an open protocol Google announced on September 16, 2025 with more than 60 payments and technology partners, including Mastercard, PayPal, American Express, and Coinbase. It lets an AI agent pay on a user’s behalf using mandates, which are tamper-proof, cryptographically signed records of what the user authorized. AP2 works in two steps: an Intent Mandate captures the rules and limits of a request, and a Cart Mandate locks the exact items and price the shopper approved. Together they form a non-repudiable audit trail that answers whether the agent was authorized, whether its request reflects real intent, and who is accountable if a transaction is wrong. AP2 is built as an extension of the A2A and MCP agent protocols, so it rides on top of how agents already communicate.
Is AP2 secure for merchants?
AP2’s cryptography is strong, but "secure" depends on more than the signatures. The Cloud Security Alliance’s analysis identifies risks that AP2 introduces or must mitigate, including mandate spoofing, a prompt-injected agent bypassing its constraints, session hijacking, and identity-linking across merchants. The signature on a mandate can be perfectly valid while the intent behind it was manipulated, which is why prompt-injection containment and agent-identity verification matter as much as the protocol itself. For merchants, the safe framing is that AP2 reduces some fraud and gives you evidence, but it does not eliminate fraud. Treat the agent’s decisions and your own verification step as the real attack surface, and add controls there rather than assuming a signed mandate is proof of good intent.
Who is liable if an AI agent buys the wrong thing?
It depends on which layer failed, and AP2 gives you evidence rather than an automatic verdict. AP2’s audit trail makes authorization provable: you can show the user permitted an agent to act and what the agent then did. What that record does not settle is authenticity of intent, meaning whether the agent correctly interpreted what the shopper wanted, and those intent disputes tend to land on the merchant. Card-network schemes shift some fraud liability through tokenization, but the merchant still owns the chargeback and the customer relationship. The practical protection is to keep your own tamper-evident record of intent at the moment of purchase, so a dispute has proof on your side rather than relying only on the agent’s account of what the shopper asked for.
How is AP2 different from Visa Trusted Agent Protocol and Mastercard Agent Pay?
AP2 is the broad, open, payment-method-agnostic layer that carries intent and authorization through signed mandates. The card networks built narrower schemes that plug into it. Mastercard announced Agent Pay on April 29, 2025, using Agentic Tokens that bind a tokenized card to a specific agent, merchant scope, and consent. Visa unveiled the Trusted Agent Protocol on October 14, 2025, co-developed with Cloudflare, which adds a cryptographic agent identity to the HTTPS request so a merchant can verify an agent against a Visa-operated directory. These are layers rather than pure competitors: network tokens fund the transaction while AP2 carries the intent, and Visa’s protocol adds identity. Most merchants will end up supporting more than one, so the durable investment is verifiable agent identity and provable consent.
Can AP2 mandates be faked or hijacked?
The signatures themselves are hard to forge, but the surrounding process can be attacked. The Cloud Security Alliance describes mandate spoofing, where an attacker tries to forge a signed mandate, and agent coercion, where a compromised or prompt-injected agent signs a cart it should have refused, producing a technically valid mandate for a purchase the shopper never really wanted. Unit 42 has documented related fraud that hides extra line items inside purchase mandates and hijacks the returns process to trigger refunds at scale. The defense is layered: verify signatures against issuer keys, use hardware-backed key storage, keep mandate lifetimes short, contain prompt injection at the agent, and verify cart contents rather than trusting that a signed mandate reflects honest intent.
How do I get my store ready for agent payments?
Start with visibility, because most merchants do not know whether agent traffic is already reaching checkout, and AI bots are already 47.9% of commerce traffic according to Akamai. Once you can see it, do not block all automation, since that turns away real buyers arriving through AI. Instead, verify an agent’s identity rather than trusting a self-reported user-agent string, capture verifiable intent at the moment of purchase so disputes have evidence, and contain prompt injection at your agent or integration layer before you trust anything an agent signs. The Cloud Security Alliance also recommends hardware-backed keys, short mandate lifetimes, and strong customer authentication. The goal is to say yes to a verified agent and no to an anonymous one, quickly and repeatably.
References
- Google Cloud. Announcing Agent Payments Protocol (AP2). September 16, 2025. Mandates, Intent/Cart, verifiable credentials, A2A/MCP, non-repudiable audit trail; authorization, authenticity, accountability.
- AP2 Protocol. Official specification and documentation.
- Cloud Security Alliance. Secure Use of the Agent Payments Protocol (AP2). October 6, 2025. STRIDE/MAESTRO threat model: mandate spoofing, agent coercion, workflow hijacking, identity linking; recommended controls.
- Palo Alto Networks Unit 42. Who’s Really Shopping? Retail Fraud in the Age of Agentic AI. Gift-card line-item injection, returns-state-machine hijack, bot farms initiating 10,000 returns per hour.
- World Economic Forum. AI agents and trust: by 2028, one in four enterprise breaches could stem from AI-agent exploitation.
- McKinsey & Company. The agentic commerce opportunity. October 2025. Up to $1 trillion US retail revenue by 2030; $3-5 trillion globally.
- Visa. Visa Introduces Trusted Agent Protocol. October 14, 2025. Cryptographic agent identity, Visa-operated directory, co-developed with Cloudflare.
- Mastercard. Mastercard unveils Agent Pay. April 29, 2025. Agentic Tokens binding a tokenized card to agent, merchant scope, and consent (MDES extension).
- Akamai (via GlobeNewswire). AI bots are 47.9% of commerce traffic; agentic AI traffic grew 7,851% year over year in 2026.
Jamie Kloncz
Founder & CEO, RankShield
Jamie Kloncz is the founder and CEO of RankShield, the verifiable AI and quantum security platform. He started the company after two attacks landed in a single week: his phone was cloned, and his business was hit by a click-fraud campaign. One targeted him as a person, the other his livelihood, and no single tool defended both. That experience, together with surviving an AI voice-clone scam, shaped RankShield’s core belief: the threats of the AI age are personal first, and trust should be something you can check, not just extend.
Make every AI action provable.
RankShield is the verifiable, quantum-safe AI security platform — protection you can check, not just trust.