Your agent paid. Now you say, “It wasn't me.”

The payment went through. The customer says they never authorized it.

Now what?

Imagine a customer asks an agent to research equipment for a home office. Later, a purchase appears on their account. They call the merchant and say, "I wanted recommendations. I didn't tell it to buy anything." The merchant has an order confirmation. The agent provider has a conversation history. The payment provider has a transaction record.

Each may have part of the answer. Someone has to establish how those parts fit together.

"It wasn't me" can describe several very different problems. Treating all of them as the same problem is how you end up investigating the wrong thing. Here’s a few examples of this:

• Someone may have impersonated the customer.
• A legitimate agent may have acted beyond its permission. The customer may have authorized one purchase while a system executed another.
• There may also be a disagreement about what was delivered.
• There may be a dishonest denial of a purchase that was authorized.

You need evidence to distinguish those situations. An agent's involvement adds another place where the instruction and the outcome can diverge. A verifiable record should help you find that point, rather than force every participant to defend its own version of events.

You can't enforce permission you never recorded.

Suppose your operating rules says an agent must stay within its owner's spending limit. Where is the limit written down? If the answers is, “it’s in agent's conversation history,” everyone downstream is taking the agent’s word for it. Operating rules that assign responsibility in a dispute scenario need a record of what that permission actually was.

Now the rule has something to work with. The owner approved $500. The agent requested $2,000. The merchant accepted it. You can identify where the request crossed the boundary and which participant was responsible for checking it. For operating rules to be effective in agentic scenarios they must be a do few things:

• Records need to bind the verified owner to the approved action and its terms. This includes the item, amount, recipient, any limits on the agent's authority and the checks performed by the systems that accepted it.
• The record has to survive the journey. From the owner's approval, through the agent, through intermediaries, to the business executing the request, each receiving system should be able to verify the signed record. Permission cannot turn into somebody else's AI chat history summary halfway through the stack.
• The approved terms must remain fixed. Cryptographic signatures make changes detectable: alter the amount, substitute the recipient, or rewrite the instruction, and the altered content will fail verification against the original signature. An AI cannot quietly rewrite the approval and pass it off as the same signed record.

That is the property we need from an immutable approval record. Corrections or new permissions require a new signed record. They don't overwrite what the owner previously agreed to. Preserve the original and the evidence of verification so another party can examine them later.

Proof's Sign Transactions binds a verified person's identity to specific transaction terms. Verification checks those terms against the signed record, the holder's signature, and the certificate chain. For delegated actions, the evidence also needs to connect the agent's execution to the owner's mandate.

This record gives operating rules something concrete to evaluate before a request is accepted, and something concrete to investigate when it is disputed.

Someone has to bear the loss.

The customer wants their money back. The merchant wants to keep the payment. The agent provider says its software followed instructions.

So, who pays?

Payments has established rules for this. For qualifying Visa transactions, fraud liability can shift from the merchant and its acquiring bank to the card issuer. Eligibility depends on the program's authentication and processing requirements. A completed payment alone doesn't earn that protection. ACH has its own rules for authorization warranties and returns, including distinctions between a debit that was never authorized and one that exceeded the authorization's terms.

Agentic commerce needs equally explicit rules. Who verifies the owner? Who authorized this? Who checks the mandate? Who bears the loss?? "The AI agent made a mistake" doesn't answer any of those questions.

Good rules protect a business that checked valid authority and fulfilled the agent’s request, while assigning loss to a participant (ie. the person, the agent, the merchant or the bank) that breached its agreed duties. This must be established through rules and contracts, consistent with applicable law. A signature doesn't create it automatically.

Now imagine the dispute isn't about a purchase.

"I asked AI to compare insurance. I never applied for that policy."

"I wanted to know what I could borrow. I never applied for that loan."

"I never ordered that prescription. Who told the pharmacy to fill it?"

Now what?

A refund may be only part of the problem. Someone has submitted personal information, made representations on the owner's behalf, or set a consequential process in motion. The business needs to establish what the owner approved, what the agent submitted, and what it did in response.

Agentic operating rules have to cover how a dispute moves: who receives the claim, which records each participant must produce, how fast they must respond, and who resolves disagreements. Getting the customer a remedy and deciding who ultimately pays are two different jobs.

Operating rules must also define how a dispute moves: who receives the claim, which records participants must produce, how quickly they must respond, and who resolves disagreements. Getting the customer a remedy and deciding which participant ultimately pays are both part of the job. You need explicit rules for what happens when a business relies on that credential to act on someone's behalf.

For example, a mobile driver's license can help establish identity. The DMV doesn't decide who pays when an agent submits an unauthorized loan application. That takes an industry framework of responsibilities and recourse, built into network operating rules.

Those rules must reach beyond payments. Applying for a loan, ordering a prescription, signing an agreement, filing an insurance claim, or submitting a benefits application each creates a different set of responsibilities. Operating rules coupled with an identity network will address disputes with verifiable records that let participants establish whether the rules were followed.

That is Proof's vision: trusted identity, verifiable permission, and a network that defines what relying on them means. Before a business accepts an agent's request, it should know what it must check, what evidence it must keep, and who stands behind the transaction if it is challenged.

The liability question starts as soon as the agent does something on someone's behalf.

Inspect how Proof binds identity to transaction terms.