x402 and MPP are converging fast on the payment rail for AI agents. Both, by design, stop at settlement and leave authorization to the layer above. That is a clean boundary. It also means the same question keeps surfacing in their own issue trackers: a settled payment says value moved, never that the caller was allowed to move it. Answering who is allowed to invoke a resource is a different job, in a different layer. Here is what their trackers keep circling, and the trail of work that already answers it.
The rails are almost done. The gate isn't in them.
The agent-payments stack has matured in public. Coinbase's x402 put a price on the HTTP 402 status code so an agent can pay per request. Solana Foundation and Tempo's MPP did the same for machine payments at scale. Google's AP2 and the UCP commerce layer sit alongside. Between them, "an agent can pay an API without a human in the loop" is close to solved.
What none of that settles is the question a service actually asks before it hands over a resource: should this caller get in at all? Paid and allowed are two different jobs. And that is only the first split: a payment is one signed fact in a transaction, not the whole trust model. Lean on settlement to carry the rest and the gaps surface around it, exactly where the trackers are pointing.
Read the receipts
Not a trend take. Three entries from the protocols' own repositories, all from the past few weeks. In each one the payment machinery worked as designed, and a different signed answer was missing around it: one at settlement, one after it, and the one this post is about, before it. Authorization is the member with no home in the spec.
Coinbase's hosted facilitator, the documented default most live integrations point at, spent days rejecting spec-compliant v2 payment payloads with a 400 that blamed the payload's shape. The real trigger, isolated only after sellers black-box bisected the endpoint themselves, was an undocumented 500-character cap on one optional description field. Affected sellers went dark silently while network-wide settlement volume never dipped, so nothing alerted. The issue closed with a documentation update and client-side workarounds.
The lesson here isn't "a service had a bug," and it isn't an authorization failure either. It is the adjacent one, at settlement: when a critical answer comes from a single opaque hosted endpoint, callers cannot independently check it or diagnose it. Verification sat behind one endpoint whose answer the caller could neither validate nor usefully read: valid requests, an opaque no, and an error message pointing at the wrong field. An answer signed at the source and verifiable offline by any party cannot strand its callers guessing. That is the standard, verifiable output we have argued for from the start, and the reason there is no key to leak in the first place.
An open extension proposal wants to add delivery-receipt attestation: cryptographic proof, attached to the response, that the thing paid for was actually delivered.
This is the answer that comes after settlement. The proposal's own motivation states it plainly: settlement proves the money moved, and proves nothing about what was delivered. It is real demand for a cryptographically verifiable attestation once the payment clears, reached for from the payment side. That is the exact primitive we build, as a general capability rather than a payment special case. See verify anything on-chain and the pre and post pattern for agent commerce, where a signed attestation brackets the transaction on both sides.
A proposal to add a new credential type so a facilitator can settle a Permit2 transaction. The word doing the work there is credential.
This is the answer that comes before the call, and the one with no home. The immediate blocker is narrow: settlement refuses unless a specific spender is the authorized one. The broader lesson is that authority has to be evaluated explicitly, not inferred from the fact that a payment credential exists. That is what we built for: multiple independent issuers, one verification pass, no single credential to forge. It is the multi-attestation model, and why we keep the credential that grants access separate from the identity that confirms who is asking.
Payment and authorization are two jobs
Hold the two apart and the whole landscape gets simpler to reason about:
- The payment rail answers: did value move, on which chain, in which asset, and did it settle. That is x402 and MPP, and they do it well.
- Authorization answers: is this specific caller allowed to invoke this specific resource right now. Does the wallet behind the agent still hold the token, the pass, the role, the position that the endpoint requires.
Treat "it paid" as "it's allowed" and you inherit the predictable failures: a paid request replayed against a second endpoint, an over-permissioned agent draining a budget it was never scoped to, a compromised key that still settles because settlement never asked who was holding it. We have written about each of those from the other direction, in why agents keep getting hacked, in how you prove an agent was authorized to act, and in the three layers of trust a payment actually rests on.
The layer, in one call
The authorization layer does not need to be heavy. It is one request and a signed boolean back. Read the wallet's on-chain state, evaluate it against the condition the endpoint sets, sign the answer. No balances exposed, nothing to leak, verifiable by any party offline.
And it drops into an agent-payments stack the same way x402 does: as middleware on the route. The pattern is an either-or gate. An X-API-Key takes your existing human customers straight through, untouched. An Authorization: Wallet request gets its signature checked, then the wallet's condition verified against InsumerAPI, and passes only if it holds. Neither header, no entry.
// x402 adds a payment door to the route.
// This adds an authorization door. Same shape, different question.
app.post('/v1/resource',
requireValidConditionOrApiKey(yourApiKeyMiddleware),
handler
);
// wallet request -> verify SIWE signature
// -> POST /v1/attest { wallet, condition }
// -> signed boolean: holds -> pass, else 401
x402 charges at the door. This decides who reaches it. You can run both on the same endpoint: the payment rail settles the value, condition-based access decides whether the request is allowed to proceed. They are complementary, not competitive, which is the whole point. See the primitive up close in your agent doesn't need an API key and wallet auth for AI agents.
We didn't write this the week it broke
The reason this reads as obvious is that we have been mapping it since before the trackers filled up. The static credential was always the weak joint. Quantum breaks static credentials made the long-run case; there is no secret made the near-term one. On the protocols themselves, we gated MPP with condition-based access, argued Coinbase's agentic market needs wallet auth, not just tools, and asked who verifies the wallet behind an agent Visa lets pay any x402 endpoint. The full frame is in before an agent pays and the wider thesis in one thesis, five companies.
The payment rail is nearly finished, and the teams building it are doing careful, correct work. The part their own issues keep bumping into is the gate: the signed answer to "Is this caller allowed?" standing beside the answer to "Did it pay?" That gate is a boolean. It is signed. It works across 37 chains. And it is in production now.
Add the authorization door to your route
InsumerAPI is free to start. Send a wallet and a condition, get a signed boolean back in one call, across 37 chains. Drop it in beside x402 or MPP.
Read the Verification DocsGet every post by email
The Inevitable series and builder notes on condition-based access. Free, one or two posts a week.