"The fourth most expensive x402 mistake: paying without a spending policy"

The wallet is empty. Nothing failed: no reverts, no timeouts, no stuck transactions. Every payment was authorized, every signature was valid, every recipient was legitimate. Your agent just spent ten dollars in increments of ten cents and never once asked whether it should stop.

The fourth most expensive x402 mistake is paying without a spending policy. The first three mistakes were about single payments gone wrong: signing twice for one intent, treating verify as settlement, retrying a payment that already succeeded. This one is about a hundred payments gone right, adding up to a bill nobody authorized.

Two traps make it inevitable:

1. The aggregate trap. You set a per-call cap, say $0.10, and ship. That cap bounds the size of each payment, not the number of payments. An agent that makes a hundred $0.10 calls in a looping task spends $10, and every one of those calls was under the cap. A per-call cap is a speed limit, not a fuel gauge. The Cloudflare Agents SDK write-up on this mechanism is blunt: its x402 client accepts a confirmation callback that reviews payments before money moves, and passing null instead of a callback "lets the agent pay automatically. No judgment. No review." Two failure modes follow from that null: per-call caps don't bound per-task spend, and retries double-pay. The protocol does not help. x402 has no notion of your budget, your task, or your intent. Every payment is locally reasonable; the sum is not.

2. The automated retry storm. Article #3's mistake, automated. A request fails after payment, or the result never comes back, and the agent does what agents do: retries, blindly, each retry a fresh signature and a fresh authorization to move funds. No human ever sees the ambiguity, so the double-payment trap from the paid-no-result incident fires at machine speed until the wallet or the task ends, whichever comes first. An agent with auto-pay and no budget is a double-spend machine with no one watching the register.

Underneath both is a protocol-level gap. x402 makes each payment frictionless and final, and says nothing about the pattern. It settles payments; it does not manage money. Budgeting, approval, and escalation live nowhere in the protocol, which means they live entirely in your code, or they live nowhere at all.

The safe sequence:

1. Budget per task, not just per call. Set a maximum total spend per task or run. When the agent hits it, it stops and escalates; it does not ask for more.
2. Approval threshold. Above a per-payment amount, require human or policy approval. Auto-approve only below it. The confirmation callback is the gate; null removes the gate.
3. Keep a payment ledger. Record every payment: intent, amount, transaction hash, result. Before any retry, check the ledger. An intent that is already paid is never paid again: the retry becomes a status check, not a second payment.
4. Kill switch. A global spend limit per wallet per time window. When it trips, all payment stops until a human resets it. This is the control that works when every other control has a bug.
5. Alerting. Notify at 50% and 80% of budget. Silent budgets are decorative.

This is where the two layers of the stack meet. Incident actions solve the problem once you have it; a mandate prevents the next one. callx402 execute is the incident-side tool: it runs the protected path with --max-budget for the per-task cap, --dry-run to walk the whole pipeline through planning without executing, --approval-threshold to fail closed above a per-payment amount without human approval, and an idempotency dedupe that refuses a retry after a stored UNKNOWN settlement rather than re-signing. Refusals are explicit, not silent: a route with no live wiring is reported as unexecuted instead of hidden.

But a tool invoked by hand only protects the runs you remember to protect. The standing answer is Veyline's economic governor: compile natural-language spending policy into machine-enforced constraints, then authorize every paid step against them. Deterministic, no LLM, fail-closed. Create a mandate with POST /v1/veyline/mandates (conflicting, injected, or empty intents are rejected with 422 and never stored), and every paid step on the subscription and credit paths runs through each mandate's intent firewall before anything is authorized or consumed. Each check returns ALLOW, DENY, or ESCALATE_HUMAN with reasons. Worst decision wins across mandates, and a DENY lands before credit consumption, so a paid single-use credit is never burned on a blocked action. The firewall defaults to DENY: paid steps with no compiled spend cap are denied. It enforces spend caps, provider and network allowlists, deadlines, and retry limits. Idempotency keys are durable, so reusing a key with a different step fingerprint is rejected as replay-substitution. ESCALATE_HUMAN becomes ALLOW only through a single-use human approval, consumed atomically and valid for 15 minutes. Live budget is queryable at any time: committed, reserved, remaining.

Two honest limits: the governor governs the rail's hosted paths. The raw x402 on-chain payment path is not governed by mandates, because that path has no organization to hold one; the authorize endpoint doubles as an advisory control-plane check for anything outside the subscription and credit paths. And a mandate is only as good as its text: write the budget, the caps, and the approval thresholds down before the agent does.

Incident actions solve the problem. Mandates prevent the next one. Full writeups with sources in the callx402 troubleshooting docs: agent auto-pay with no spending cap. The live governor spec is published at payloadhq.github.io/agents.html and the machine-readable agents.json. The repo is github.com/Payloadhq/callx402. When x402 breaks, callx402.