A program sends a request to a paid API it has never used. It has no account there and no key. The server answers with status 402 and a small document: a price, an asset, an address to pay, and a window of a few hundred seconds. The program signs a transfer for the amount, repeats the request with the proof attached, and receives the resource. Cloudflare, announcing a gateway that will put this exchange in front of any resource it protects, states the premise in one sentence: the buyer needs no account with the seller, because the payment itself is the credential.
That sentence is accurate, and I think it is also the place to start worrying. A signed payment is a real credential. It is also a thin one. It proves that whoever held a key controlled some funds at one moment and chose to spend them on this request. It does not name a principal, it carries no delegated authority, and it offers the seller nothing to revoke. The account did not become unnecessary. Its jobs moved to places that are harder to see: the wallet key, the request signature, and the terms clause attached to the challenge.
What the 402 actually proves
Follow the mechanics. In the x402 exchange, the server's challenge lists the accepted networks, the asset, the amount, and the payee. The client's proof is a signed transfer that a facilitator verifies and settles. After settlement, the seller knows one fact with certainty: an address paid. On a public chain the record is more inspectable than any API-key log, since anyone can look up the transfer. It also says less. An address is not a person, an organization, or an agent acting in a defined role. It is a key.
The x402 project presents the missing account as the point. Its comparison of the old way and the new way lists account creation, payment-method setup, prepaid credit, and API-key management as the steps removed, with key management called out as a security risk that required storage and rotation. The protocol dropped the identification step because sub-cent settlement removed the commercial reason for it. Cloudflare says the same thing from the seller's side: usage-based billing used to be sold only to a known buyer who signed up and received a key, because collecting a tiny payment from a stranger cost more than the payment.
Three principals behind one address
The question I keep asking of any control is which principal, credential, resource, and decision are involved. Here the resource and the decision are clear. The principal is not.
The key that signed the payment may belong to a person who funded a wallet for their own agent. It may belong to a platform that holds one balance for thousands of agents and pays from it on their behalf. Coinbase's developer documentation describes agentic accounts that give an agent its own account for paying x402 services, and Locus markets one balance across dozens of providers so that an agent never stops for another key. From the seller's side, these cases are indistinguishable. A platform paying from one wallet for many agents looks like one very busy customer.
So the seller has a credential without a principal, and the principal has a delegate without a record at the seller. Whatever authority the agent had came from somewhere upstream, and nothing in the exchange asked to see it.
The protocols are putting identity back
The clearest evidence that thin identity is not enough comes from the protocols themselves. In August the Machine Payments Protocol team shipped identity support in its client library. Its agents can now sign the initial request and each paid retry with HTTP message signatures, under either Web Bot Auth or Visa's Trusted Agent Protocol, so that servers can apply their own trust and access policies. Each attestation carries a fresh timestamp and nonce, and the server verifies it before it issues a challenge or accepts a credential.
Read that sequence carefully. The server checks who is asking before it quotes a price. That is the identification step returning, one layer down from where it used to live. It is no longer an account at the seller. It is a signature on every request, verified against a key directory that the seller chooses to trust.
Identity also returns through fulfillment. Prospect Butcher, a Brooklyn sandwich shop that sells through an API paid over MPP, takes the payment without any account. Its instructions to agents nonetheless say that a name and email are required before purchasing, because someone has to collect the sandwich and receive the receipt. The payment can be anonymous. The obligation it creates cannot.
The vending-machine objection
The strongest ordinary explanation is that none of this is new. Cash never needed an account. A vending machine identifies nobody, a prepaid card identifies nobody, and commerce survived. A signed stablecoin transfer is cash that travels over HTTP.
The objection is right about the small cases, and it narrows my thesis. For a two-cent lookup that returns immediately and can be repeated if it fails, thin identity is sufficient, and it always was. The pressure appears when the purchase creates obligations that outlive the request: delivery, a refund, a plan that renews, a term of service that binds someone. Cash at a counter comes with a person standing there and a receipt in hand. A payment signed at three in the morning by a key held by software comes with neither, and the payer may be a delegate whose authority nobody checked.
Commentary that sorts the current protocols into layers concedes the point from the other direction. Settlement protocols such as x402 and MPP, it notes, do not address wallet management, spending limits, or compliance reporting, which is why an authorization layer built on signed mandates of user intent exists alongside them. An account was one way to bundle identity, authority, and billing. Unbundling them did not make the first two optional.
Nothing to revoke
With an API key, revocation is a deletion and the audit log names the key. With a signed payment the seller holds nothing to revoke. The control point moved upstream, into the wallet: a spending limit, a session key, a balance that can be drained to zero. Those are the buyer's controls, and the seller cannot see them.
The audit question moves with it. 1Password, announcing a product for governing agent credentials, defines the record an organization wants as which credential was used, when, by which identity, and under whose authority, and lists that audit capability as coming later. A payment proof answers the first two parts. It says nothing about the last two. Was it paid is not the same question as was it authorized, and the gap between them is exactly where a disputed agent purchase will be argued.
What a seller can show afterward
Consider what a seller can produce after an agent purchase goes wrong: a chain transaction from an address, perhaps a request signature naming a platform, and a terms clause that attributes the act to an unnamed human. That is the whole evidentiary record of thin identity, and for now the vendors are filling the gaps inside their own products.
One consequence is worth watching. If sellers begin requiring a signed request before they issue a 402 at all, as the MPP client now makes possible, the account will have returned under a new name, kept in a key directory rather than a signup form. At that point the phrase no account needed will still be true, but only of the purchases small enough that nobody would have asked.
Published . Corrections