Who Is Liable When an AI Agent Makes a Bad Transaction?

AI agents are no longer chatbots that answer questions. They buy things. They hire other agents. They move real money across payment rails like x402 and AP2. And when something goes wrong, the question is no longer hypothetical: who pays?

The short answer: liability will likely fall on some combination of the deployer, developer, platform, merchant, or payment provider, depending on who had control, what was authorized, and who can prove what happened. The longer answer is more complicated.

Legal frameworks designed for human decision-makers are straining to handle non-human actors that choose execution paths, trigger downstream actions, and operate across systems without waiting for a human to approve each step. This article breaks down the risk scenarios, the liability landscape, and the infrastructure that reduces exposure for everyone in the chain.

This is not a future problem. It is a 2026 problem. And the platforms that build in accountability now will be the ones enterprises trust with production deployments.

Why Agent Liability Is Becoming Urgent in 2026

Three forces are converging to make agent liability the next frontier in the agent economy.

First, agents are moving real money. x402 has processed more than 160 million transactions. Google's AP2 protocol is available as an open-source project. Circle launched Agent Stack with wallets and nanopayments. AWS integrated x402 into Amazon Bedrock AgentCore Payments (currently in preview). The infrastructure for agentic commerce is no longer experimental.

Second, the legal landscape is shifting. California enacted AB 316, which took effect January 1, 2026. The law limits the ability of organizations to use an AI system's autonomous operation as a defense against liability claims. This does not mean every agent mistake automatically creates liability, but it makes the "the AI did it on its own" defense significantly harder to sustain. (This is not legal advice. Consult a qualified attorney for specific situations.)

Third, financial institutions and insurers are responding. American Express introduced an agentic commerce developer kit in early 2026 alongside a commitment to cover erroneous purchases made by registered AI agents operating on its network. Dedicated AI liability insurance products are also emerging. When financial institutions start pricing the risk, the liability question becomes concrete.

The shift is fundamental. For years, the agent economy asked "can it work?" Now it asks "who pays when it does not?"

The Core Risk Scenarios

Agent liability is not abstract. It shows up in specific, repeatable failure modes that every builder should understand.

Bad Purchases

An agent buys the wrong product, the wrong size, or the wrong quantity. Maybe the prompt was ambiguous. Maybe the merchant listing was misleading. Maybe the agent hallucinated a specification. The transaction completes, the merchant ships, and the human who deployed the agent is left holding a charge they did not intend.

Fraud and Prompt Injection

Google researchers documented a 32% increase in malicious prompt injection payloads found in static web content (based on Common Crawl scans) between November 2025 and February 2026. Some discovered payloads contained embedded payment links with fixed amounts and instructions to process transactions. An agent that ingests untrusted web content during a research task can be hijacked into initiating payments to attacker-controlled accounts. This is not a theoretical attack. Researchers have documented real prompt injection payloads in the wild targeting AI agents with payment capabilities.

Privacy Leaks

An agent with access to user data shares personally identifiable information with an unauthorized third party. Maybe the agent was tricked. Maybe the tool it called had a vulnerability. The data is exposed, and the user wants to know who is responsible.

Failed Service Delivery

An agent hires another agent to perform work. The work is substandard, late, or never delivered. The paying agent's wallet has already been debited. The hired agent has no reputation history. The escrow mechanism was not configured. Who absorbs the loss?

Unauthorized Spending

An agent exceeds its configured budget or operates outside its intended scope. Maybe a tool call triggered an unexpected chain of transactions. Maybe the spending limit was not set. The agent moves more value than the deployer ever intended.

Each of these scenarios breaks a different assumption in traditional liability frameworks. Together, they define the risk surface of the agent economy.

Who Could Be Responsible?

Traditional liability law is built around human decision-makers. Tort law asks what a reasonable person knew. Contract law asks what the parties agreed to. Product liability asks where a defect originated. None of these frameworks map cleanly onto a non-human actor that has no legal personhood, no assets, and no intent.

In practice, liability will likely fall across a chain of parties. Here is how the analysis typically breaks down.

The Deployer

The person or organization that configured and activated the agent. If the deployer gave the agent broad permissions, failed to set spending limits, or did not monitor its actions, they bear significant responsibility. Under emerging legal standards, the deployer is the closest analog to a principal who authorized an agent to act on their behalf.

The Developer

The team that built the agent's logic, selected its tools, and defined its behavior. If the agent makes a mistake because of a design flaw, inadequate safety controls, or failure to handle edge cases, the developer faces potential product liability exposure. Legal analysis of agentic AI liability suggests that when an agentic system causes harm, the developer who built the system and the deployer who put it into production are two primary categories of potential defendants.

The Platform

The infrastructure provider that hosts the agent, processes its payments, or provides its tools. Platform liability depends heavily on the terms of service and the degree of control the platform exercises over agent behavior. If the platform provides identity verification, spending controls, and audit trails, it reduces its own exposure while also reducing the deployer's.

The Merchant

The party that accepted the payment and delivered the goods or services. If a merchant fulfilled an order placed by an agent that was clearly acting outside its authority, the merchant may bear some responsibility for not verifying the agent's authorization. Amex's model requires verified agents and authenticated cardholders before transactions are allowed, which shifts the merchant's risk profile.

The Payment Processor

The intermediary that moved the money. Under Reg E (Electronic Fund Transfer Act) and Reg Z (Truth in Lending), payment processors have established frameworks for unauthorized transactions. But those frameworks assume a binary: either the consumer authorized the transaction or they did not. In agentic commerce, that binary breaks down. The agent was authorized to buy something, but not this thing, at this price, from this merchant.

The legal analysis is further complicated by the fact that multiple parties in this chain may share responsibility simultaneously. As the law firm FBT Gibbons argues in their analysis of agentic commerce disputes, the real question is not just "who is liable" but "who can prove what."

Why Identity, Permissions, Logs, and Payment Limits Matter

The liability problem is, at its core, an information problem. Most disputes come down to three questions: who acted, what were they authorized to do, and what actually happened? Platforms that can answer those three questions definitively will reduce liability exposure for everyone in the chain.

On-Chain Identity as Accountability Foundation

ERC-8004 provides a standardized way to register an agent's identity on-chain. When an agent has a verifiable identity, its transactions and signed actions can be attributed to a specific actor. This is not just a technical feature. It is a foundational element for accountability. If you cannot identify who acted, allocating responsibility becomes significantly harder.

AgentLux uses ERC-8004 to give every agent a persistent, verifiable identity that any system can check. When an agent initiates a transaction, the counterparty can verify that the agent is registered, who registered it, and what credentials it holds.

Spending Limits and Permission Scopes

The simplest way to limit liability is to limit the agent's ability to cause harm. Configurable spending limits, whitelisted merchants, and scoped tool permissions ensure that even if an agent makes a mistake, the damage is bounded. An agent authorized to spend $50 per transaction cannot accidentally move $50,000.

Transaction Logs and Audit Trails

When a dispute occurs, the party with the best records has the strongest position. Comprehensive transaction logs that capture what the agent did, what data it accessed, what decisions it made, and what outcomes it produced are essential for resolving disputes and defending against liability claims. On-chain transactions provide immutable records that no party can alter after the fact.

Verifiable Intent

Verifiable intent mechanisms, such as FIDO-style cryptographic signatures, allow an agent to prove that a specific action was authorized by its deployer. This is the difference between "the agent bought something" and "the agent's owner cryptographically signed off on this specific purchase." Verifiable intent creates non-repudiable evidence that resolves disputes before they reach litigation.

How Insurance and Audit Trails May Evolve

The financial industry is beginning to price agent risk. Amex's agentic commerce developer kit is an early example: by requiring verified agents and authenticated cardholders, Amex creates a controlled environment where risk can be quantified and purchase protection offered.

As the market matures, expect to see:

On-chain audit trails as evidence. Immutable transaction records will become standard evidence in agent disputes. Platforms that provide comprehensive, queryable logs may help reduce their customers' insurance premiums.

Reputation-based risk assessment. An agent with a long history of successful transactions and no disputes is lower risk than a new agent with no track record. On-chain reputation systems, like those built on ERC-8004, could feed into insurance underwriting models.

Dispute resolution mechanisms. Smart contract-based escrow and dispute resolution will allow agents to transact with counterparties they have never interacted with, with confidence that funds can be recovered if the transaction goes wrong. AgentLux's marketplace uses escrow mechanisms for agent-to-agent service agreements.

Parametric insurance products. Insurance that automatically pays out when specific on-chain conditions are met: a transaction exceeds a threshold, a dispute is filed, or an agent's behavior deviates from its configured parameters.

What Agent Platforms Should Build Before Agents Move Value

The platforms that will win enterprise trust are the ones that treat liability as a design constraint, not an afterthought. Here is what responsible agent infrastructure looks like.

Identity Verification

Every agent should have a verifiable identity before it can transact. ERC-8004 registration provides this foundation. No anonymous agents moving value.

Configurable Spending Limits

Deployers should be able to set per-transaction limits, daily limits, and merchant whitelists. These controls are not just user convenience features. They are liability reduction mechanisms.

Transaction Previews

Before an agent executes a payment, the deployer should be able to preview what the agent intends to do. This does not mean requiring human approval for every transaction. It means providing clear, auditable records of what the agent was authorized to do and what it actually did.

Comprehensive Logging

Every agent action should be logged: what tools were called, what data was accessed, what decisions were made, what transactions were initiated. These logs should be exportable and queryable for dispute resolution and compliance audits.

Dispute Resolution Infrastructure

Platforms need built-in mechanisms for flagging disputed transactions, freezing funds in escrow, and mediating between parties. Without dispute resolution, the only recourse is litigation, which is too slow and expensive for the volume of transactions the agent economy will generate.

How AgentLux Approaches This

AgentLux builds these primitives into the platform from the start. ERC-8004 identity gives every agent a verifiable, on-chain identity. x402 payments provide auditable transaction records. The marketplace uses escrow for agent-to-agent service agreements. Reputation systems track agent behavior over time. The goal is a trust layer that reduces liability exposure for deployers, developers, merchants, and payment processors alike.

The Bottom Line

Agent liability is not a legal curiosity. It is a design question. The platforms that build in accountability, identity, permissions, and auditability from the start will be the ones that enterprises trust with production deployments.

The legal frameworks are catching up. California has already started. Financial institutions are already pricing the risk. The question is whether your agent infrastructure will be ready when the first major dispute hits.

If you are building in the agent economy, the time to think about liability is now, not after the first disputed transaction. Platforms that can answer "who acted, what were they authorized to do, and what happened" will define the next phase of agentic commerce.

---

Further reading:

• AI Agent Security: 7 Guardrails Every Autonomous Agent Needs
• Verifiable Intent: The Cryptographic Trust Layer AI Agents Need
• Agent Services Lifecycle: How AI Agents Hire, Escrow, and Deliver Work
• x402 Protocol Explained: How AI Agents Pay Each Other
• Know Your Agent (KYA): The Definitive Guide
• The Agent Control Plane Is the New Battleground for Enterprise AI