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

What do the agent payment protocols say about liability?

Less than the write-ups imply. Google's Agent Payments Protocol, AP2, is the one built specifically for the argument that happens after the purchase, and its own specification is careful about where it stops. In a dispute, it says, the Checkout Mandate and Receipt and the Payment Mandate and Receipt can be brought together to give a non-repudiable picture of the transaction. Then, immediately: “Specific details of how this is used for dispute resolution, retention, and retrieval requirements are outside the scope of this specification” (the AP2 specification).

The project's FAQ is equally plain about the intent. A primary objective, it says, is to supply evidence that helps payment networks establish accountability and liability principles, with a network adjudicator such as a card network comparing the user-signed Checkout Mandate against what is claimed in the dispute (AP2 FAQ). That is a handoff rather than a gap in the design. AP2 assembles the exhibit and passes it to whoever already adjudicates the dispute.

An analysis by Aashis Luitel, republished by Fortune from The Conversation on 24 August 2026, reaches the same reading from outside the project: AP2 shows how the evidence could travel, and it does not decide who bears the loss or specify how long each company must keep that evidence and how it can be retrieved later (Fortune). Retention is the part builders underrate. On card rails a dispute routinely arrives months after the purchase, by which point most application log policies have rotated the instruction away, so a mandate that every party can generate and none is required to store may not exist any more when someone finally asks for it.

Why does the word “unauthorised” decide the outcome?

Because in the United States the consumer protections are written to trigger on that one word, and both of the definitions describe a stranger.

Regulation Z caps a cardholder's liability for unauthorised use of a credit card at the lesser of $50 or the amount obtained before the issuer is notified. The term itself is narrow: “the use of a credit card by a person, other than the cardholder, who does not have actual, implied, or apparent authority for such use, and from which the cardholder receives no benefit” (12 CFR 1026.12(b), eCFR, Cornell LII).

Regulation E covers debit cards and other electronic fund transfers, and reaches the same shape by a different route. An unauthorised transfer is one initiated by a person other than the consumer without actual authority and from which the consumer receives no benefit, and the definition then excludes, expressly, a transfer initiated “by a person who was furnished the access device to the consumer's account by the consumer, unless the consumer has notified the financial institution that transfers by that person are no longer authorized” (12 CFR 1005.2(m), eCFR, Cornell LII).

Now put an agent in those sentences. You configured it, you handed it a credential, and you told it to buy running shoes under $120. It bought the wrong shoes, or the right shoes four times. Actual authority is precisely what you granted, and a benefit did arrive. Whether that reads as unauthorised is a question of fact about your specific instruction, which is a much harder question than the one the $50 cap was written to settle. These are the American rules; other jurisdictions allocate consumer loss differently, and this page describes what the rules say rather than advising on any particular dispute.

Who does the dispute actually reach?

The merchant, in most designs shipping today, and the standards say so deliberately. The Agentic Commerce Protocol, the one behind ChatGPT's Instant Checkout (Stripe, Payments Dive), states that businesses maintain their customer relationships as the merchant of record, and that an AI platform embeds commerce into its application without being the merchant of record (agenticcommerce.dev, and the same wording in the ACP specification repository).

So the path is the familiar one. The cardholder complains to the issuer, the issuer raises the chargeback, and it lands on the business that fulfilled the order. The agent platform that produced the instruction is not in that chain, and nothing in the standards obliges it to keep the instruction or to hand it over. The merchant defends a purchase it did not originate using records it does not hold.

What can you do before the rules catch up?

Three things, and all of them are logging discipline rather than law.

Keep the instruction beside the transaction. Not in an application log with a fourteen-day retention, but in the same store as the payment record and under the same retention rule. Disputes reach you long after the sale. An instruction that rotated out after a fortnight is evidence of nothing.

Scope the credential to the task rather than to the agent. The token your agent holds is written for everything it might ever need to do, while the prompt covers only this minute. The payment network sees the token.

Write down your own liability position before a customer asks for it. Every dispute I have handled on card rails collapsed into the same three questions: what was authorised, by whom, and can you show it. AP2 and the work around it are solving the third question and leaving the first two to you, so decide now what you will say when a customer asks the first one.