When an AI agent transacts on behalf of a human or corporate principal and something goes wrong (wrong payee, wrong amount, fraudulent counterparty, agent malfunction), the operational question of who handles the dispute and who bears the loss is unresolved across every major rail and every major insurance market. This is distinct from the legal-counterparty question covered in Regulatory perimeter for agents, which addresses whether the principal is bound by the agent's act. The dispute and insurance layer addresses what happens after that legal answer is in: which institution adjudicates, on what evidentiary basis, and which insurer (if any) reimburses. The page consolidates the dispute and insurance dimensions currently mentioned in passing across Foundations Chapter IX, Part 4 and Part 5, and surfaces the question structure rather than answers, because the answers are still forming. The market for specialised agentic-commerce insurance is genuinely nascent and there is no public underwriting data yet to anchor against.
The four dispute categories
Useful to keep them named and separate. Most published commentary collapses them into "agent disputes," which obscures that each has a different operational owner and a different insurance posture.
Wrong-payee disputes. The agent paid the wrong merchant. The instruction was sound; the routing or merchant resolution was not. The reverse-route question is the operational one: can the rail unwind the transaction, and on what authority. On bank rails the bank's existing reversal mechanics apply with the wrinkle that the original instruction came from an agent rather than a human. On chain-native rails the answer is typically no for finalised settlement and depends on the issuer's posture for pre-finalisation revocation.
Wrong-amount disputes. The agent paid more than instructed. The principal authorised up to a cap; the agent exceeded it through a reasoning error, a unit conversion error, or a prompt-injection-driven scope expansion. The over-spend question is whether the rail offers any pre-settlement revocation, whether the merchant cooperates in a partial refund, and whether the principal can recover the over-payment from the agent's developer if the malfunction was foreseeable.
Fraudulent-counterparty disputes. The merchant the agent paid was a fraudster (a spoofed website, a fake invoice, a synthetic merchant in a card programme). The chargeback question turns on whether the rail offers a chargeback mechanism, what evidence the cardholder or principal must present, and whether the dispute apparatus has been built to accept agent-instruction logs as evidence.
Agent-malfunction disputes. The agent's instructions to the rail were wrong because of an upstream model failure: hallucination, training-data poisoning, prompt-injection attack, scope creep in pursuit of a higher-order goal. The product-liability question runs to the agent's developer rather than to the rail. The case law is essentially absent; the doctrines have answers in principle (negligence, foreseeability, mitigation) but the precedent has not been set.
Who handles each category today
Wrong-payee on a bank rail runs through the bank's existing dispute process. The rail's reversal mechanics, the bank's customer-service triage, and the receiving bank's cooperation are the relevant operational pieces. The novel piece is the evidentiary record: the bank needs the full agent-instruction log (the instruction text the principal gave, the resolved merchant identity the agent acted on, the timestamp, the authentication state at the time of the act) to determine where the error sits.
Wrong-amount on the x402 rail or any chain-native settlement rail depends on settlement timing. Pre-settlement, protocol-level revocation may be available depending on the asset (USDC has issuer freeze; Project Orchid PBM structures permit conditional reversal at the contract level). Post-settlement, the principal's recourse is a civil claim against the merchant for the overpayment plus, if applicable, a separate claim against the agent's developer for the underlying malfunction.
Fraudulent-counterparty on the Visa Intelligent Commerce or Mastercard Agent Pay rail runs through the existing card-network chargeback rules. The cardholder remains the legal principal and the chargeback claim runs in the cardholder's name. The novel evidence is the agent-instruction log; whether the network's dispute apparatus accepts the log as adequate proof of the cardholder's intent (or lack of it) is one of the unresolved operational questions both networks have flagged but not formally answered.
Agent-malfunction is the open one. The doctrinal frame is product-liability against the developer of the agent, with foreseeability and mitigation as the load-bearing tests. Whether the developer is treated as having shipped a product (one-time sale liability) or a service (continuing-duty liability) is unresolved. The first major case will set the pattern for several years.
Insurance coverage today
Three layers, each at a different stage of maturity.
The bank's existing fraud-and-error coverage typically extends to agent-mediated transactions if the agent operates under an authenticated customer credential. The principal's authentication is the load-bearing piece: if the customer authenticated to the bank and granted authority to the agent through the bank's documented onboarding pathway, the bank's existing operational-loss policies and the deposit-insurance backstop apply. If the agent operates only under its own credential without persistent customer authentication, coverage gets thin.
The agent developer's professional-liability or errors-and-omissions cover is the second layer. The market is nascent. A small number of commercial insurers have begun underwriting general AI errors-and-omissions policies through 2025 and into 2026, but specific agentic-commerce coverage (dollar liability for agent-driven misrouted payments) is not yet a standard product line. The page does not name specific products because the disclosure is too thin to anchor against.
Specialised agentic-commerce coverage is the third layer and the most speculative. Insurers are exploring per-transaction caps, per-agent-deployment caps, and reinsurance-backed pool structures as the market develops. None of this has settled into a recognisable product category. We treat this as a market-formation question and track it through industry coverage rather than treating any specific product as load-bearing.
What institutions should design for
Concrete operational guidance for tokenisation product teams shipping anything that touches agent-mediated flows.
Logging. Capture the full agent-instruction provenance for every transaction. Instruction text, model used, parameters, timestamp, customer authentication state. The record is what every dispute apparatus and every insurer will demand if the transaction is later contested. Retain for the longer of the rail's record-retention requirement and the limitation period for civil claims in the relevant jurisdiction.
Authentication. Customer authentication must persist through the agent layer rather than being delegated wholesale at onboarding. Agent-only-authenticated transactions (where the principal signed off once and the agent authenticates to the rail thereafter) are operationally fragile. Re-authentication on novel counterparties, on unusual amounts, and on category-of-payment changes is the design pattern that survives a contested dispute.
Limits. Per-transaction, per-day, per-merchant-category, and per-novel-counterparty caps are the table stakes. Threshold breaches should require explicit human re-confirmation rather than agent-autonomous override. The cap structure is also the lever an insurer will use to scope coverage; tight caps with documented breach handling are more underwritable than loose authority with discretion.
Insurance. Confirm with the institution's existing insurer that fraud-and-error coverage extends to agent-mediated transactions under the contemplated authority model. If it does not, obtain a specific endorsement or accept the residual exposure on the institution's own balance sheet. Do not assume coverage by inference.
Open questions
The first major dispute (a high-profile agent-malfunction-causes-financial-loss case) has not yet occurred publicly. The precedent will be set by whichever case lands first and in which jurisdiction. The case could surface in retail (a personal financial agent overspending on behalf of a household), in corporate treasury (an agent misrouting a payable), or in machine-to-machine settlement (an agent overpaying an API in a runaway loop). Each would shape underwriting and product-liability doctrine differently.
The cross-jurisdictional dispute-resolution question is unsettled. An agent in jurisdiction A acting for a customer in jurisdiction B paying a merchant in jurisdiction C creates a conflict-of-laws question on which substantive law governs the principal-and-agent relationship, which forum hears the dispute, and which insurer's policy responds. None of the published agent-mediated payment products has a documented answer.
Whether any major regulator publishes operational guidance on dispute-handling specifically (rather than the broader regulatory perimeter) is open. MAS and the HKMA are the most likely candidates given the production tokenised-deposit work in each jurisdiction; the European Banking Authority is a candidate through MiCA implementation guidance; the US bank regulators (OCC, Federal Reserve, FDIC) could speak through GENIUS Act implementation rules.
Related
- Regulatory perimeter for agents
- x402: HTTP-native payment rail for agents
- Visa Intelligent Commerce and Mastercard Agent Pay
- Foundations Chapter IX, Part 1: Definition
- Foundations Chapter IX, Part 4: Regulatory accommodation and confusions
- Foundations Chapter IX, Part 5: Production and open questions
- Approaching agentic commerce