No US federal statute directly addresses AI agent purchase liability. The EU AI Act introduces a risk-classification framework that will shape how liability is argued in European courts, but its commerce-specific provisions are still being operationalized. Payment network rules from Visa and Mastercard were drafted for human cardholders, and chargeback procedures have not been formally updated to account for agent-initiated transactions.
What follows is a practitioner-level analysis of the legal frameworks that apply today, the gaps regulators have not yet closed, and the contractual controls buyers and merchants can put in place right now. Nothing in this article constitutes legal advice.
The Current Liability Landscape: Unsettled by Design
AI agent purchase liability sits at the intersection of three bodies of law that were written for different actors: agency law (written for human agents), electronic contract law (written for click-through and EDI transactions), and consumer protection law (written for individual buyers). None maps cleanly onto an autonomous software system that can browse, compare, negotiate, and pay without a human approving each step.
To understand what agentic commerce is and why this gap matters, consider the scale of the problem. Agentic systems are already processing procurement, travel booking, subscription management, and B2B supply orders. When something goes wrong — a wrong SKU purchased, a duplicate order placed, a fraudulent agent command executed — the injured party must identify a responsible legal person. Courts and regulators are still deciding who that is.
Why No One Has Sued to a Final Answer Yet
Litigation takes years. Most current agentic commerce errors are resolved commercially — merchants issue refunds, platforms absorb costs, and enterprises quietly eat losses to avoid setting precedent. This means the case law that will ultimately define AI agent purchase liability does not yet exist in the US, and EU cases under the AI Act will not reach final judgment for several years after the Act's commerce-relevant provisions take effect.
The result is a liability vacuum that practitioners must navigate using analogical reasoning from existing doctrine.
How Principal-Agent Doctrine Applies to AI Systems
The most directly applicable legal framework is the common law of agency, codified in the Restatement (Third) of Agency. Under this doctrine, an agent is a person who acts on behalf of a principal, with the principal's consent, and subject to the principal's control. The principal is bound by the agent's actions within the scope of actual or apparent authority.
AI systems fit this structure imperfectly but usefully:
- The principal is the individual or organization that deploys the AI agent and grants it access to payment credentials, procurement systems, or purchasing authority.
- The agent is the AI system itself — though courts have not formally recognized software as a legal agent, the principal's liability for agent actions does not require the agent to have legal personhood. What matters is whether the principal authorized the conduct.
- Actual authority exists when the principal explicitly programs or configures the agent to make purchases within defined parameters.
- Apparent authority arises when a merchant reasonably believes the agent has authority to transact, based on how the principal has held the agent out — for example, by providing it with a corporate payment card and API credentials.
When an agent acts within its authorized scope and something still goes wrong — say, it purchases the right item from the wrong vendor — the principal bears the loss unless there is a contractual remedy against the platform or a statutory remedy available. When an agent acts outside its authorized scope — purchasing items the principal never permitted — the principal may still be liable to a good-faith merchant under apparent authority doctrine, while retaining a claim against whoever caused the unauthorized conduct (a rogue configuration, a compromised prompt, or a platform bug).
Electronic Contracts and Automated Transactions: E-SIGN and UETA
Two statutes form the backbone of US electronic contract law: the Electronic Signatures in Global and National Commerce Act (E-SIGN Act, 2000) and the Uniform Electronic Transactions Act (UETA), enacted in 47 states. Both validate electronic records and signatures, and — critically — both contain provisions addressing contracts formed by electronic agents.
UETA Section 14: The Electronic Agent Provision
UETA Section 14 explicitly addresses contracts formed by "electronic agents" — defined as computer programs or electronic means used independently to initiate an action or respond to electronic records without review by an individual. Under UETA § 14(2), a contract may be formed by the interaction of two electronic agents, even if no individual was aware of or reviewed the actions. The legal effect of such a contract is attributed to the persons on whose behalf the electronic agents acted.
This is the closest existing US law comes to directly addressing AI agent purchase liability. The attribution rule is clear: whoever deploys the electronic agent owns the legal consequences of its transactions. There is no exception for errors in the agent's judgment, hallucinated product choices, or misunderstood instructions.
E-SIGN Act Alignment
The E-SIGN Act reaches the same result at the federal level. Section 101(h) defines "electronic agent" consistently with UETA and makes clear that a person using an electronic agent is bound by its actions if the person had the legal capacity to enter into the underlying contract.
UCC Article 2 and Automated Purchasing
For the sale of goods — the most common category of AI agent purchases — the Uniform Commercial Code (UCC) Article 2 governs contract formation, warranties, and remedies. UCC § 2-204 allows contracts to form in any manner sufficient to show agreement. An AI agent purchasing a physical product from a merchant will typically create a binding contract under Article 2 the moment the merchant accepts the order, regardless of whether a human reviewed the specific transaction.
Warranty claims under UCC § 2-314 (implied warranty of merchantability) and § 2-315 (implied warranty of fitness for a particular purpose) still run from merchant to buyer. If the agent purchased a product that does not conform to the description or is unfit for its purpose, the buyer retains those remedies. The agent's involvement does not strip the buyer of UCC warranty rights.
Three Liability Scenarios in Practice
Scenario 1: The Agent Buys the Wrong Item
A procurement agent is instructed to reorder "office paper, A4, 80gsm." It instead orders A3 paper at higher cost because a supplier updated their catalog schema and the agent misread the product identifiers.
Under this scenario:
- The merchant has a valid contract with the buyer (electronic agent provision applies).
- The buyer is bound by the purchase but likely has a UCC § 2-601 "perfect tender" rejection right if the goods are non-conforming.
- The buyer must notify the merchant promptly and return the goods to avoid being deemed to have accepted them (UCC § 2-606).
- If the error originated from the AI platform's catalog parsing logic, the buyer may have a contractual claim against the platform depending on the terms of service.
The cleaner remedy here is commercial: most merchants will accept returns for agent-ordering errors. The legal exposure materializes when the buyer delays notification or the goods are perishable or custom-made.
Scenario 2: A Hacked or Compromised Agent
This is the scenario with the most uncertain liability exposure. A prompt injection attack, a compromised API key, or a supply-chain vulnerability in the agent's underlying model causes the agent to place unauthorized purchases — potentially large ones, potentially to fraudulent merchant accounts. Autonomous commerce security controls exist precisely to prevent this scenario, but when they fail, who is liable?
Several theories apply simultaneously:
- Payment fraud rules: If the buyer's payment credentials were used without authorization, card network rules (Visa's Zero Liability Policy, Mastercard's Zero Liability protection) may protect individual consumers. Business accounts have different — and weaker — protections under Regulation E and card network rules.
- Platform liability: If the AI platform's security failure enabled the attack, the buyer may have a breach-of-contract or negligence claim. Most platform terms of service disclaim consequential damages, which limits this recovery significantly.
- Cybercrime statutes: The Computer Fraud and Abuse Act (CFAA) provides a federal cause of action against the attacker, but collecting from an attacker is rarely practical.
The practical exposure gap is widest for business buyers using AI agents with high spending authority. Consumer protections under the Electronic Fund Transfer Act and Regulation Z (for credit cards) provide a floor; businesses above that floor have only contractual remedies, which are typically limited by platform terms.
Scenario 3: The Agent Overspends Its Budget
An enterprise deploys a travel-booking agent with a per-trip cap of $2,000. The agent books a last-minute business-class ticket at $4,800 because its optimization logic determined it was the only available flight to meet a scheduling constraint. No human approved the overspend.
Liability here is primarily internal — the deploying organization bears the cost — but it raises external questions when:
- The purchase is on a corporate card with a different credit limit than the agent's configured cap. The card issuer is owed the full $4,800 regardless of the internal cap.
- The merchant charged a non-refundable fare. UCC does not apply to services; common law contract principles govern, and the merchant's terms likely prevail.
- The agent's decision log is used in an internal audit or dispute with a travel management company.
Budget overruns are the most tractable scenario legally, but they are the most common operationally and expose organizations to significant aggregate losses when multiplied across many agent transactions.
Liability Framework Table
| Scenario | Primary Liable Party | Legal Basis | Available Remedy |
|---|---|---|---|
| Wrong item purchased (catalog error) | Buyer (bound by electronic agent) | UETA § 14, UCC § 2-204 | UCC § 2-601 rejection; contract claim against AI platform |
| Wrong item (agent hallucination) | Buyer | UETA § 14, Restatement (Third) of Agency | UCC rejection if goods non-conforming; platform ToS claim |
| Hacked agent — consumer account | Card network absorbs (Zero Liability) | Visa/Mastercard network rules, Reg Z | Chargeback; CFAA claim against attacker |
| Hacked agent — business account | Buyer (limited card network protection) | Network rules differ for commercial cards | Limited chargeback; platform negligence claim |
| Agent overspend within session | Buyer | Agency law (apparent authority) | Internal policy claim; merchant refund if timely |
| Agent overspend via exploited config | Potentially AI platform | Negligence; platform ToS | Breach of contract; limited by consequential damages cap |
| Merchant delivers non-conforming goods | Merchant | UCC § 2-314, § 2-315 | Rejection, revocation of acceptance, damages |
| Platform outage causes duplicate orders | Platform (if ToS allows) | Breach of contract | Typically capped at subscription fee |
EU AI Act Implications
The EU AI Act (Regulation (EU) 2024/1689), which entered into force in August 2024 with phased applicability through 2027, introduces a risk-based classification for AI systems that has direct bearing on AI agent purchase liability in European markets.
Risk Classification and Commerce Agents
AI systems used in commerce are not automatically classified as high-risk under Annex III of the AI Act. However, agents that access consumer credit, manage financial accounts, or make autonomous procurement decisions for regulated industries may fall into high-risk categories depending on their specific application. High-risk systems face conformity assessments, technical documentation requirements, human oversight obligations, and accuracy/robustness standards.
For AI agent purchase liability specifically, the most relevant provision is Article 9 (risk management system) and Article 14 (human oversight). Article 14 requires that high-risk AI systems be designed to allow human intervention or override. An agent that operates without any meaningful human checkpoint on individual transactions may fail this requirement — creating a compliance exposure separate from, but related to, liability for specific purchases.
Product Liability Directive Alignment
The EU's revised Product Liability Directive (PLD), applicable from December 2026, extends product liability rules to software, including AI systems. Under the revised PLD, an AI system that causes damage through a defect — including a reasoning defect that produces a wrong purchase — may expose the AI provider (not just the deployer) to liability. This is a significant shift from the current US position, where provider liability is largely contractual and heavily disclaimed.
European buyers will have a direct claim path against AI platform providers for defective agent behavior that would not exist under current US law. This asymmetry means that multinational enterprises deploying AI commerce agents need jurisdiction-specific liability analysis.
The GPAI Model Layer
The AI Act also regulates general-purpose AI (GPAI) models — the foundation models underlying most commercial AI agents. GPAI providers face transparency and copyright compliance obligations, and systemic-risk GPAI models face additional adversarial testing requirements. When a foundation model's behavior causes an agent to make a wrong purchase, the liability chain potentially extends upward to the GPAI provider, though the practical allocation of this liability between GPAI provider, agent developer, and deployer is not yet settled.
US Law Gaps
Three gaps in US law create the most practical uncertainty for AI agent purchase liability:
1. No Federal AI Liability Statute
The US has no equivalent to the EU AI Act's liability provisions. State-level AI legislation (Colorado SB 24-205, Texas HB 1709) focuses on high-risk AI in employment and credit decisions, not commerce. Federal bills have been introduced but not enacted. Until Congress acts, liability is determined by the patchwork of state agency law, UCC, and platform contract terms.
2. Business Payment Fraud Protections Are Weak
Regulation E's protections for unauthorized electronic fund transfers apply to consumer accounts. Business accounts are governed by UCC Article 4A (for wire transfers) and card network rules for card payments, which provide significantly less protection. An enterprise using an AI agent with corporate card credentials that is compromised faces much higher out-of-pocket exposure than a consumer in the same scenario.
3. Platform Terms Disclaim Too Much
Most AI platform terms of service include broad disclaimers of warranties, limitations of liability to subscription fees paid, and exclusions of consequential damages. These terms are generally enforceable in commercial contracts between sophisticated parties. The result is that when an AI agent causes significant purchase errors due to platform defects, the buyer's contractual recovery is often nominal. This gap is not unique to AI — it mirrors the limitation-of-liability landscape for SaaS generally — but the autonomous and high-frequency nature of agent transactions makes the exposure larger.
How Payment Networks Handle Agent Chargebacks
The chargeback process was built for disputes between human cardholders and merchants. Visa's dispute resolution framework and Mastercard's Chargeback Guide define reason codes, documentation requirements, and timelines. Neither framework has been formally updated to address AI agent transactions.
Understanding AI agent payment APIs is essential context here: most agents transact using stored card credentials, virtual cards, or tokenized payment methods issued by providers like Stripe. How the payment instrument is classified — consumer card, commercial card, or business debit — determines which dispute protections apply.
Consumer Card Disputes
For consumer credit cards, Regulation Z (Truth in Lending Act) provides a statutory right to dispute unauthorized charges and billing errors. "Billing error" under Reg Z § 226.13 includes charges for goods not delivered as agreed. If an AI agent buys the wrong item and the merchant refuses to resolve it, a consumer cardholder can file a billing error dispute. The card network chargeback process (Visa reason code 13.3, "Not as Described") is the operational mechanism.
The complication: if the consumer explicitly authorized the agent to make purchases and the agent made an authorized-but-wrong purchase, it is not an "unauthorized transaction" under Reg Z. The cardholder authorized the agent; the agent made a bad choice. That is a contract dispute with the merchant, not a card network dispute.
Commercial Card Disputes
Visa and Mastercard treat commercial card chargebacks differently. While both networks offer chargeback rights for commercial cards, the Zero Liability protections that consumers enjoy do not automatically extend to commercial accounts. Card issuers have more discretion to deny commercial chargebacks, and the documentation requirements are more onerous.
Stripe's documentation for business card programs notes that commercial card dispute outcomes depend on the issuer's specific program terms, not just network rules. Enterprises relying on Stripe Issuing or similar platforms to provision agent payment cards should review issuer-level dispute policies, not just network-level rules.
Merchant Perspective: Chargeback Liability
Merchants face chargeback liability when disputes are upheld. Because agent-initiated transactions cannot always be distinguished from human-initiated ones at the merchant's end, merchants have limited ability to pre-screen for agent-specific risk. Merchants that adopt autonomous commerce security signals — agent certificates, verified caller identity, structured order metadata — may be better positioned to contest chargebacks by demonstrating the buyer authorized the agent.
How Merchants Limit Liability
Merchants deploying their own purchasing agents, and merchants receiving orders from buyer agents, can take practical steps to limit their liability exposure:
- Terms of Service Updates: Explicitly address AI agent purchases in terms of service. Specify whether orders placed by automated systems are binding, what documentation is required to dispute an agent-initiated order, and what the return window is for agent-ordered goods.
- Order Confirmation Loops: Require a human confirmation step for orders above a threshold value before fulfillment begins. This limits the scope of the "wrong item" scenario by catching errors before goods ship.
- Structured Order Metadata: Accept and log agent identity metadata (agent version, session ID, authorization token) with each order. This creates an audit trail that supports or defeats chargeback claims.
- Liability Caps in B2B Contracts: When contracting with enterprise buyers known to use procurement agents, include explicit liability caps for agent-initiated order errors and specify dispute resolution procedures.
How Buyers Limit Exposure
Buyers deploying AI purchasing agents have more control over their exposure than they often realize. The key levers are authorization scope, spending controls, and contractual protections:
- Define and Document Agent Authority: Create a written authorization document specifying what the agent is permitted to buy, from which vendors, up to what amounts, and under what conditions. This document serves as evidence of the agent's actual authority and limits apparent authority claims by merchants for out-of-scope purchases.
- Use Scoped Payment Credentials: Rather than providing an AI agent with full corporate card access, use virtual cards with per-transaction and aggregate spending limits. Stripe Issuing and similar platforms allow issuance of virtual cards with category restrictions, merchant locks, and spending caps that enforce the authorization document at the payment layer.
- Implement Spending Guardrails at the Platform Level: Most enterprise AI platforms support tool-level permission systems. Configure purchasing tools with hard spending limits that cannot be overridden by model outputs. This limits overspend exposure even if the agent's reasoning goes wrong.
- Negotiate Platform Liability Terms: For enterprise deployments, negotiate the AI platform's standard limitation-of-liability clause. Seek carve-outs for gross negligence and security failures that expand recoverable damages beyond the subscription fee cap.
- Log Everything: Maintain immutable logs of agent instructions, tool calls, and transaction outcomes. These logs are essential for UCC rejection notices (which require prompt notification), chargeback documentation, and internal audit trails. Without logs, proving what the agent was authorized to do — and what it actually did — is extremely difficult.
Frequently Asked Questions
Is an AI agent legally considered an agent under US law?
Not formally. US courts have not granted AI systems legal personhood or recognized them as agents in the traditional sense. However, UETA Section 14 and the E-SIGN Act both address contracts formed by "electronic agents" and attribute their actions to the person on whose behalf they act. The practical liability outcome is similar to agency — the deployer is bound — but the agent itself has no legal standing.
Can I get a chargeback if my AI agent bought the wrong item?
It depends on the payment instrument and the nature of the error. If the purchase was genuinely unauthorized (for example, due to an account compromise), standard card network dispute processes apply. If the agent made an authorized-but-wrong purchase, you are typically in a UCC contract dispute with the merchant, not a card network dispute. Consumer credit cards offer more protection than commercial cards in either scenario.
Does the EU AI Act create a direct liability claim against AI providers?
Not directly under the AI Act itself for commerce transactions. The AI Act imposes compliance obligations; it does not create private rights of action for individual purchases. However, the revised EU Product Liability Directive (applicable from December 2026) does allow buyers to claim against AI system providers for defects in AI software, including reasoning defects that cause wrong purchases.
What spending controls should I put on an AI purchasing agent?
Use scoped virtual cards with per-transaction limits, daily aggregate caps, and merchant category restrictions. Enforce these at the payment API level — not just in the agent's prompt or configuration — because payment-layer controls cannot be overridden by model outputs or prompt injections.
Who is liable if a hacked AI agent makes fraudulent purchases?
The legal picture is complicated. If consumer card credentials were used, card network Zero Liability policies typically cover the cardholder. For business accounts, protections are weaker and the deploying organization may bear the loss unless it can establish a negligence claim against the AI platform. In all cases, the actual attacker is liable under CFAA and state computer crime statutes, though collection is rarely practical.
Do merchants have to accept returns from AI agent purchase errors?
Merchants are generally not required to accept returns beyond their standard return policy. For goods, UCC § 2-601 gives buyers a right to reject non-conforming goods, but the buyer must act promptly and provide adequate notice. For services and digital goods, common law contract principles and the merchant's terms govern. Merchants that explicitly address agent purchases in their terms of service have greater certainty about their obligations.
How does principal-agent doctrine limit liability for out-of-scope agent purchases?
If an agent acts outside its actual authority and the merchant was not reasonably misled into believing it had authority (no apparent authority), the principal may not be bound. However, if the principal provided the agent with payment credentials and API access that led the merchant to reasonably believe authority existed, apparent authority may still bind the principal. Documented authorization limits are the primary defense.
Will US law eventually catch up to the EU AI Act on agent liability?
Practitioners expect federal AI legislation, but timing is uncertain. In the interim, the FTC has signaled interest in AI-related consumer harms, and state attorneys general in California, Texas, and New York have investigated AI commerce issues under existing consumer protection statutes. The practical near-term path for US buyers is contractual: negotiate liability terms with AI platforms rather than relying on statutory protections that do not yet exist.
This article is practitioner analysis for informational purposes only. It does not constitute legal advice. Consult qualified legal counsel for guidance on specific AI agent purchase liability questions.