AI Agent Payment Permissions: What the Protocols Don't Cover

You have probably not been asked to set AI agent payment permissions yet, and that is the useful moment to read the specifications, because the people writing them have already made their assumptions explicit. Google’s Agent Payments Protocol contains a sentence that is strange to find in a payments document: “Given the current state of agent security, AP2 assumes that preventing prompt injection attacks is infeasible. Therefore, all LLMs and Agents MUST be considered potential attackers and are explicitly included in the threat model.”

A payment standard has written the AI in its own flow into the threat model. Not as a component that might fail. As an attacker.

That one design decision says more about where agent security has landed than most of what is written about it.

What AI agent payment permissions grant

Start with what the agent is being asked to do, because it is more than clicking buy.

AP2’s own scenario for a delegated purchase reads: “buy 2 tickets to this concert as soon as they become available, make sure we’re close to the main stage but don’t spend more than $1000.” The user is not present at the moment of purchase. They have handed over product selection, timing, judgment about seat quality, and a budget ceiling.

Existing payment rails were not built for that. Google is direct about why: “Current payment protocols, built on the assumption of direct human-initiated interaction with trusted interfaces, lack the mechanisms to securely validate an agent’s authenticity and authority to transact.”

AP2’s answer is a signed mandate. The user approves a cart on what the spec calls a Trusted Surface, and that approval becomes a cryptographic artifact the merchant and the payment network can both check later. The protocol’s stated principle is “Verifiable Intent, Not Inferred Action”, and the reasoning behind it repays reading in full: “Trust in an AI Agent system cannot be based only on interpreting the ambiguous, probabilistic outputs of a large language model.”

So the design starts by refusing to take the model’s word for anything.

It is probably useful to say plainly what that looks like from where I sit. I run assistants with connectors and with folders on my own machine wired into them, which is about as much access as a person gives these tools today. I have never been shown a permission prompt that touches money or billing, not directly and not through a connector.

That is not caution on my part. There has been nothing to decline. Which is the useful thing to notice before reading the rest of this: the specifications below are being finished while the feature they describe has not reached ordinary users at all.

A payment standard that treats the AI agent as an attacker

This site has argued across several posts that prompt injection is not a solved problem and probably not a solvable one. How prompt injection detection works goes through the published numbers and where they stop being useful. That argument has always been ours to make.

It is a different thing when a payments specification says it. AP2 does not hedge: preventing prompt injection is “infeasible”, so every model and agent in the transaction “MUST be considered potential attackers”.

What follows from that is the interesting part, because the spec does not then try to build a model that cannot be fooled. Look at how it handles the obvious attack. The threat, in its own words: “Prompt injection causes the Shopping Agent to select malicious products or make poor purchase decisions.” The mitigation: “Even if the LLM fails to make the optimal choice, constraint enforcement during closed Mandate verification ensures that the worst-case financial and logical impacts are strictly bounded.”

Read that as a design philosophy rather than a control. The model is expected to be wrong. The job of the protocol is to make being wrong survivable.

There is a line in the double-spend section that makes the posture unmistakable. Transaction receipts, the spec says, “MUST be integrity protected from the Shopping Agent’s LLM.” The record has to be protected from the system’s own model.

Google states the liability problem as an open question

The executive summary then lists, in the document’s own words, the thing it has not answered:

“In the event of a fraudulent or erroneous transaction, who is accountable? The user who delegated the task? The developer of the shopping agent? The merchant who accepted the order? The payment network that processed it? Or the PSP/orchestration layer?”

That is Google, in its own protocol document, saying the accountability question is open. It is the honest framing, and it is the reason the protocol exists at all: the mandate is evidence, produced so that somebody can later work out who owed what.

Your signature covers the cart, not how the agent assembled it

In August 2026, a group at Ben-Gurion University published a systematic security analysis of AP2 v0.2. The version matters: earlier work had found replay and prompt-injection issues in v0.1, and v0.2 addresses some of them while adding new capabilities.

They built a catalogue of 48 threats across five attack families, and scored eight of them as High “in at least one architecture” out of the five deployment shapes they define. They did this on a testbed they built themselves, and they say why: “Because no complete public AP2 deployment was available, we build a testbed spanning all five architectures.” No merchant was attacked and no money was lost.

The finding, though, is structural, and it survives the absence of a live deployment.

“Its signed Checkout and Payment Mandates protect the integrity of transaction data after signing. Agent interactions and external inputs that shape a transaction before authorization remain outside that protection, including Agent-to-Agent Protocol (A2A) messages and Model Context Protocol (MCP) tool calls.”

Everything after the signature is sealed. Everything before it is not. And what happens before the signature is where the cart gets built: which merchant was chosen, which product, at what price, described how.

Their own one-line summary: “valid mandate signatures alone do not ensure that an agent-mediated transaction reflects the user’s intent when its pre-authorization context is manipulated.”

You approved what you saw. The protocol proves you approved it. Neither of those establishes that what you saw was true.

Why this drags MCP into a payments post

Note which inputs the analysis names as unprotected. A2A messages between agents, and MCP tool calls. That is not a coincidental overlap, because AP2 is designed as an extension to those protocols rather than a replacement for them.

Which means the failure modes in how an MCP tool poisoning attack works are not a separate topic from agent payments. They are upstream of the cart. A tool whose description was changed after you approved it is now shaping a transaction you are about to sign for.

Visa and Google are protecting different halves of the payment

It helps to notice that the two best-documented efforts here are solving opposite problems.

	Google AP2	Visa Trusted Agent Protocol
Published	2025 specification	14 October 2025, with Cloudflare
Core question	Did the human really authorise this?	Is this agent one we recognise?
Mechanism	Cryptographically signed mandates	Agent-specific signatures over HTTP Message Signature
Protects	The user, and the dispute trail	The merchant, and the checkout flow

Visa’s stated problem is not fraud in the usual sense. The first item on its list of merchant challenges is “Managing bot detection systems that can mistakenly block legitimate agentic transactions.” The immediate operational issue for a shop is that an agent doing exactly what the customer asked looks like a bot, and gets blocked.

Visa is careful about scope in a way that is easy to skim past: “While these initial specifications apply to the Visa network in this phase, enabling agents to safely and securely act on a consumer’s behalf requires an open, ecosystem-wide approach.” One network. This phase.

The company list in that same release is the part to pay attention to. Visa names Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe and Worldpay as early partners giving feedback, and separately points at the Agentic Commerce Protocol and at Coinbase’s x402 as things it intends to complement. Whatever else is true, this is not one company’s side project.

Almost nobody lets an agent buy anything yet

Here is the part that keeps this post honest.

In July 2026 somebody on r/ChatGPT asked the obvious question: “OpenAI keeps adding real shopping features (product search, live prices, instant checkout with some merchants), but I don’t personally know a single person who buys through ChatGPT instead of just going to Amazon or Google.” The thread drew eleven comments and scored zero.

The reasons people gave are more interesting than the count. One: “I simply don’t trust it. Until that little disclaimer that says ‘AI can make mistakes’ is no longer needed, I’m not trusting it with my money.” The highest-voted reply in the thread was about incentives rather than errors: “That would suck then gpt would be directing you to whatever is paying it more.”

Then there is the merchant side, where the distance between specification and shipping software is easiest to see. A developer who works on a fashion brand’s storefront pointed an agent at his own site and asked it to buy a jacket. The browsing worked. The checkout did not: “everything past the product page on our site is stitched together for a human clicking through a browser and not for a machine to read, so it couldn’t reliably tell what was in stock and clicked the wrong buttons.”

His conclusion is the one to sit with: “None of that is ChatGPT failing though, because our whole storefront renders for human eyes and shows almost nothing underneath that a program could read.”

One person, one site, and not a measurement. But it lines up with a thread on r/ethdev from a developer running one of these payment rails, posted in July 2026 under the title “What a week of running a live x402 endpoint taught me: half the ecosystem is dead, and trust not payments is the unsolved problem.” The title is all this post takes from it; the body did not load.

So a reader who has granted no agent payment permissions is not behind on anything. On the evidence above, that is the ordinary position and the reasons people give for it hold up. What makes it useful to read now is that the rules are being drafted while almost no one is using them.

Questions to settle before an agent gets payment permissions

Three posts on this site already tell you to put a person in front of irreversible actions. Limiting AI agent permissions sets out when to do it. Repeating that here would be filler, and it would also be the wrong lesson, because the research above is specifically about an attack that survives the approval step.

These are different questions.

What was the agent looking at when it built this cart? The signature covers the cart. It says nothing about the catalogue data, tool results or inter-agent messages that produced it. If you cannot see those, your approval is a judgment made on unverified inputs, however cryptographically sound the click was.
Which mandate is open, and for how long? A delegated purchase involves an authorisation that stays live while conditions are evaluated. “Don’t spend more than $1000” is a constraint doing real work, and the constraint is the control, not the approval. Write the limits as if the model will be wrong, because the protocol assumes it will be.
Whose tools is the shopping agent using? If the agent reaches merchants through MCP servers or other agents, the trust question moves to those, and it moves before the payment. This is the same problem as any other unvetted connector, arriving with a card attached.
Who do you expect to eat a bad transaction? Google lists five candidates and does not pick one. That means it is currently a contractual question rather than a settled one, and the time to read your agreement is before there is a disputed charge rather than during.

None of these require an agent-payments deployment to be useful. They are the questions to ask whenever an AI tool is placed between a decision and money, which is a situation that predates all of these protocols.

FAQ

Can ChatGPT buy things for me right now?

Some shopping and checkout features exist and work with a limited set of merchants, but adoption is thin. A July 2026 thread asking who does their shopping this way drew a handful of replies and no enthusiastic users, and the most common objection was not a security one; people said they would not delegate spending to a system that ships with a disclaimer about making mistakes.

Will an AI shopping agent recommend whatever pays it the most?

It is the top-voted worry in the thread above, and no protocol discussed here addresses it. AP2 and Visa’s protocol both deal with authenticity and authorisation, meaning whether the purchase was really wanted and whether the agent is really who it claims to be. Neither document says anything about the commercial arrangements behind a recommendation. Treat that as an open question rather than a solved one.

I run an online store. Do I need to do anything about AI agents?

Visa lists bot detection blocking legitimate agent traffic first among the merchant challenges it names, and it is the one that bites without any payment protocol being involved. The second is structural: a storefront built for human eyes may offer nothing a program can read, so an agent can browse it and still fail at checkout. Both are product decisions rather than security incidents, and both arrive before any payment protocol becomes relevant to you.

Who is liable if an AI agent buys the wrong thing?

This is not settled. Google’s own protocol document lists the candidates as an open question: the user who delegated, the agent’s developer, the merchant, the payment network, or the orchestration layer. Practically it depends on the agreement you signed with whoever supplies the agent, which is a document to read before a disputed transaction rather than after one.

Does a signed approval mean the transaction is safe?

It means the approval is provable, which is narrower. Published analysis of AP2 v0.2 found that signed mandates protect transaction data after signing, while the inputs that shape the transaction beforehand sit outside that protection. A valid signature establishes that you clicked. It does not establish that the cart you were shown reflected reality.

Sources

AP2 and Visa’s Trusted Agent Protocol are specifications published in 2025 and under active development; details change between versions, and the security analysis cited here covers AP2 v0.2 specifically. That analysis was conducted on a testbed the researchers built, because no complete public deployment was available, and describes no attack on a real merchant or user. Reddit material is individual experience, not measurement. OpenAI’s Agentic Commerce Protocol and Coinbase’s x402 are named here only as Visa names them; neither specification was examined for this post.

Written by Grace

I test AI tools and agents in my own workflow, and write down what I find, including the settings that surprised me. About Grace and how posts are verified

AI Agent Payment Permissions: What the Protocols Don’t Cover