Guide · 6 min read · For engineering

x402 pre-authorization, explained: signed tokens before agent money moves

x402 removes the human from the payment loop by design. Pre-authorization puts a policy decision back in: the agent's payment becomes an intent, the engine evaluates it, and a signed, single-use, scope-bound token is the only thing that lets money move. No token, no payment.

x402 is the HTTP 402 payment flow: an agent requests a resource, the server answers 402 Payment Required with a challenge, the agent signs an on-chain transfer, a facilitator broadcasts it. No checkout page, no merchant of record, no human. That is the point of the protocol, and it is also the gap: your fraud, compliance, and approval gates never see the transaction.

Pre-authorization is how we close that gap without breaking the flow. Before the agent's signer broadcasts anything, the payment is turned into an intent, evaluated against your organization's policy, and, only if policy allows, granted a signed token that authorizes exactly that payment and nothing else. This is a walkthrough of the flow as it is actually implemented in our x402 policy middleware.

The flow, step by step

The agent calls a paid resource and receives the 402 challenge: facilitator URL, payee address, amount, asset, chain.
The middleware builds an outbound value transfer record from the challenge and the agent context: which agent, acting for which principal, using which tool, paying whom, how much. This is the intent, and it gets a canonical fingerprint so the exact bytes that were evaluated can be replayed later.
Protocol-level preconditions are checked first. If the challenge carries a spend delegation (more on that below), the payment must fit inside it or it is denied before any policy question is even asked.
The decision engine evaluates the intent against org policy: budgets per agent, per tool, and per merchant over rolling windows, approval tiers, counterparty rules. The verdict is allow, deny, or require_approval.
On allow, the host signs an authorization token and returns it. The agent retries the facilitator with the token attached.
The signer verifies the token before broadcasting. If there is no valid token, nothing is broadcast. Fail-closed is the contract: no token, no payment.

What is inside the token

The token is a short-lived signed JWT whose claims pin every dimension of the payment:

{
  "jti": "unique, single-use token id",
  "iss": "your Axiru issuer",
  "sub": "org id",
  "aud": "facilitator URL",
  "exp": "short expiry",
  "event_id": "the intent's id",
  "ovt_fingerprint": "hash of the evaluated intent",
  "rail": "x402",
  "rail_action": "pay",
  "pay_to_address": "exact payee",
  "amount_minor_units": "exact amount",
  "asset": "USDC",
  "chain": "base",
  "agent_identity_value": "which agent paid",
  "principal_identity_id": "who it acted for"
}

Scope-bound means the token authorizes this payee, this amount, this asset, on this chain, presented to this facilitator, before this expiry. And it cannot be replayed for a second payment: the jti is minted per decision, issuance is idempotent (a retried request gets the original token, never a second one), and the jti is recorded on the decision record so the audit trail can bind token to evidence.

Fail closed, everywhere

The real design work in a governance layer is the failure paths. Each of these is pinned by tests in the middleware:

Decision engine unreachable, or the call throws: the result is blocked with an internal error. No token is minted.
Token signer unreachable, or it returns an empty token: blocked. An allow verdict without a signable token is still not a payment.
A spend delegation is present but malformed: denied outright. A corrupted spending cap is treated as a broken control, not a missing one.
Budget aggregates unavailable because the spend-data pipeline is down: an enforcing budget rule escalates to require_approval rather than assuming zero prior spend. The middleware never fabricates zeros, because a zero reads as 'no prior spend' at exactly the moment the data is least trustworthy.

The spend-governance extension: built by Fireblocks, consumed by us

In June 2026, Fireblocks contributed a security extension to x402 that lets a payer's governance layer attach delegations to the protocol flow itself: a request integrity hash, and a spend-governance section carrying a maximum amount, an expiry, an allowed payee list, and an optional session budget. To be clear about provenance: Fireblocks built the extension, the x402 ecosystem carries it, and Axiru consumes it.

Our middleware enforces those delegated bounds as hard preconditions before the decision engine runs: amount within the cap, payee on the list, delegation not expired, challenge bytes matching the integrity hash. The extension is a good primitive, and it is deliberately not the whole answer. It bounds a single delegation; org-level policy answers the questions above it, like which agent, whose budget, what approval tier, and what evidence. The two layers compose, and we do not compete with the protocol.

The receipt at the end

Every governed payment ends in an Agent Spend Receipt: a deterministic document projected from the decision and event records, carrying the agent identity, the principal, the amount, the policy outcome, and the authorization token's jti. The receipt body carries a canonical-JSON sha256 self-hash, and the underlying decision sits in a hash-chained audit ledger. Same rows in, same receipt out, byte for byte, and tampering is visible.

That closes the loop: intent, decision, token, settlement, receipt. When someone asks what your agent paid for last Tuesday and under whose authority, the answer is a signed document, not a log grep.

What is live and what is not

The x402 pre-authorization path, the signed authorization tokens, and the receipts endpoint are live today.
The middleware package itself is private while we prepare a public release; the hosted path does not require it.
Charge-style intents are governed today. Session-level intents (max session spend, voucher velocity) are a later phase, and we do not claim them yet.

See it run

The fastest way to feel the flow is the hosted MCP endpoint: point an agent at it with an Axiru key and every spend intent becomes a policy decision with a receipt. Or watch the four-minute demo of the gate holding under a live agent.

Connect over MCP →Watch the demo →