Who Pays When an AI Agent Buys the Wrong Thing?

You give a shopping agent a budget and a job. Order the replacement water filter for the fridge. It finds a listing, reads the fitment table wrong, and buys a filter for a different model. The box shows up. The charge posts.

Walk the parties. The merchant shipped the item that was ordered, at the advertised price, to the right address. Nothing went wrong on the merchant side. You never saw the listing and never chose that filter, so nothing went wrong on your side either. The agent misread a table.

Now try to place that in the existing rulebook. Chargeback reason codes are organized around a small set of failures: the goods never arrived, the goods were not as described, or the transaction was not authorized. An agent that flawlessly ordered the wrong thing is none of those. The merchant delivered. You gave permission for the agent to buy. Somebody is still out the money.

What Regulation E and Regulation Z actually say

Two consumer rules do most of the work in the United States, and which one applies depends on how you paid. Reg E covers electronic fund transfers out of a consumer account, so it reaches debit and ACH. Reg Z covers credit cards. An agent in the flow does not change which rule you are under.

Start with the piece that matters most. In its January 2026 agentic symposium white paper, the Consumer Bankers Association puts the Reg E framing in one line: “The burden falls on the financial institution to prove that a transfer was authorized; if the institution cannot establish authorization, the consumer is not liable.”

Read that with an agent in the flow and you can see the problem. Proving a transfer was authorized used to mean showing that the person holding the card was the person who agreed to the charge. With an agent, the institution has to show something harder: that a delegation from you existed, that it covered this amount and this merchant, and that it was still in force at the moment authorization ran. Not in force last week. In force at that instant.

Banks are not well positioned to show that today. The same paper notes that banks may have limited visibility into agent behavior, which makes it hard to explain to a consumer what the agent did or why. The institution carries the burden and does not hold the record that would discharge it.

Be careful here, because it is easy to overclaim. The filter case may not be an unauthorized transfer at all, and if it is not, that burden of proof line never gets reached. The CBA calls this “the ‘access device’ trap”: sharing credentials or API keys with an AI agent “may be deemed furnishing an access device, potentially shifting full liability to the consumer if the AI agent exceeds its authority.” The paper is blunt about what follows. “Put another way, consumers may be liable for mistakes their agents make and these mistakes could be costly.”

Reg Z is in the same position. The CBA notes that Reg Z caps consumer liability for unauthorized credit card transactions at the lesser of $50 or the transaction amount before notice, and that the protection “does not apply if the transaction is made by someone who has ‘actual, implied, or apparent authority to use the consumer's credit card.’” Whether telling an agent to go buy something creates that authority is, in the CBA's own words, “at best, unclear.”

So the accurate summary is short. Nobody knows yet. The rules were drafted for a world with two candidate wrongdoers, and the plain reading of the delegation exception tends to point back at you. The Federal Reserve's Regulation E compliance guide mentions AI agents nowhere.

What the networks have actually shipped

The card networks are not ignoring this. They have shipped real infrastructure, and each piece is worth describing accurately.

Visa Trusted Agent Protocol

Visa introduced Trusted Agent Protocol on October 14, 2025, working with Cloudflare and with feedback from a long list of acquirers and platforms. Its specification uses RFC 9421 HTTP Message Signatures, gives signatures a maximum eight minute validity window, checks nonces for replay, and publishes a JWKS so a merchant can verify the agent's signature. It answers the question a merchant asks at the door: which agent is this.

Mastercard Agent Pay and Verifiable Intent

Mastercard announced Agent Pay on April 29, 2025 as part of its Agentic Payments Program, requiring that trusted agents be registered and verified before they transact, with network tokens as the credential bound to the agent. Alongside it sits Verifiable Intent, a layered SD-JWT design carrying a credential provider layer, a user signed layer and short lived agent signed layers, with full chain disclosure reserved for disputes and the payment network holding the audit trail. In June 2026 Mastercard extended the model with Agent Pay for Machines, launched with more than thirty partners.

American Express ACE and Agent Purchase Protection

American Express published its Agentic Commerce Experiences developer kit on April 14, 2026, with five components: agent registration, account enablement, intent intelligence, payment credentials and cart context. The Amex engineering team describes the credential model as OAuth plus mutual TLS with scoped, short lived credentials and a structured intent contract. Listed on the same page, and marked coming soon, is Amex Agent Purchase Protection, which covers charges related to AI agent error for eligible customers.

AP2

AP2, the Agent Payments Protocol, launched from Google in September 2025 with more than sixty partners and was donated to the FIDO Alliance in April 2026. It is the most complete of the group on signed artifacts. The specification defines Checkout and Payment Mandates, binds the agent key through a confirmation claim, requires ECDSA, and defines signed Checkout and Payment Receipts.

x402

x402 came out of Coinbase and now sits under the x402 Foundation at the Linux Foundation, launched April 2, 2026 with American Express, Mastercard, Visa, Google, Microsoft and Stripe among its members. Settlement is on chain, so the payment itself is independently checkable. More on that in x402 agent payments and receipts.

Here is the honest observation about all five. Each answers a question that comes before the purchase. Who is this agent, is it registered, what was it allowed to spend, and did the user say yes. None of them produces a record, after the fact, of which party got it wrong. Mastercard's developer guidance is candid about what that leaves: it states that Mastercard and Visa “have confirmed that existing dispute frameworks and chargeback rules apply to agentic commerce transactions” and that “merchants cannot require consumers to waive dispute rights,” per its agentic commerce guide. Those frameworks assume the merchant or the cardholder erred.

Amex said the quiet part out loud

The clearest public statement of the gap came from American Express. Luke Gebb, EVP and Head of Global Innovation, speaking to Digital Commerce 360 on April 14, 2026:

“If the merchant has made no error and the cardmember has made no error, but the agent has made the error, that's a new paradigm in agentic commerce today and one that has not been figured out.” Luke Gebb, EVP and Head of Global Innovation, American Express, in Digital Commerce 360, April 14, 2026

That is the filter case, described by an executive at the company that just took on the liability for it. He went further in the same piece, on where the money actually starts to move:

“no one has yet brought the issuer into the equation (or the bank). That's where you start to have legitimate financial liability for transactions.” Luke Gebb, EVP and Head of Global Innovation, American Express, in Digital Commerce 360, April 14, 2026

Credit where it belongs. Amex named the open problem in public while shipping a product into it, and Agent Purchase Protection puts real money behind that position. Much of the industry still treats agent error as a research topic. Amex wrote a commitment to pay.

That commitment creates a practical follow on question. When you pay out on agent error, what is the record that says the agent erred, and who besides you can check it? It sits waiting for every issuer that follows.

What is missing

Describe the missing thing generically and it gets easy to recognize. You need a signed record. It has to be produced by a party that is not the issuer, not the acquirer, not the merchant, not the network and not the agent operator, because every one of those parties has a stake in the answer. And anyone holding the record has to be able to recompute the finding from the same inputs and arrive at the same result, so the conclusion is checkable rather than asserted. What it determines is narrow: which party's own precommitted constraint the observations violated.

Precommitment means every constraint has to be timestamped strictly before the loss, so nobody gets to invent a rule after they see the bill. Independence means the signer cannot be a party to the transaction, because a party signing its own exoneration proves nothing in a dispute. Recomputability means a regulator, an agent operator or a merchant can run the check instead of accepting somebody's database row. That last point is the one we keep coming back to in logs are claims, receipts are proof.

There is a fourth property that matters more than it looks. The record has to be able to say it does not know. If the precommitments postdate the loss, the honest output is indeterminate rather than a named party. Anything that always produces a defendant is not evidence.

None of this competes with what the networks have built. Identity, registration and scoped credentials are prerequisites for any of it to work. It is the layer that sits after the purchase, when someone has to decide who absorbs the cost.

The two instruments

Hive builds exactly two receipts for this. authorization.decision records the approve or decline, the mandate it was measured against, and whether that mandate was live at the instant. fault.attribution allocates loss among the principal, the agent operator, the acceptor and the issuer by recomputing which party's own precommitted constraint the observations violated, and returns indeterminate when the precommitments postdate the loss. Both are signed by a role that is fixed in the schema so it cannot be any party to the transaction. Patent pending.

The canon entries walk through both of them, field by field, with what each one proves and what it does not: authorization.decision and fault.attribution. The nearest published white papers are mandate conformance, for measuring an action against the mandate meant to bound it, and cross acceptor, for an agent spending across acceptors that will not show each other their books. The same signing approach runs underneath AI agent receipts.

Questions people are asking

Who pays when an AI agent makes a buying mistake?

In the United States this is unsettled. The CBA wrote in January 2026 that it is “at best, unclear” whether authorizing an AI agent to buy things creates the kind of authority that removes consumer protections. Amex has published Agent Purchase Protection, listed as coming soon, covering charges related to AI agent error for eligible customers.

Does Regulation E cover an AI agent transaction?

Reg E covers electronic fund transfers out of a consumer account, so it reaches debit and ACH rather than credit card purchases, which sit under Reg Z. The Federal Reserve's compliance guide for Reg E says nothing about AI agents. The CBA notes Reg E puts the burden on the institution to prove a transfer was authorized, and that whether the delegation exception applies to an agent is unclear.

Can you charge back a purchase an AI agent made by mistake?

Mastercard's developer guidance says Mastercard and Visa have confirmed that existing dispute frameworks and chargeback rules apply to agentic transactions, and that merchants cannot require consumers to waive dispute rights. Those frameworks were built around merchant error and unauthorized use, so an agent that correctly ordered the wrong item does not land cleanly on an existing reason code.

What do Visa Trusted Agent Protocol and Mastercard Agent Pay actually prove?

Trusted Agent Protocol signs the agent's HTTP requests so a merchant can tell which agent is calling, with signatures valid for at most eight minutes. Agent Pay registers and credentials agents and pairs them with Verifiable Intent, a layered SD-JWT carrying the user's scoped instruction. Both establish identity and permission before the purchase. Neither determines fault after it.