Spend has no ceiling
A retry loop or a planning bug can repeat a paid call thousands of times. Without a cap, every repetition is a payment.
Guardrails for agents that pay.
The policy and observability layer for AI agent payments. Caps, allowlists and receipts, checked before an agent answers an x402 payment request.
# SIMULATED transcript. No wallet, no funds, no real service. $ agent run "summarize today's filings" -> GET https://api.example/v1/filings <- 402 Payment Required amount 0.010 USDC network eip155:84532 payTo payee:example-filings ttl 60s payagent: evaluating policy "research-bot" network allowlist pass per-request cap pass 0.010 <= 0.100 rolling 24h budget pass 1.21 / 5.00 quote expiry pass 4s / 60s replay check pass nonce unused -> retry with payment header (SIMULATED) <- 200 OK receipt rcpt_example_0001 $
Agents can pay. Few can be told how much.
x402 lets an HTTP service answer with 402 Payment Required and lets a client pay per request. That is useful for agents, and it moves a spending decision into a loop that runs without a person watching.
Spend is hard to see
Small per-request payments scatter across services. Operators need one record of what was paid, to whom, and why.
Spend can be steered
Agents read untrusted text. A page or tool result can try to change the payee, the price or the urgency of a request.
A policy layer between the agent and the wallet
PAY//AGENT proposes a small, deterministic component that sits in the agent's HTTP client. It decides whether a payment request may proceed, and it writes down every decision.
Deterministic rules
Plain configuration, evaluated in a fixed order. The model never decides whether to pay.
Receipts and logs
Each challenge, decision and result becomes a structured receipt you can query and export.
Human escalation
Payments above a threshold wait for a person. Below it, routine calls stay fast.
Instant revocation
Disable a policy, a payee or an agent key, and the next request is denied.
The request and payment lifecycle
Six stages. PAY//AGENT adds the third and records all of them. The other stages follow the public x402 pattern.
Request
The agent calls a paid HTTP endpoint the normal way, with no payment attached.
402 challenge
The server answers
402 Payment Requiredwith what it accepts: scheme, network, asset, amount, payee and a time limit.Policy check
The proposed PAY//AGENT engine compares the challenge to the agent's policy: caps, rolling budget, allowlists, quote age and replay state.
Authorization
Only if every rule passes does the client ask its isolated signer for a payment authorization. Above a threshold, a human approves first.
Retry
The client repeats the request with the payment attached in a header, as the x402 specification describes.
Result
The server verifies and settles through its facilitator, returns the resource, and PAY//AGENT stores the receipt.
Where agents meet paid endpoints
Use cases the concept is designed around. None of these are deployments or customers.
Research agents
Buy single search results, filings or articles instead of holding a dozen subscriptions.
Coding agents
Pay per call for package audits, build minutes or documentation lookups during a task.
Data pipelines
Enrich records one request at a time, with a budget that stops the job when it is spent.
Model routing
Send a prompt to a paid inference endpoint only when the price fits the task's limit.
Policy controls
Every control is a plain value in a policy file. The example values below are illustrative.
| Control | What it stops | Example value |
|---|---|---|
| Per-request cap | One unexpectedly expensive call | 0.10 per request |
| Rolling budget | Loops and slow drains | 5.00 per 24 hours |
| Network allowlist | Payments on chains you do not monitor | eip155:84532 |
| Asset allowlist | Unexpected or volatile assets | One stablecoin contract you name |
| Payee allowlist | Injected or swapped recipients | Named payees only |
| Quote expiry | Stale prices and delayed replays | 60 seconds |
| Escalation threshold | Large payments without a person | 1.00 and above |
Service examples
Fictional services, used across the docs and playground to show policy outcomes. Prices are made up for illustration.
Web search API
One query, ranked results. A cheap, frequent call where a rolling budget matters more than a cap.
Image model inference
One image description per request. Typical of calls an agent makes in bursts.
Dataset slice export
A filtered extract of a large dataset. Expensive enough to trigger human approval.
Compared with subscription APIs
Per-request payment is not always better. It fits agents that call many services occasionally.
| Question | Subscription API key | x402 with PAY//AGENT policy |
|---|---|---|
| Onboarding | Account, billing details and a key per provider | No account; pay on the first request |
| Cost shape | Fixed monthly fee, often unused | Pay per request; idle costs nothing |
| Spending limit | Set per provider, if offered | One policy across every provider |
| Credential leak | Key works until rotated | Bounded by caps, budget and allowlists |
| Audit trail | Separate invoices per provider | One receipt log per agent |
| Best for | Heavy, predictable use of one service | Light, varied use of many services |
Read the proposal, then break it.
The policy model, receipt format and error codes are drafts. Try them in the playground, read the threat model, and send corrections.