Who Is Liable When Software Spends?
Here is the question that ends most agentic-commerce conversations the moment it is asked: an autonomous agent buys the wrong thing, or buys the right thing at the wrong price, or is tricked into paying an address it should not have. Who is responsible? The user who deployed it? The company whose model it runs on? The merchant who accepted the payment? The developer of the agent framework? The answer today is a shrug, and a shrug is not a foundation you can build a market on.
Identity and liability are the two problems that separate a demo from an economy. A demo needs an agent that can pay. An economy needs to know whose agent it was, what it was allowed to do, and who is on the hook when it does something else. These are not engineering details to be solved later. They are the load-bearing walls. Skip them and you do not get a faster economy; you get a faster way to lose money with no one to call.
Start with identity, because liability depends on it. A merchant accepting a payment from a human relies on a stack of assumptions: a name, a card, an issuing bank, a fraud system, a chargeback path. An agent arrives with none of that by default. It is software holding a balance. For the agent economy to function, an agent needs a verifiable identity that answers three things at the moment of payment: who deployed me, what am I authorized to do, and up to what limit. This is the domain of decentralized identifiers and verifiable credentials, of attestations that travel with the agent and can be checked without calling a central authority. The technology exists. What is missing is the agreement on how to use it, and the legal weight to make the answers binding.
Then liability, which is where law has to catch up to software. Today's frameworks assume a human principal who authorizes each act. Agentic payment breaks that assumption in two places. The agent acts continuously, so consent cannot be per-transaction; it has to be delegated in advance, scoped, and revocable. And the agent can act in ways its principal never specifically intended, which is the entire point of delegation and also its central risk. A workable model looks less like a card authorization and more like a power of attorney for software: a delegation with explicit scope, explicit limits, an audit trail, and a clear allocation of who bears the loss when the scope is exceeded versus when it is honored and the outcome is still bad.
None of these are questions a payments protocol can answer on its own. A protocol can carry an authorization token. It cannot decide whether that token shifts liability from the user to the platform, or what a regulator will accept as valid consent, or how a court will read a transaction that no human specifically approved. Those are legal and structural questions, and they will be answered jurisdiction by jurisdiction, by whoever does the work of mapping new behavior onto existing law and then arguing, persuasively, where the law must extend.
This is the part of agentic commerce that rewards firms who have lived at the seam of technology and regulation rather than on one side of it. The teams that understand both how an attestation is constructed and how a Korean or US regulator will treat a delegated, autonomous payment are rare, and they are the ones who will set the terms others operate under. The standard for agent identity and the allocation of agent liability are being drafted now, in protocol specifications and in the first regulatory responses to them. Whoever shapes that early gets to shape the market that runs on top of it.
The agents are learning to spend. Before that becomes an economy rather than a liability, someone has to answer who they are and who pays when they are wrong. That answer is not a feature. It is the market's permission to exist.
General commentary, not legal advice. Legal services are provided solely by AXIS Law.