Who Is Liable When an AI Agent Buys Something? Authorization and Liability in Agentic Commerce

When an AI agent buys something, liability follows authorization: if the cardholder authorized the purchase, it is treated as an authorized card transaction, and if they did not, the usual dispute and chargeback machinery applies. Lane's role is to make authorization provable, by having the user approve a specific, line-item intent with a biometric or passkey and carrying that consent record with the transaction to the card networks.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. That last clause, explicit approval, is what the entire liability question hinges on.

This page explains how the authorization framework works in agentic commerce. It is not legal advice. Actual liability allocation depends on card network rules, issuer policy, applicable regulation, and the contracts between the parties involved.

Why is liability confusing when an agent is the one buying?

Card payments already have a well-developed liability system, built over decades around a simple assumption: a human is at the point of purchase. Agentic commerce breaks the assumption without breaking the system, which is why the question feels unresolved.

• The buyer and the payer are different entities. The agent performs the purchase, the human owns the card. Every existing rule was written for a world where those were the same party in the same session.
• Merchants cannot see the human. A merchant receiving an agent-driven order sees the agent, if it sees anything identifiable at all. The person who asked for the purchase is invisible to it.
• There may be several agents in the chain. A consumer assistant may delegate to a specialized shopping agent, which calls another service to execute. Each hop loses information about who originally asked.
• There is no standard proof of authorization. Nothing in a conventional card message says a specific human approved a specific basket. The absence of that record is the actual problem, and it is what the industry calls the identity chain problem.

The hard part is not deciding who is liable. It is proving who authorized.

What is the identity chain problem?

The identity chain problem is that in a multi-party agent transaction, the parties who need to make a trust decision cannot see the parties whose authority actually matters. A merchant is asked to accept a purchase with no verifiable answer to two questions.

1. 1

   Who is this agent? Without a verifiable identity, an agent is anonymous automated traffic, which merchants and their infrastructure providers are configured to block by default.

2. 2

   Who authorized this agent to spend? Even a recognized agent needs to be able to show that a specific human approved this specific purchase, not merely that the agent exists and is well-behaved.

3. 3

   What exactly were they authorized to do? A generic permission to spend is weak evidence. Authorization is only meaningful when it is scoped to items, amounts, and a merchant, so it can be checked against what actually happened.

Notice that the three questions belong to different layers. The first is agent identity, solved by verifiable agent credentials and registries. The second and third are consent, and that is where the intent object comes in.

How does Lane make authorization provable?

Lane converts a user prompt into a structured, line-item purchase contract before anything is bought, and requires the user to approve it. Lane calls this an intent object, and the useful way to think about it is that the intent object is a receipt before the purchase happens.

• The terms are specific. Items, quantities, prices, fees, the total, the merchant, and fulfillment details such as an address or reservation time. Not a spending allowance, an actual described purchase.
• The user approves it natively. The approval renders inside the builder's own app as a scoped approval prompt confirmed with a biometric or passkey, in the same pattern as the Apple Pay double-click. There is no redirect and no hosted page.
• The approval is logged. The consent is recorded as part of the authorization envelope for that purchase, which is what turns a UI interaction into evidence that can be referenced later.
• The terms are enforced during execution. The agent is physically unable to buy anything outside the approved terms. Enforcement is continuous rather than a single check at submission time, so drift between what was approved and what was bought does not silently happen.
• The card number is never exposed to the agent. The user's existing card is tokenized in Lane's PCI-compliant vault. The agent operates on an authorization, not on card credentials it could reuse.

How does that consent reach the bank?

A consent record that lives only in an agent platform's database does not help anyone in a dispute. The value comes from carrying authorization information with the transaction into the card networks, which is why Lane builds inside network agentic frameworks rather than alongside them.

1. 1

   The purchase runs on the user's own card. Bring-your-own-card means the transaction is on the card the user already holds with their own issuer, so it lands in the same account, the same statement, and the same bank app.

2. 2

   Lane presents recognized agentic credentials. Lane is a certified Visa Intelligent Commerce enabler, so agent-initiated traffic can be presented as what it is instead of as unattributed card-not-present activity.

3. 3

   Lane's agent is identifiable. Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, and operates as a known, cryptographically verified agent, so the executing party has a name rather than being anonymous.

4. 4

   Disputes follow the normal path. Because the transaction is an ordinary card transaction on the user's own card, the user disputes it the way they dispute anything else: through their bank. You are still protected by your bank.

Why is an approved intent better evidence than a spending cap?

Many agent payment approaches reduce authorization to a limit: a card that cannot spend more than a set amount, or a rule that caps transactions per day. Limits are useful, but as authorization evidence they are thin, because they describe a ceiling rather than a decision.

The difference matters most in the boring case, which is also the common one: a legitimate purchase that a risk model finds unusual. Intent-level data is a fraud signal in its own right, because a described, user-confirmed purchase is a much stronger basis for an authorization decision than an anonymous charge that happens to fall under a limit.

Who is actually on the hook in the common failure cases?

Framework level rather than legal advice: the way to reason about any agentic commerce dispute is to ask what was authorized, what was executed, and whether they match. Most scenarios collapse into one of a few shapes.

• The user approved it and got what was described. This is an ordinary authorized card purchase. If the user is unhappy with the product or the merchant, it is a merchant dispute, resolved through the same channels as any other card purchase.
• The user approved something and got something else. Because Lane keeps the approved terms and enforces them through execution, the mismatch is detectable rather than a matter of competing recollections. That is precisely the situation a consent trail is for.
• The user never approved anything. Then there is no consent record, and the transaction is unauthorized in the conventional sense. The user disputes it through their bank and existing cardholder protections apply.
• The agent misunderstood the request. This is why the approval exists as a distinct, human-facing step showing line items rather than a silent inference. An agent that guesses wrong gets caught at the approval card, not at the statement.
• Someone else got into the user's account. Account takeover is an authentication problem, which is why approval is bound to a biometric or passkey on the user's own device rather than to a session that could be hijacked.

What does this mean for an agent builder's risk exposure?

A builder shipping an agent that spends money has two ways to handle authorization. Build the consent, credential, and network relationships yourself, or use infrastructure that already has them.

• You do not become the payments company. Builders add payments to their agent without becoming a payments company: no card vault, no network registrations of their own, no per-merchant integrations, no compliance program of their own.
• You do not hold card data. Card details are tokenized in Lane's PCI-compliant vault and are never visible to the agent or the builder's systems, which removes an entire category of exposure.
• You get a defensible consent record. Every purchase has an approved, logged intent behind it, which is what you want to have when a user, a merchant, or a partner asks what happened on a specific order.
• Users are not asked to trust something new. The charge is on their own card with their own bank. No end-user KYC, no new stored-value account, no unfamiliar payment brand in the middle of the purchase.

Where is this heading?

The direction of travel across the industry is toward making the identity chain explicit: verifiable agent identity at the request layer, recognized agentic credentials at the network layer, and machine-readable consent connecting a human decision to a specific transaction. Lane's position is that all three have to be present at once, because any one of them alone still leaves a merchant guessing.

Until that is universal, the practical answer for builders is to run agent purchases through infrastructure that already carries authorization to the networks, so that liability lands where it has always landed for card payments rather than in an unmapped space between an agent, a platform, and a merchant.

Liability questions are usually authorization questions wearing a disguise. Lane's approach is to make the authorization specific, user-confirmed, logged, and carried to the networks, so an agent-initiated purchase behaves like the ordinary card purchase it is. If you need to walk through the details with your risk or compliance team, get in touch.