required.Try the demo

THE CONTROL LAYER FOR AGENT PAYMENTS

Autonomous
agents.
Accountable
spending.

Budget and approval controls for AI agents that buy data and tools through x402.

Take the controls See how it works

Interactive product concept. Every payment is simulated.

MEET YOUR GATEKEEPERUNIT / 402
The original Gatekeeper: a beige robot with a CRT head displaying 402, standing watch in a black tie.
POLICY CHECK / EXAMPLEWithin budget. Proceed.
HUMAN OVERSIGHT, BUILT IN

AGENTS DO THE WORK.
YOU SET THE BOUNDARIES.

SCROLL TO THE PLAYGROUND
Set a budget Decide what’s allowed Know where it wentDESIGNED AROUND x402
01 / AUTONOMY WITH BOUNDARIESTHE PRODUCT CONCEPT

Delegate the task.
Keep the authority.

A useful agent needs access to tools, data and compute. 402 Required explores how to give it spending power with a clear limit, a reason for every decision and a human in the loop.

01

A budget. Not a blank check.

Set a cap for the mission. Requests that exceed the remaining budget stop before a simulated payment.

SESSION BUDGET$0.38 / $1.50Illustrative session
02

Your rules travel with it.

Allow known services. Flag larger requests for approval. Keep unapproved vendors outside the boundary.

Known service ALLOW Above threshold REVIEW Unknown vendor BLOCK
03

A clear trail for every decision.

Follow each request from price to policy decision. See what was approved, what was blocked and why.

REQ_001 / EXAMPLEAPPROVED

Public web search

$0.08 USDC · WITHIN POLICY
02 / THE PLAYGROUND INTERACTIVE SIMULATION

Your agent. Your budget.
Your call.

Run a mission. Watch the requests. Decide where the line is.

START HERE ↙Try the balanced policy, then rerun with a tighter budget to see what changes.

402 / CONTROL ROOM LOCAL SANDBOX
SESSION / RESEARCH_001

Mission control

READY TO RUN
Simulated spend$0.00
Budget remaining$1.50
Requests approved0 / 5
$0.00 of $1.50 used
SERVICE / PURPOSEPRICEDECISION
THE GATEKEEPER’S DESKPOLICY / READY

The rules are set. Let’s put them to work.

Run the mission to follow each request from HTTP 402 to a policy decision. Select a row to inspect it.

REQUEST→402→POLICY CHECK→PAY / HOLD / BLOCK
Waiting for your go-ahead.

This is a product simulation. Services, prices and reports are illustrative. Nothing is sent to an AI model, wallet or blockchain.

03 / A CHECKPOINT, NOT A ROADBLOCKTHE PROPOSED FLOW

One request.
A considered response.

x402 describes how software can pay for a resource. Our concept adds a decision before payment: should this agent spend this amount on this service?

01 / AGENTRequest a resourceGET /research
02 / SERVICEReceive a price402 PAYMENT REQUIRED
03 / 402 REQUIREDCheck your policyALLOW · REVIEW · BLOCK
04 / IF AUTHORIZEDPay and proceed200 OK + resource

Budgets and approval rules belong to the control layer. x402 handles the payment exchange.

Explore x402 (opens in a new tab)

Give agents autonomy
with an accountable boundary.

THE 402 PRINCIPLE
04 / THE NEXT STEPSPROTOTYPE NOW · INTEGRATIONS PLANNED

From simulation.
To a tested integration.

The browser prototype is ready to explore. Agent and payment integrations are planned work, not live features.

  1. NOW / AVAILABLE

    Interactive prototype.

    Explore budgets, service permissions and human approvals with prepared requests. Everything runs locally in your browser; no funds move.

  2. NEXT / PLANNED

    Research agent.

    Connect a research agent to tools, with budget and permission checks enforced in code and human review where required.

  3. LATER / PLANNED

    x402 test payments.

    Validate the payment flow in a test environment before considering a live service. No live payment endpoint is deployed.

05 / THE FINE PRINT

Clear rules.
Clear answers.

A transparent concept.
A tangible experience.

Is this a working payment product?

This is an interactive product concept. The playground runs entirely in your browser using prepared requests and sample results. It does not call AI services, connect a wallet or move funds.

What would 402 Required add to x402?

x402 provides a way for software to pay for resources. The proposed 402 Required layer would evaluate a request against a session budget, an approved service list and an approval threshold before a payment is authorized. The demo illustrates those decisions.

Can a human approval override the budget?

In this simulation, no. A request above the approval threshold can be approved once if it fits the remaining budget and the vendor is allowed. A budget breach or an unapproved vendor is blocked. Change the policy and rerun to explore a different outcome.

Does the demo use real companies or prices?

All service names, prices, vendors and competitor results in the playground are illustrative. The downloadable JSON is a simulation log, not an invoice or blockchain receipt.

Would this require a new token?

The concept does not require a proprietary token. The demo uses simulated USDC amounts to explain per-request payments. No token contract, network integration or payment endpoint is deployed.

AUTONOMY, ON YOUR TERMS.

Let it work.
Keep the controls.

Built by Abel Cano, founder of 402 Required. If you're exploring paid tools for agents, I'd like to hear about your workflow.

Talk to the founder Try the playground
The canonical Gatekeeper holding his red PAYMENT REQUIRED stamp.