x402 · agent payments · policy · 11 min read

x402 Security for AI Agents: Before Your Agent Pays an API

x402 makes paid HTTP calls machine-native; agent teams still need policy checks for price, recipient, network, inputs, settlement proof, and receipt integrity.

By Hekate Gate Team · 2026-05-20· Markdown

Want to check a real agent workflow?

Paste a manifest into the public demo or bring a scoped workflow to the private beta.

Run a preflight check →Join private beta →

The payment step is a security decision

x402 makes paid HTTP APIs natural for machines. A service can return HTTP 402 Payment Required, the agent can satisfy the payment requirement, and the resource can be delivered without a human account, session, invoice, or card checkout.

That is powerful because agents often need to buy small pieces of data or computation in real time. It is also risky because payment is an irreversible external action. Once an agent can pay, security teams need to know who it paid, how much it paid, on which network, for what task, with what input data, and what proof came back.

The payment rail can prove that money moved. It does not prove that the agent should have paid. That is the job of policy preflight.

What x402 solves

x402 solves a real distribution problem for paid APIs. A machine client can discover a price, satisfy a payment challenge, and retry the request with payment proof. Vendors can charge for a single API call without forcing a developer through sign-up, subscription, or credit-card billing.

For agents, that means the market for tools can become more dynamic. A research agent can buy one market signal. A support agent can buy one verification check. A compliance agent can buy one registry lookup. A developer agent can buy one specialized analysis without a monthly vendor relationship.

That unlocks agentic commerce, but only if spend is governed. Companies do not want agents with unlimited wallets. They want agents with budgets, allowlists, payment caps, receipts, approvals, and audit evidence.

What x402 does not solve

x402 does not decide whether a vendor is trustworthy. It does not know whether the endpoint is appropriate for the task. It does not know whether the input contains customer data or secrets. It does not know whether the agent is being manipulated by prompt injection.

It also does not replace receipt integrity, settlement review, or business policy. A payment can be valid and still violate company rules. An endpoint can be cheap and still be malicious. A network can be allowed and still carry the wrong recipient.

That is why Hekate Lite sits before the payment. The agent sends the payment requirements, task, endpoint metadata, and policy. Hekate returns allow, warn, or block before the wallet path is reached.

Preflight checks before payment

A safe x402 preflight checks price, asset, network, recipient, facilitator, endpoint schema, declared output, refund or dispute policy, receipt support, input sensitivity, and vendor reputation. It also checks daily budget and per-call limit against the agent's policy.

The common policy fields are simple: max_payment_per_call_usd, max_daily_spend_usd, allowed_networks, allowed_recipients, require_receipt, deny_sensitive_inputs, mainnet_allowed, and require_human_approval_above_usd.

The response should be equally simple. price_ok, network_ok, recipient_ok, input_ok, metadata_ok, receipt_expected, decision, risk_score, warnings, and receipt_id give the agent enough information to proceed or stop.

Payment abuse patterns

The first abuse pattern is price inflation. An agent asks for a $0.10 resource and receives a $10.00 challenge. Preflight should block above threshold and record the challenge as evidence.

The second is recipient mismatch. The endpoint claims to be a known provider but asks payment to an unknown address or account. Preflight should compare recipient metadata to allowlists or registry records.

The third is sensitive-input laundering. The agent is asked to send customer data, API keys, private keys, health data, or financial data to a paid endpoint that has no clear need for it. The payment may be small, but the data exposure can be critical.

The fourth is replay or double-spend ambiguity. If an agent retries, the payment proof, task hash, idempotency key, and receipt should match the same intended action. Otherwise a harmless retry can become a duplicate purchase.

Receipts and evidence after settlement

Preflight is only half the story. After the payment settles, the agent should retain the payment proof, endpoint response hash, task hash, policy hash, settlement reference, and a signed security receipt. That bundle is what lets a human reconstruct the event later.

A strong receipt says what was checked, which policy applied, what decision was returned, which findings existed, which evidence hash was signed, which issuer signed it, and which scanner version produced it.

For Accord-compatible workflows, the layering is clean: x402 verifies payment, Accord verifies completion, and Hekate verifies the security preflight and evidence integrity around the flow.

A safe default policy

A conservative x402 policy starts with mainnet disabled, a low per-call cap, a daily budget, a recipient allowlist, network allowlist, mandatory receipts, sensitive-input denial, and human approval above threshold.

For private beta, that might mean max_payment_per_call_usd of 0.25, max_daily_spend_usd of 10, allowed networks of base and ergo-testnet, mainnet_allowed false, require_receipt true, and allowed recipients limited to known provider domains.

Those numbers can change by organization and risk appetite. The structure should not. Before an agent pays an API, the company should know whether the next payment is inside policy and whether it will produce evidence strong enough to audit.

Hekate next steps

Compare Hekate Gate vs direct x402

Where payment protocol mechanics end and policy preflight begins.

Read the x402 glossary

HTTP 402 payment challenge, proof, response, and settlement concepts.

Review pricing

Private beta packaging for Hekate Lite and production preflight.

Run the public demo

See how Hekate classifies payment-capable tools before production.

FAQ

Does x402 decide whether an agent should pay?

No. x402 handles the payment challenge and proof flow. Policy preflight decides whether the agent should pay this endpoint under this task, price, recipient, and policy.

What should be checked before an x402 payment?

A preflight should check price, asset, network, recipient, endpoint metadata, input sensitivity, budget caps, receipt support, settlement proof, and replay risk.

Why does Hekate require receipts for paid agent flows?

Receipts make payment decisions auditable by binding subject, policy, evidence, scanner version, decision, issuer, and signature to the workflow.