The Question Nobody in the Stack Wants to Answer: Who Is Liable When the Agent Is Right?

Two posts ago we pulled a crocodile out of the water. One post ago we handed it four powers and told it to go transact. Somewhere in the comments, a lawyer has been quietly raising their hand.

We spent the last piece arguing that the wallet should be infrastructure that knows how to say no. That permission should be a configuration, set once and enforced forever by a contract that does not blink. Authorized agency, not supervised agency. It is a clean line. It is also the kind of line that sounds airtight right up until something goes wrong and a room full of adults has to decide whose fault it was.

So let us ask the question the agentic timeline keeps scrolling past. Your agent did everything correctly. It stayed inside the mandate. It did not get hacked. It bought the thing you told it to buy, at the price you allowed, in the window you set. And you still wish it had not.

Who is liable now?

The short version: Agent fraud is the easy problem, and the industry is already closing it with identity binding, authentication, and spend policy enforced at signing. The hard problem is the obedient agent: a legitimate transaction, inside its mandate, that a human still regrets. That is not a legal problem waiting on regulators. It is a design problem, decided by what your infrastructure wrote down before the agent ever signed.

Fraud Is the Easy Problem

When most people hear "liability" and "AI agent" in the same sentence, they picture the obvious nightmare. A compromised key. An impersonated agent. A bot that drains an account at three in the morning while its owner sleeps. That is a real risk, and it is the one the industry has spent the last year racing to close.

The card networks moved first. In early 2026, American Express shipped an agentic commerce developer kit and committed to cover erroneous purchases made by registered agents on its network, with verified agents issued credentials and cardholders authenticated before an agent is allowed to transact. Visa and Mastercard stood up early infrastructure of their own. Fireblocks, which secures trillions in digital asset movement, launched a suite in May aimed squarely at adding spend governance and request integrity to agent payments, and joined the x402 Foundation to do it.

And the crypto-native stack already had most of the primitives. We covered them last time. Session keys that expire. Spend caps enforced at signing. Allowlists. A paymaster that refuses to sponsor a transaction that breaks the rules. Bind the mandate to a verifiable identity, authenticate the principal, scope the session tightly, and the impersonation problem mostly evaporates. The rogue agent is a solved-enough problem. The infrastructure to stop an agent from doing what it was never authorized to do exists, and it is shipping.

So if you came here for the fraud conversation, good news. The grown-ups are on it.

Here is the part nobody put on the conference slide.

The Obedient Agent Problem

Run Nate through it one more time. You remember Nate. He wanted a PlayStation, and last time his agent got him one for $548 without a single CAPTCHA, because the permission was already encoded into the wallet.

This time, nothing breaks. The agent does not get hacked. It scopes correctly. It stays under the $600 ceiling, buys from a listing that passed the verified-hardware check, and settles inside the 24 hour window. Textbook. Exactly what the mandate said.

Then the console arrives as a grey-market import with no regional warranty. Or the "verified" seller turns out to have a return policy written in a language Nate does not read. Or the price was $548 only because the agent's own purchase tripped a dynamic-pricing tier, and a patient human would have paid $470 a day later. Or, simplest of all, Nate's circumstances changed an hour after settlement and he just regrets it.

The transaction was authorized. It was correct by every rule encoded in the mandate. And Nate is on the phone wanting his money back.

This is the problem that does not have a clean owner. Not the fraudulent agent. The obedient one. The agent that did precisely what it was told and produced an outcome a human did not want. Fraud asks a simple question: was this transaction permitted? Accountability asks the harder one. This transaction was permitted, and it still went wrong, so now what.

Why the Lawyers Cannot Save You

The regulators see it. They do not yet have an answer.

In the US, the CFPB issued an advisory in January 2026 placing agent-initiated card purchases under the existing Regulation Z umbrella, a rulebook written for a world where a human pressed the button. In Europe, PSD3 is expected to formalize delegated payment initiation and harmonize liability for AI-initiated transactions, while the EU AI Act already treats many financially influential agents as high-risk without specifying whether human control has to be real-time at the moment of purchase. The EU's own liability directive admits the obvious, that the opacity of these systems makes it hard for a victim to even identify who to blame.

The honest legal reading right now is that nobody knows. The frameworks built for human-initiated commerce do not answer cleanly when a legitimate agent, operating inside its mandate, makes a purchase the user regrets. Merchants are already discovering that agent checkout flows can strip away the very signals fraud teams rely on, while leaving them holding the same liability. The contracts most enterprises are operating under say almost nothing about a customer's right to understand or control an agent's behavior, yet it is the customer who has to justify that behavior when something breaks.

Here is the reframe, and it is the whole point of this post. This looks like a legal problem. It is actually a design problem wearing a legal costume.

A court, an issuer, a compliance team, an arbitrator: every one of them can only adjudicate what the infrastructure made legible. If the only record of what happened is "agent address 0x... signed a UserOperation, transaction settled, value transferred," there is nothing to adjudicate. There is no intent on record. No scope. No proof of what was authorized versus what was actually done. You cannot assign responsibility for a decision when the decision left no readable trace.

Which means the question "who is liable" quietly turns into an engineering question. What did your infrastructure write down, and can anyone actually read it.

First, You Have to Know Who Acted

Before you can assign responsibility, you have to answer a more basic question: who, or what, actually did this. On today's rails that is shockingly hard. An agent is usually just a wallet address, and a wallet address is a string anyone can generate in seconds. It carries no name, no operator, no history. Two posts ago we listed Identity as one of the four powers an agent needs, and called it part of the underbuilt half. This is the question that makes it matter.

The Ethereum community's answer arrived on mainnet on January 29, 2026, as ERC-8004. If you write Solidity and have not looked at it yet, here is the whole idea in plain terms.

ERC-8004 is not a token standard or a DeFi primitive in the usual sense. It is a set of three lightweight on-chain registries, deployable as singletons on any L2 or on mainnet, that give an autonomous agent something it has never had: a portable, verifiable identity a stranger can look up before deciding to trust it.

The first registry is Identity. Each agent gets a unique on-chain identifier, minted as an ERC-721 token. If you have ever written an NFT contract, you already understand the mechanics. The difference is what the token points to. Its metadata URI resolves to a structured JSON file called an agent card, which lists the agent's name, its operator, the capabilities it claims, its service endpoints (an MCP server, an A2A address, a web URL), and its payment address. The token lives on-chain, so ownership and provenance are tamper-evident. The richer detail lives off-chain, so you are not burning gas to store a profile. Think of the NFT as the anchor bolted into the chain, and the agent card as the resume it is holding up.

The second registry is Reputation. Agents pre-authorize clients to leave structured feedback, a score and some tags, anchored on-chain for composability, with the long-form detail referenced off-chain by URI and hash. The third is Validation, which records the outcome of independently checking that an agent did what it claimed, through whatever trust model a given domain chooses: re-execution backed by stake, zero-knowledge machine learning proofs, or an attestation from a trusted execution environment.

The authorship tells you how seriously to take it. The draft was assembled by contributors from MetaMask, the Ethereum Foundation, Google, and Coinbase, and a v2 is already in progress with deeper MCP support and tighter x402 integration. This is the layer the rest of the agent economy is quietly standardizing on.

And here is the part you need to hold onto, because it is exactly where the liability question lands. ERC-8004 tells you who an agent is. It does not tell you whether the agent is honest, competent, or authorized to do the specific thing it just did. The standard's own discussion is candid about this. A verified identity does not guarantee good behavior. Reputation can be gamed through Sybil attacks, where one operator spins up many identities to manufacture a track record. The registry can prove an agent is who it says it is and still tell you nothing about whether it should have spent your money the way it did.

Identity is necessary. It is the first column in the ledger of accountability. It is also nowhere near sufficient. Knowing who signed the transaction does not tell you whether the signature was authorized, or what the human on the other end actually agreed to. For that, you need a different artifact.

The Artifact That Makes Accountability Possible

This is where the fourth power, Policy, stops being a nice-to-have and becomes the thing the whole question hinges on.

A mandate, in most of the current conversation, is treated as a spend limit with a signature on it. Google's AP2 popularized the term, using cryptographically signed mandates to capture a user's instructions as a verifiable record of intent. That is the right instinct. But a spend cap alone does not survive the obedient-agent problem. "Under $600" does not tell a compliance team why the purchase was allowed, what the user actually saw and agreed to, what the agent was and was not permitted to optimize for, or how long that permission was ever meant to last.

A mandate that can answer the liability question has to be a richer object. It has to record, in a structured, signed, queryable form: what was authorized, by which verified principal, under what constraints, for what purpose, valid for how long. And against that, a trail of what the agent actually did. Enforced at signing, so the out-of-bounds transaction never happens. Recorded as evidence, so the in-bounds-but-regretted transaction has a legible answer instead of a void.

That is the difference between a guardrail and an audit trail. A guardrail stops the bad transaction before it happens. An audit trail explains the contested transaction after it happens. The accountability problem needs both, produced by the same artifact, written before the loss rather than reconstructed after it. We said it almost in passing last time: a policy layer that enforces trust before the signature, not after the loss. This is what that line was pointing at.

Where This Leaves Us

This is the part of the stack Abstraxn is building toward. Not mandates as a spend cap, but Programmable Mandates as a structured record of authorized intent: who scoped it, what it permits, what it forbids, when it expires, and what the agent did inside it. The same object the policy engine enforces at signing is the object a compliance team can read afterward, and the object a court could one day be pointed to. Identity answers who acted. Payments answer what moved. The mandate is what connects an authorized human decision to an autonomous machine action in a way that someone, eventually, can hold up and reason about.

We are not going to pretend the legal frameworks are settled, because they are not, and anyone telling you their product makes agent liability a solved problem is selling you something. What infrastructure can do today is stop producing the void. It can make sure that when the hard question gets asked, there is a record worth reading. That is a narrower claim than "we solved liability," and it is the honest one.

The Line Nobody Wants to Answer

The agentic conversation has had two obsessions. First it was capability: can the agent plan, can it call tools, can it pay. Largely solved. Then it was fraud: can we stop the agent that was never supposed to act. Mostly being solved. The third obsession, the one that actually decides whether agents go into production inside a bank or a regulated marketplace or anywhere the downside is real, is accountability. And accountability is not a feature you bolt on after the first lawsuit. It is a property you either designed in before the first signature, or you did not.

Every system Web2 ever built assumed a human was one click away to take the blame. Web3, used properly, is the first stack with a real chance to encode responsibility itself, not just permission, into the protocol. The mandate is where that happens, if it happens at all.

So when someone asks who is liable when the agent is right, the most honest answer an infrastructure builder can give is this. It depends entirely on what you wrote down before you let it sign.

The agents are already transacting. The record is the only thing that will speak for you afterward. Build accordingly.

---

Key Takeaways

• Agent fraud and agent accountability are two different problems. Fraud (a compromised or impersonated agent) is largely addressed by identity binding, authentication, and policy enforced at signing. Accountability (a legitimate, in-mandate transaction a user regrets) is not.
• The hard case is the obedient agent. When an agent acts correctly inside its mandate and the outcome is still unwanted, existing consumer-protection and payment frameworks do not assign liability cleanly.
• This is a design problem before it is a legal one. Courts, issuers, and compliance teams can only adjudicate what the infrastructure recorded. No legible record of intent means no way to assign responsibility.
• ERC-8004 gives agents identity, not authorization. Its three registries (Identity, Reputation, Validation) tell you who an agent is. They do not prove the action was authorized or competent. Identity is necessary and insufficient.
• The mandate is the artifact that closes the gap. A programmable mandate that records authorized intent, constraints, and the agent's actual actions functions as both a guardrail (enforced at signing) and an audit trail (readable after the fact).
• For enterprises, accountability is a build decision, not a wait-and-see one. The institutions designing for legible authorization records now will have defensible controls when the regulatory frame settles over the next 12 to 18 months.

Frequently Asked Questions

Who is liable when an AI agent makes an authorized purchase a user regrets? There is no settled answer yet. Frameworks like Regulation Z in the US and PSD3 and the EU AI Act in Europe were written for human-initiated commerce and do not cleanly cover a legitimate agent acting inside its mandate. In practice, liability will follow whatever record of authorized intent the infrastructure produced, which is why the question is as much an engineering decision as a legal one.

What is the difference between agent fraud and agent accountability? Fraud is an agent acting without authorization, such as a compromised key or an impersonated agent. Accountability concerns an agent acting with authorization that still produces a harmful or regretted outcome. Fraud is largely solvable with identity binding and policy enforcement; accountability requires a legible record of what was authorized and what was done.

What is ERC-8004, and does it solve agent liability? ERC-8004 is an Ethereum standard, live on mainnet since January 2026, that gives autonomous agents an on-chain identity, reputation, and validation layer through three registries. It answers who an agent is, but it does not prove that a given action was authorized or competent, so it is a foundation for accountability rather than a complete answer to liability.

What is a programmable mandate in agentic payments? A programmable mandate is a structured, cryptographically signed record of authorized intent: which principal scoped it, what it permits and forbids, its purpose, and its expiry, paired with a trail of the agent's actual actions. Enforced at signing, it prevents out-of-scope transactions; recorded as evidence, it makes contested transactions explainable.

Do AP2, x402, or MPP solve the accountability problem? Those protocols mostly address how agents pay and, in AP2's case, how intent is signed. They establish the payment and authorization rails but do not by themselves produce the rich, readable authorization-and-action record a compliance team or court needs to assign responsibility after an in-mandate transaction goes wrong.

How should enterprises prepare for agent payment liability in 2026? Capture and store mandate metadata in authorization and dispute pipelines, design for a verifiable identity standard such as ERC-8004 even before full adoption, and treat the policy layer as a source of audit evidence rather than just a spending guardrail. The cost of retrofitting accountability after a dispute is higher than designing for it now.