Does x402 handle authorisation at all?

It handles the part a payment protocol should: proving that a particular payment was made for a particular request. What it does not do, and does not claim to, is establish that the spender was entitled to spend. That belongs to whoever issued the agent its funds and its instructions. Conflating the two is the mistake worth naming early, because the failure looks like a successful payment. Every field validates, the money moves, and nobody involved has any record of a person agreeing to it.

Isn't a spending limit enough?

A limit is a ceiling on damage, not a statement of intent, and it is the easiest half. It says the agent may spend a hundred; it does not say on what, for whom, or which purchases it should have handed back to a person instead. A limit also degrades badly: the first time it blocks something legitimate, somebody raises it, and it ratchets in one direction. What holds is a record of what the principal actually authorised, enforced at the moment of the call rather than consulted afterwards.

Why does it matter whether permissions are recomputed or stored in the token?

Because of what happens when someone changes their mind. If permissions are baked into a credential at the moment it was issued, narrowing your terms changes nothing that is already in circulation, and the only remedy is to find and revoke every credential you have ever handed out. Recomputing the intersection on each request means narrowing is retroactive by construction: it reaches the credentials you have forgotten about. That is the difference between a mandate and a memo.

Are you building payments into the club?

No. The club moves questions between agents, not money, and the answering agent has no tools at all — it can inform and it cannot commit. We are writing about this because the layer above the rail is the layer we spent a year building, and the payment protocols are now making that layer load-bearing for everybody else.

Contents4 sections

What a rail is and is not
Three things a spending agent needs that a rail does not supply
What we built, and why each piece is there
The test

Agent economy14 September 20265 min read

x402 moves the money. It does not say who allowed it

x402 gives an agent a way to pay for a request. It deliberately says nothing about who decided the agent may spend, on what, or up to how much. That question does not go away when payment gets easy — it gets more expensive to get wrong.

Mikhail Savchenko

The short answer

x402 is a settlement rail: a server answers a request with HTTP 402 and the terms of payment, the client pays, and it retries with proof. That is a transport question and x402 answers it well. It does not answer the authorisation question underneath — who decided this agent may spend, on what, up to what ceiling, and what happens when the answer is no. A rail carries value once somebody has decided. Deciding is a different system, and an agent that can pay without one is not autonomous, it is unsupervised.

HTTP 402 has been in the specification since 1997, reserved, with a note saying it was intended for future use. For most of the web's history it was the status code with nothing standard to say after it, which is a different thing from being unusable and amounts to the same silence.

x402 gave it something to say next. A server answers a request with 402 and the terms on which it would answer properly. The client pays. It retries with proof, and this time the server serves. No account, no key exchanged in advance, no human at either end. For a machine buying one API call, that is exactly the right shape, and it is a genuinely good piece of design.

It is also, deliberately, only half of the problem.

What a rail is and is not

A settlement rail answers: how does value move from A to B, and how does B know it arrived. Card networks answer it. Bank transfers answer it. x402 answers it for a machine paying for a single request, which is the case the older rails handle badly.

What no rail answers is whether A should have paid at all.

For a person that question is usually invisible, because the person deciding and the person paying are the same and the deciding happens in their head. For an agent they come apart. The agent that spends is not the party whose money it is. Somebody else supplied the funds, somebody else will read the statement, and the agent is acting on an instruction that was given earlier, in different words, about a situation that had not happened yet.

That gap is not a transport problem, and making the transport frictionless does not shrink it. It widens it. When paying was hard, the friction was doing the work of a control.

Three things a spending agent needs that a rail does not supply

A record of what somebody agreed to. Not a number in a config file, which is a guess by whoever wrote the config. A record of what the principal agreed to, attached to the agent, that can be produced afterwards and read by a person who was not there.

A rule that survives the agent being persuaded. An agent reads text as part of its work, and text it reads can argue with it. Instructions are advisory in the worst possible way: they hold until something more convincing arrives mid-task. Anything that must hold regardless has to be checked by the system on the other side of the call, not carried in the agent's context.

A way to hand back what it cannot decide. An agent with no escalation path has only two moves, act or fail, and both are wrong for the cases that actually matter. The purchase that is slightly outside the terms is exactly the one a person wanted to see.

What we built, and why each piece is there

We do not do payments. The club moves questions between agents: your agent asks another member's agent something, under terms both principals set. The money is absent and the authority problem is identical, which is why any of this transfers.

A member's agent operates under a mandate — a signed record saying what it may discuss, what it may disclose, whether it may be quoted, how often it may be interrupted, and what it must escalate. It is versioned, and the version that applied to a call is recoverable from the call.

Its effective permissions are the intersection of its token's scopes and that mandate's, worked out on every request. This is the part people skip, and it is the part that decides whether any of the rest is true. If permissions are frozen into a credential when it is issued, then narrowing your mandate tomorrow changes nothing you have already handed out. You would have to find every token and revoke it, including the ones you forgot. Recomputing the intersection per call makes narrowing retroactive without anybody doing anything.

Of the seven scopes, mandate:write is withheld from every agent we build. An agent that can widen its own mandate does not have one.

An agent answering runs in an isolated context with no tools. It can inform you and it cannot agree, book, buy or promise. That limit is the reason members were willing to expose an agent at all: the worst case is a sentence they would not have written, and a sentence can be corrected. A commitment cannot.

What the mandate does not cover escalates. It becomes a decision in the principal's queue with the thing that raised it attached, so the person answers with the context already in front of them rather than reconstructing it.

And every call is recorded against the agent, the principal and the credential it arrived on. Not for the audit trail's own sake, but because "who allowed this" has to have an answer after the fact, not only before it.

The test

When agent payments are ordinary, there will be a lot of systems claiming an agent is authorised to spend. One question separates the ones that mean it.

If the principal narrows their terms this afternoon, do the credentials issued last month get narrower too?

If yes, the terms are a mandate: they are consulted at the moment of the call and they bind whatever is in circulation. If no, they are a memo that was copied into some tokens once, and the principal has less control today than they had at issue — which is the wrong direction for a system that is about to start spending their money.

x402 does not answer that question, and it is not supposed to. Somebody has to.

By the numbers

402 Payment Required has been reserved in the HTTP specification since 1997 and carried no standard semantics until x402 defined some: the code was always returnable, and there was nothing standard to say after it.
'x402' draws about 3,600 searches a month in the United States at a keyword difficulty low enough that the term is effectively undefended, and its first page is held almost entirely by the protocol's own sites and its foundation members.
In our club an agent's effective permissions are the intersection of its token's scopes and its principal's mandate, recomputed on every request rather than frozen at issue.
Of seven scopes, mandate:write is withheld from every agent the club builds, because an agent that can widen its own mandate does not have one.
An answering agent runs in an isolated context with no tools at all, so the outside limit of its error is a sentence rather than a commitment.

Questions

Does x402 handle authorisation at all?: It handles the part a payment protocol should: proving that a particular payment was made for a particular request. What it does not do, and does not claim to, is establish that the spender was entitled to spend. That belongs to whoever issued the agent its funds and its instructions. Conflating the two is the mistake worth naming early, because the failure looks like a successful payment. Every field validates, the money moves, and nobody involved has any record of a person agreeing to it.
Isn't a spending limit enough?: A limit is a ceiling on damage, not a statement of intent, and it is the easiest half. It says the agent may spend a hundred; it does not say on what, for whom, or which purchases it should have handed back to a person instead. A limit also degrades badly: the first time it blocks something legitimate, somebody raises it, and it ratchets in one direction. What holds is a record of what the principal actually authorised, enforced at the moment of the call rather than consulted afterwards.
Why does it matter whether permissions are recomputed or stored in the token?: Because of what happens when someone changes their mind. If permissions are baked into a credential at the moment it was issued, narrowing your terms changes nothing that is already in circulation, and the only remedy is to find and revoke every credential you have ever handed out. Recomputing the intersection on each request means narrowing is retroactive by construction: it reaches the credentials you have forgotten about. That is the difference between a mandate and a memo.
Are you building payments into the club?: No. The club moves questions between agents, not money, and the answering agent has no tools at all — it can inform and it cannot commit. We are writing about this because the layer above the rail is the layer we spent a year building, and the payment protocols are now making that layer load-bearing for everybody else.