The Agent Paid. Did it Obey its Mandate?

When I read that Visa, Mastercard, Ripple, and a growing number of payment infrastructure companies were joining the x402 effort, I felt two things at the same time.

Author: JJ

July 30, 2026

The first was excitement.

The second was the faint unease that arrives when a technical idea stops being speculative and begins acquiring lawyers, working groups, corporate logos, and a foundation.

Until recently, the idea of an AI agent paying for something sounded like a demonstration you might watch at a conference. The agent would locate a service, send a little stablecoin, retrieve some data. Everyone would applaud. Then someone would close the laptop and the world would return to its ordinary business of subscriptions, credit-card forms, API keys, invoices, procurement departments, and Jenny in accounting who wants to know why you have expensed seventeen dollars to a company called FrogData.

Now it’s here. The x402 protocol takes an old, mostly unused piece of the web—the HTTP status code 402 Payment Required—and makes it functional. A piece of software asks for something. The server responds with a price. The software pays. The resource is delivered.

Unlike you or I, the agent does not have to create an account or choose between a monthly and annual plan. No need to invent a password containing a capital letter, a number, and a punctuation mark. It does not have to decide whether to accept promotional emails. It encounters a price in the course of its work, pays that price, and continues.

And not needing a person opens up new possibilities, as well.

A research agent might buy one current financial data point rather than subscribe to an entire database. A coding agent might rent a specialized model for twenty seconds. The amounts may be too small and the transactions too numerous to make sense inside systems built for human buyers.

So here we are. Software is beginning to buy things. And not metaphorically. Not because a person clicked a button and the software completed the final step. Agents are beginning to evaluate options, select services, authorize payments, and continue working without a human.

It’s all extremely intriguing, so why did I feel uneasy?

The disappearing person

For years, people have talked about “removing friction” from payments.

Friction is usually depicted as an enemy. It shows up as the extra click, the loading screen, the forgotten password, the card that needs to be retrieved from another room. Companies spend extraordinary amounts of money shaving seconds from checkout because every second gives a customer another opportunity to remember that perhaps she does not need the electric milk frother after all.

But some friction is not accidental. Sometimes delay leaves room for discernment.

A person sees the price. A person notices the vendor. A person wonders why the shipping address is in another country. A person has the vague but useful feeling that something is wrong.

The human being in a transaction is not merely a slow payment processor. She carries context. Jenny remembers that the department budget was reduced last week, that this supplier caused trouble before, that the CEO said not to sign anything until legal reviewed the new terms. She may ignore all of these things, of course. Humans have never been a particularly reliable security system. But many of our existing guarantees assume that one will be present.

The agent economy removes the person because removing the person is, in part, the point. Agents are valuable because they can act while we sleep, compare more options than we can read, and complete a thousand small transactions that no sane employee would want to approve individually.

But when the person leaves, what happens to the guarantee she was shouldering?

A successful payment can still be a wrong action

A payment protocol can tell us that money moved correctly, but it can’t necessarily tell us whether the decision to move the money was correct.

Suppose an agent is told to purchase a dataset for a research project. It finds the data. The seller requests payment through x402. The agent sends the stablecoin. The cryptography works. The payment settles. The server delivers exactly what was promised.

The transaction is flawless.

The dataset may still come from a prohibited vendor. Its license may forbid the intended use. The price may exceed the amount the agent was authorized to spend. The request may have been planted by malicious text. The agent may have disclosed sensitive information while negotiating access.

Nothing about the validity of the payment establishes the validity of the conduct.

This is not a criticism of x402. A road is not defective because it does not decide where you ought to go.

In fact, the problem becomes visible precisely because the payment layer is beginning to work. Once agents can transact easily, we are forced to confront new questions.

Who authorized the action? Which rules applied? Did the agent remain inside its mandate?

How would anyone know?

These questions are easy to answer when there are only a few transactions and a person is watching. They become stranger, and much more difficult, when the agent is making hundreds of decisions across services that have never met one another, each operating on a fragment of the relevant information.

The temptation to record

So the familiar answer is the log. Record every action. Then, should anything go wrong, someone can reconstruct the event.

I understand the appeal. A log feels like a form of honesty. Here is what happened. Here is everything. Look for yourself.

But at machine scale, “everything” becomes impossible to keep track of.

A sufficiently detailed log may contain customer information, internal instructions, trading strategy, proprietary model behavior, credentials, pricing logic, or the private rules by which an institution operates. That is a lot of extremely sensitive information. All stored in one place. Ripe for a data breach.

And the existence of the log does not mean anyone can understand it.

A human auditor can read a dozen transactions. Perhaps a hundred. An agent may generate thousands of actions inside a workflow, with the consequence of one decision depending on the previous forty-seven. The log grows more complete and, in a strange way, less legible.

This is where the subject becomes more interesting to me, because it stops behaving like a problem with a straightforward solution. It becomes a dilemma: the apparent remedy reproduces the condition we were trying to escape. We begin with the desire for trust. We respond by demanding disclosure.The disclosure creates exposure. The exposure creates another trust problem.

A new type of receipt

At Inherence, we’ve been thinking about what should replace the guarantee that disappears when the human leaves. It’s not a better log and it’s not a person reinserted into every decision.

What is needed is proof.

Disclosure says: here is what the agent did. Examine it and decide whether you trust me.

Proof says: the agreed conditions held, and you can verify that fact without seeing the private material underneath it.

So imagine that an institution gives an agent a mandate:

Spend no more than a certain amount. Use only approved counterparties. Do not transact with sanctioned addresses. Do not expose protected information. Seek approval when the transaction crosses a defined threshold.

With Inherence, those rules can be enforced as the agent acts. The system can block a transaction that violates the mandate before the payment leaves. It can also produce a compact cryptographic receipt showing that the rules held, without exposing any sensitive data. The receipt does not explain the agent’s strategy. It answers a narrower and more useful set of questions. Was the seller permitted? Was the amount authorized? Did the transaction remain within policy? Did the rule hold?

Our work at Inherence is to make this kind of proof fast enough to work inside an autonomous system. Speed matters because a proof that arrives several seconds later belongs to a different world, one that is no longer relevant. Markets move. Agents continue. Transactions settle. If governance can’t keep up with the action, the governance is rendered moot.

Our technology works in two parts: an inline enforcer, which blocks a rule-breaking transaction before execution, and a 128-byte zero-knowledge receipt, which allows the conduct to be verified without revealing the underlying orders, sizes, or strategy. Our current proof generation is under 50 milliseconds.

We are interested in proof that arrives in time to matter.

Two pieces, one puzzle

I don’t think the right story is that x402 creates a dangerous future and Inherence arrives to make it safe. x402 solves a real problem. Agents need a way to exchange value that does not force every machine interaction through a checkout process designed for a person sitting at a desk with a credit card.

But payment and permission are different things.

x402 can allow an agent to pay.

The next layer must establish whether the agent was allowed to pay, under the rules that governed that particular action.

Perhaps this is how infrastructure develops. One obstacle disappears and reveals the shape of the obstacle behind.The internet learned how to move information before it learned how to decide which information could be trusted. Blockchains learned how to settle transactions before institutions learned how to express all the messy conditions under which they were willing to transact. Agents are learning how to act before we have finished deciding what an accountable action looks like when no person is there to perform it.

The announcement around x402 definitely deserves attention. It’s bringing the agent economy closer. But it’s also illuminating everything that’s missing.

The guarantee. The trust. The proof.

Follow along at Substack and Linkedin.

Request Access To Inherence