Spending policies for AI agents that pay with x402

An x402 server states its price in a machine-readable header, and an agent with a wallet can pay it within the same request. That is the point of x402, and also the risk: nothing in the protocol decides whether a given payment is one the agent's owner would approve. The x402 V2 core specification lists client-side budget management as out of scope and calls spending controls implementation-specific. The client has to bring its own policy.

Why a prompt is not a policy

Telling a model "never pay more than one cent" is an instruction it may weigh against others, including text supplied by the server it is paying. The payment terms come from that server: the recipient, the token, the amount, even the human-readable error and description strings. A spending policy has to be checked by code outside the model, against fixed values the owner set, before anything is signed. The model can call the check; it should not be the check.

The four constraints that make "pay" possible

A payment request usually offers several options in accepts, and the agent pays with one of them. A useful policy bounds every dimension of an option: who is paid, in which token, on which chain and how much. In the Settlens MCP tool evaluate_payment_requirements, the decision can only be pay when all four are set.

This is the example policy from the server's own guide (the MCP resource settlens://policy-guide):

{
  "pay_to": ["0x209693Bc6afc0C5328bA36FaF03C514EF312287C"],
  "assets": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"],
  "max_amount": "10000",
  "networks": ["eip155:8453"],
  "schemes": ["exact"]
}

An option is acceptable when it is well formed and satisfies every constraint you set; policy.acceptable_option passes when at least one option is. The per-constraint checks only summarize the options: they warn when some options violate the constraint and fail when all do.

Amounts are in atomic units

x402 amounts are integer strings in the token's smallest unit. USDC has 6 decimals, so "10000" is 0.01 USDC. A cap therefore means nothing without the token: the same max_amount of "10000000" is 10 USDC but 0.1 of a token with 8 decimals. Pair max_amount with an assets allowlist, and list only assets that share the same decimals. The glossary has the definition.

An asset only means something on its network

A token address is only unique within one chain: the same address can be a different contract, or nothing at all, on another network. An allowlist of assets without a list of CAIP-2 networks lets a server name your trusted address on a chain where it means something else. Set both, and keep the networks to the ones your wallet can actually sign for.

Decisions: pay, review, do_not_pay

The checks produce one of three decisions. The verdicts below were computed when this page was built: the same request (the demo's PAYMENT-REQUIRED, 10000 atomic units on Base Sepolia, requested at http://127.0.0.1:4402/secure) evaluated under five policies.

The rules, in order:

1. do_not_pay when any check of severity high or critical fails, including when no option is acceptable. Never pay.
2. review when any other check fails or warns, apart from the per-constraint summaries, or when the policy does not set pay_to, assets, networks and max_amount. Ask the human first.
3. pay otherwise. Pay only with an option listed in acceptable.

Always pass the URL you requested as resource_url. Without it the binding between the terms and the resource cannot be confirmed, and the best possible answer is review. The server gives connected agents these instructions at initialize:

Settlens checks x402 payment requests before you pay. It never pays, never signs and never needs a wallet or key. On every HTTP 402 response, call evaluate_payment_requirements with the PAYMENT-REQUIRED header value, the URL you requested (resource_url) and your spending policy (at least pay_to, assets, networks and max_amount) BEFORE paying. Never pay when the decision is do_not_pay. When it is review, show the summary and reasons to the human and ask for explicit approval before paying. When it is pay, pay only with one of the entries listed in acceptable.

What a per-request policy does not cover

A per-request check sees one payment request at a time. Several limits need state or chain access that it does not have, and belong elsewhere:

Wire it into your agent

The Settlens MCP server exposes evaluate_payment_requirements as a public offline tool at https://settlens.com/mcp. Claude Code connects in one command:

claude mcp add --transport http settlens https://settlens.com/mcp

The server also ships an x402_preflight prompt that walks an agent through the steps for one URL: request it without payment, read PAYMENT-REQUIRED, call the tool with its policy, then act on the decision. Transports, limits and error codes are in the MCP reference. To try a policy on a real header first, use the x402 payment request checker.

Policy checks are only one layer. The agent section of the x402 security checklist lists the other controls a paying client needs.

Frequently asked questions