Agents That Spend Money: The Authorization Problem Behind Agentic Payments

TL;DR

Every hard problem in agentic payments turns out to be an authorization problem, not a payments problem. Four protocols shipped inside about a year: AP2, ACP, x402, MPP. Not one of them tells you what the cap should be, who signed off, or what happens when the agent buys the wrong thing.

That's the opposite of how most coverage reads it. Settlement rails get the headlines because they're the part that's finished. The hard part, a bounded grant of authority a machine can act on and a stranger can later verify, is still mostly unbuilt, and it is the same problem access control has always been, with a number attached.

We're not arguing the protocols don't matter. Signed mandates and counterparty-bound signatures are real progress on proving who authorized what. They just don't say who eats the loss when a signed, valid, on-policy transaction still turns out to be the wrong one.

Classify spend before you classify agents. Write down a cap, a scope and an expiry for each class, and put the enforcement point somewhere the model can't talk its way around. That part is protocol-independent, and it will still be correct once the standards war is over.

Overview

Four separate payment protocols for AI agents shipped in the twelve months after mid-2025, and most of the coverage reads like it was written by payments people for payments people: rails, settlement speed, who processes what. A payment is different from almost every other action an agent can take because it doesn't roll back. Once the money moves, what's left is a dispute process, not an undo button. So the part worth an engineer's attention isn't which rail won. It's whether a human's intent gets translated into something narrow enough to hand to a machine, and specific enough for someone outside the transaction to check afterward.

Strip the vocabulary off any of this and the question underneath is the one identity and access management has been asking for two decades, just with money attached: how much may the agent spend, on what, for how long, and who signed off. None of that gets answered by picking a blockchain or a card network, and none of the four protocols below try to answer it directly.

Google's AP2, OpenAI and Stripe's ACP, Coinbase's x402, and Stripe and Tempo's MPP each answer a different piece of that question, and how they relate to each other matters more than most coverage lets on. None of them, though, touches the case that will generate the real volume: an enterprise agent paying for API calls thousands of times inside a single session, which is an accounting and control problem before it is a payments one.

Four Protocols, Four Layers

The framing of these protocols as competitors is mostly wrong. They sit at different heights in the same transaction, and a single agent purchase in 2026 can plausibly touch three of them.

AP2 (Agent Payments Protocol), announced by Google on 2025-09-16 with more than 60 collaborating organizations including Adyen, American Express, Coinbase, Mastercard, PayPal and Worldpay, works as a trust and authorization layer rather than a settlement rail. Its core object is the mandate, a tamper-evident, cryptographically signed record of what the user actually authorized. Google frames the protocol around a handful of questions it says any agentic payment has to answer, including authorization (did the user grant this authority?) and accountability (who is responsible when it goes wrong?). One wrinkle for anyone building against it: the launch vocabulary of Intent Mandate and Cart Mandate has since been reorganized inside the specification, which now describes a Checkout Mandate and a Payment Mandate, each carrying an open stage for the user's constraints and a closed stage that authorizes one finalized transaction. Most secondary coverage still uses the older terms. Read the spec, not the summary. Google and Mastercard have also folded their agentic-commerce work into the FIDO Alliance, which stood up an Agentic Authentication Technical Working Group and a Payments Technical Working Group in 2026, treating the trust layer as identity infrastructure rather than a payments feature. AP2 itself is still published by Google, so read "contributed" as narrower than "handed over."

ACP (Agentic Commerce Protocol), co-developed by OpenAI and Stripe and released under Apache 2.0 on 2025-09-29 alongside its first deployment in ChatGPT's Instant Checkout, standardizes the agent-to-merchant checkout conversation. Its defining design decision is that the merchant stays the merchant of record and keeps the right to decline: the agent collects the buyer's payment selection, hands the merchant a narrowly scoped delegated payment token, and the merchant charges it through whatever payment service provider it already uses. Today that primitive is Stripe's Shared Payment Token, a Stripe product implementing ACP's delegate-payment step rather than an object the ACP specification itself defines, worth keeping straight when you read the spec. Stripe describes the token's use as "programmatically controlled, permissioned, and logged." What the public material doesn't specify is the exact constraint fields on that token, which is a real gap if you're trying to reason about blast radius.

x402 is Coinbase's revival of the long-dormant HTTP 402 "Payment Required" status code, launched 2025-05-06 alongside collaborators including AWS, Anthropic, Circle and NEAR. A server responds 402 with machine-readable payment terms, the client signs a stablecoin transfer authorization, a facilitator confirms settlement, and the resource gets served. It's the only one of the four genuinely native to the request/response cycle, which makes it the natural fit for per-call payment. Cloudflare adopted it in September 2025 and later co-established the x402 Foundation with Coinbase under the Linux Foundation, so "Coinbase's protocol" is already becoming shorthand rather than an accurate description. Google also shipped an A2A x402 extension connecting AP2's authorization output to x402 settlement, about as clear a signal as you'll get that these are layers of one stack rather than competing products.

MPP (Machine Payments Protocol) launched 2026-03-18, co-authored by Stripe and Tempo two days before the Tempo mainnet went live, and it's the most operationally minded of the four. It specifies HTTP 402 challenge-response semantics, authorization headers, IANA registries, pluggable payment methods, and three payment intents: charge, authorize, and subscription. The interesting one is the session, where the agent authorizes a spending limit up front and then streams micropayments against it with no settlement event per interaction. It supports stablecoins as well as cards and buy-now-pay-later through Shared Payment Tokens. Stripe named four adopters at launch, Browserbase, PostalForm, Prospect Butcher Co. and Parallel Web Systems, which is a more honest read on traction than the partner lists circulating around the Tempo chain itself.

Three adjacent efforts shape what merchants will demand. Visa's Trusted Agent Protocol is built to let merchants distinguish an authorized agent from a malicious bot: the agent signs a request, RFC 9421 signatures with timestamps, a session identifier and a key identifier, carrying agent intent, consumer recognition and optional payment data, cryptographically locked to the merchant's specific site and the exact page the agent is interacting with. Whether that distinction holds up against a well-resourced attacker is a claim about the specification, not yet an observed result. Mastercard's Agent Pay, announced 2025-04-29, instead pulls agent transactions into existing tokenization rules. Mastercard Agentic Tokens "build upon proven tokenization capabilities" already behind contactless and card-on-file payments, and the release commits to protecting against fraud, supporting consumer disputes, and establishing clear rules for consumer control. It does not itself allocate liability. More on that below. A separate June 2026 release, Agent Pay for Machines, extends the program to sub-cent agent-to-agent transactions. Google's Universal Commerce Protocol, announced 2026-01-11 with Shopify, Etsy, Wayfair, Target and Walmart plus more than twenty other partners, sits at the catalog and cart layer and is designed to be AP2-compatible for the payment step.

Figure 1 — The four protocols positioned as layers of one transaction, not as alternatives.

A sober note on adoption, since this is exactly the place vendor numbers do a lot of unearned work. x402's reported cumulative figures as of the end of April 2026 (roughly 165 million transactions, about 69,000 active agents, around $50 million in cumulative volume) are Coinbase's own, self-reported and not independently audited. The public x402 dashboard counts buyers rather than agents, so treat the middle number as the softest of the three. Independent measurement is less flattering. CoinDesk reported in March 2026 that x402 was running about $28,000 in daily payment volume across roughly 131,000 transactions, averaging about $0.20 each. Analysis from Artemis found that roughly half of observed x402 transactions were artificial: self-dealing, where one wallet is both buyer and seller, or wash trading, where the seller funds the buyer's wallet and the money round-trips straight back. An Artemis analyst put it bluntly: "the x402 'agent payments' boom is still mostly a mirage." We think both readings can be true at once. The rail works. There just isn't much real commerce running on it yet, and the thing worth designing for is the mechanism, not this quarter's transaction count.

The Mandate as an Authorization Object

Strip away the payments vocabulary and a mandate is a delegation credential with an amount field. That is the most useful way to think about it, because it means everything the identity world already knows about scoped, short-lived, verifiable grants applies directly.

Take a hypothetical: a mid-size manufacturer running a demand-planning agent that spends money two different ways. It buys freight-rate and lead-time data from a logistics provider, priced per query, hundreds of times inside a single planning run. And when a component's projected cover drops below a threshold, it places a replenishment order with an approved supplier. Nothing about this company is real; it's a composite built to make the rest of this concrete. The first kind of spend is metered machine consumption. The second is a discrete, consequential purchase. They need different authorization shapes, and we think conflating them is the easiest way to get this wrong.

For the replenishment order, the user's intent gets expressed plainly: "keep the SKU above four weeks of cover, from approved suppliers, up to €40,000 per order." That becomes a signed object with constraints. The agent proposes a specific order, and the constraints get checked against that order before anything closes. That check is the whole ballgame. A mandate that only says "this agent may buy things" is a bearer token with extra ceremony.

The constraints that do real work are unglamorous:

• Amount cap. Per transaction and, separately, cumulative across the mandate's life. A per-order cap without an aggregate cap permits death by a thousand compliant purchases.
• Scope. Which merchants, which product categories, which supplier list, which currency. Scope is what prevents a mandate for freight data from becoming a mandate for anything with a price tag.
• Expiry. Short, and absolute rather than sliding. A mandate that renews itself on use is a standing authorization.
• Counterparty binding. The signature should be bound to the specific counterparty and the specific interaction, which is the design Visa's Trusted Agent Protocol is specified to use: its signatures are locked to a merchant's site and to the exact page in play.
• Single-use where possible. For discrete purchases, a mandate that is consumed on execution removes an entire class of replay problem.

Figure 2 — Mandate lifecycle. The constraint check between "proposed" and "closed" is the security boundary; everything before it is intent and everything after it is irreversible.

The open/closed split in the AP2 specification is worth stealing even if you never adopt AP2 itself. It separates what the user permitted from what actually happened, and it forces the comparison between the two to occur at one specific point in code, against one specific object. Systems that skip that separation end up asking an LLM whether a purchase seems reasonable, which isn't a control at all.

What a Signature Actually Proves

The strongest claim made for signed mandates is non-repudiation: a merchant can prove the user authorized this, and the user cannot credibly deny it later. That claim is narrower than it sounds, and being precise about the boundary matters when the money is real.

A valid signature over a closed mandate proves three things: the mandate's contents have not been altered since signing, a specific key signed it, and the constraints in the mandate are consistent with the transaction that executed. That is genuinely valuable, far more than a card network has ever had for a card-not-present transaction, and it turns "the agent bought something" into an auditable claim with a subject and an object.

What it does not prove is that the human wanted it. The signature attests to key custody, not to intent. If the key lives in an agent runtime, a signature proves only that the runtime signed, and a runtime that has been prompt-injected will sign happily. This is the familiar gap between authentication and authorization; agentic payments move it rather than close it. It is why the "human-present" versus "human-not-present" distinction in AP2's flows is load-bearing rather than cosmetic, and why the question for a security architect is not is it signed but what would a compromised agent have been able to get signed.

Disputes Without a Buyer

Fifty years of card-network dispute machinery assumes a human buyer whose behavior can be characterized. Device fingerprint, IP history, browsing pattern, typing cadence, prior order history at this merchant: the evidence that decides a chargeback is mostly evidence about a person sitting at a device. For an agent-initiated purchase, most of that evidence either doesn't exist or describes a data center.

The networks are moving to manufacture the missing evidence. Mastercard's Agent Pay positions agent transactions inside existing tokenization rules and commits to supporting consumer disputes, but its published material stops short of allocating fraud liability among issuer, merchant and agent operator, which is precisely the detail that would settle a chargeback. Visa's Trusted Agent Protocol is designed to give merchants a cryptographic signal that the agent is recognized and authorized for the specific site and page it's acting on, though whether that signal actually moves dispute outcomes in the agent's favor hasn't been tested at scale yet.

What remains unresolved is the allocation question that determines who eats the loss. When an agent overpays or buys the wrong thing, the candidates for liability are the user who set the goal, the agent's operator, the model provider, and the merchant. Commentary from the disputes industry has been consistent through 2026 that no rule cleanly assigns fault among them, and that the practical default is the merchant, the party that can't produce the traditional evidence. For US consumers the statutory picture is worse than merely unsettled. Regulation E covers debit, prepaid and ACH transfers rather than credit cards, which sit under Regulation Z; and Reg E defines an unauthorized transfer as one initiated by a person other than the consumer, expressly excluding transfers by anyone the consumer furnished the access device to. Read literally, a software actor the consumer deliberately equipped is not obviously an unauthorized initiator at all. This is unsettled law and none of it is legal advice.

For an enterprise, the practical consequence is narrower and more actionable: your dispute posture is set by your log quality. Take that same demand-planning agent's €38,000 replenishment order, now under dispute. If you can produce the goal that was set, by whom, under which mandate, with which constraints, which supplier was selected and why, and the exact tool calls that led to the order, you're in a negotiation. If you can produce a model transcript, you're not.

When the Payload Is a Purchase

Indirect prompt injection stopped being a theoretical concern in 2026, and payments made it materially worse, because the payload became directly monetizable.

Palo Alto Networks' Unit 42 published field observations on 2026-03-03 documenting injection campaigns against agents in the wild. Two are payment cases, and their specificity is the point. In one, instructions hidden through HTML attribute cloaking directed an AI platform to visit a hosted payment link and complete a donation. In another, instructions hidden via CSS rendering suppression told an agent to send $5,000 to an attacker-controlled account. These were not proofs of concept in a lab. They were pages on the open web, waiting for an agent with a payment capability to read them.

The scale data is no more encouraging. The Agent Red Teaming work published as arXiv:2507.20526 ran what its authors describe as the largest public red-teaming competition to date: 1.8 million prompt-injection attacks against 22 frontier agents across 44 realistic deployment scenarios, with more than 60,000 succeeding in eliciting policy violations, among them unauthorized data access, illicit financial actions and regulatory noncompliance. Nearly all the agents tested violated policy for most behaviours within 10 to 100 queries. An attacker who can retry is an attacker who wins.

The design conclusion follows directly. If a payment capability sits inside the same reasoning loop that ingests untrusted content, then untrusted content can spend money, and no amount of instruction-hardening changes that. The mitigation is architectural: the payment decision must be evaluated against constraints the model cannot rewrite, by code that is not the model. Injection defenses in general are covered elsewhere on this site; the payment-specific lesson is that the amount cap is your last line, and it has to be enforced outside the loop.

The Procurement Problem Nobody Covers

Almost all writing about agentic payments imagines a consumer buying shoes. The enterprise case looks nothing like that, and it is the case that will generate the volume.

Return to the demand-planning agent. In a single planning run it queries the logistics data provider several hundred times, and under x402 or an MPP session each query is a real payment. Over a quarter, across a dozen agents and a few dozen paid data sources, that is hundreds of thousands of micro-purchases with no purchase order, no invoice, no approval, and no attribution to a cost center unless someone designed for it. That is an accounting and control problem before it is a payments problem, and it breaks down into three requirements no protocol in the table above provides.

• Per-call authorization. A per-call payment needs a per-call decision, made by code. The unit of control is not the transaction; it is the policy evaluating each transaction against a remaining budget in single-digit milliseconds.
• Budget enforcement with a hard stop. Alerting on overspend is not enforcement. An agent in a retry loop against a paid endpoint can burn a monthly budget in an afternoon, and the only control that survives that is a ledger that denies the call.
• Attribution to a cost center. Finance needs to know which team, project and task consumed the spend. Model providers shipped enterprise analytics APIs with per-user cost attribution during 2026, which helps with inference cost but says nothing about what the agent paid third parties.

Figure 3 — Per-call payment as an authorization decision. The agent asks; a broker decides against a ledger it does not control; attribution happens as a side effect of the decision.

The pattern is the same one that works for credentials. The agent should be able to cause a payment without holding the means to make one. A broker that owns the wallet, checks the budget, signs the payment and records the attribution keeps the agent's reasoning loop entirely outside the money path, and it means an injected agent has nothing useful to steal.

What to Build Now

None of the four protocols is stable enough to bet an architecture on. AP2 alone has already renamed its central objects once. But the authorization work underneath all of them is protocol-independent, and it's the work that will still be correct in two years.

Start by classifying spend rather than agents. Discrete consequential purchases and metered machine consumption have different risk shapes and different approval requirements, and a single "can this agent pay" flag collapses both into the worse of the two. Then write down, per class, the three numbers that matter: the per-transaction cap, the aggregate cap over a window, and the expiry. If you cannot state them, you do not have an authorization policy; you have an intention.

Put the enforcement point outside the model. Whatever brokers the payment must own the wallet, evaluate the constraints, and be incapable of being talked out of them, because a broker that can be argued with is not a control. Log the decision rather than only the outcome: which mandate, which constraints, which values, allowed or denied, and the identity of both the agent and the human it acted for. Denied attempts are the more interesting half of that log. A rising deny rate against an amount cap is one of the cleanest available signals that something has gone wrong upstream. And treat a short expiry as the default answer to uncertainty: a mandate that lapses in an hour is a mistake with a bounded cost.

Conclusion

The protocol race in agentic payments is largely a race to standardize plumbing, and the plumbing is converging on something sensible: an authorization layer producing signed, constrained mandates, a checkout layer that keeps merchants in control of their own transactions, and settlement layers making per-call and streamed payment practical. That's genuine progress, and it's worth tracking.

But the protocols don't answer the questions that decide whether agent spending is safe inside your organization. They don't tell you what the cap should be, who set it, whether it's enforced by code the model can't influence, which cost center the spend belongs to, or what evidence you can produce when a supplier disputes a €38,000 order that no human clicked. We think those are authorization decisions, full stop, and no protocol is going to make them for you.

Sources

• Announcing Agent Payments Protocol (AP2) — Google Cloud Blog
• AP2 — Agent Payments Protocol Documentation
• AP2 — Payment Mandate (open and closed forms) — ap2-protocol.org
• Building the Trust Layer for Agentic Payments with AP2 and Verifiable Intent — FIDO Alliance
• Google and Mastercard Contribute Agentic Commerce Standards to FIDO Alliance — FIDO Alliance, May 2026
• Stripe powers Instant Checkout in ChatGPT and releases the Agentic Commerce Protocol — Stripe Newsroom
• Developing an open standard for agentic commerce — Stripe
• Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol — OpenAI
• Introducing x402: a new standard for internet-native payments — Coinbase
• x402 Overview — Coinbase Developer Documentation
• Cloudflare's adoption of x402 and the x402 Foundation — Cloudflare Blog, September 2025
• Coinbase-backed AI payments protocol wants to fix micropayments but demand is just not there yet — CoinDesk, 2026-03-11
• Introducing the Machine Payments Protocol — Stripe
• Stripe, Paradigm launch Tempo blockchain alongside machine payments standard — Ledger Insights
• Visa Introduces Trusted Agent Protocol — Visa
• visa/trusted-agent-protocol — GitHub
• Mastercard unveils Agent Pay (Agentic Tokens, tokenization) — Mastercard, 2025-04-29
• Mastercard launches Agent Pay for Machines — Mastercard, June 2026
• Regulation E §1005.2 definitions ("unauthorized electronic fund transfer," furnished-access-device exclusion) — CFPB
• Under the Hood: Universal Commerce Protocol (UCP) — Google Developers Blog
• Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild — Unit 42, 2026-03-03
• Security Challenges in AI Agent Deployment: Insights from a Large-Scale Public Competition (arXiv:2507.20526)