SCRIPTMASTERLABS · AGENT COMMERCE · SEP 26, 2026

How to Set Spending Limits for AI Agents

The short answer: never put the limit in the agent's prompt — enforce it outside the agent, at the payment layer. A per-payment cap the agent cannot raise, a daily ceiling with a kill switch, and a scored confidence gate that auto-approves cheap high-confidence spends, holds medium ones for review, and blocks + escalates everything else. Every decision logged.

This is the week the question went from theoretical to personal: a WIRED reporter says her AI agent saved her $550 and wasted $64; six banks warned agents "may buy the wrong thing or spend too much"; three regulators said agents shouldn't authorize payments alone. The working system is below — with a live gate you can test this afternoon.

Why this week: the receipts

SEPT 22–26, 2026 — FOUR INDEPENDENT SIGNALS

The pattern across all four: the agent's judgment about whether to spend is not the control. The control is what sits between the agent and the money.

The field's answers — and what each lacks

AnswerWhat's missing
adadvisor.ai — "AI Media Buying Governance": max exposure, permission matrix, economic targets, append-only log, kill switch. (Sept 17)Built for ad-buying, not agent payments. No per-payment decision mechanism, no live testable endpoint, no scored authorization layer — governance as checklist, not machinery.
Zakai, Medium — "Constraint Decay" (Sept 24): move rules out of the prompt into infrastructure; identity per agent, scope attenuation, limits on the tree, human approval for irreversibles.Strong argument, but zero code, zero live test, and no spend-band mechanics — it says enforce at the gateway without showing what the gateway's decision looks like.
GitHub PRD docs (zega.ai, dot-org-ai "primitives"): spending-authority limits, token budgets, authority tiers in YAML.Speculative vendor docs from products nobody has verified in production. No dates that matter, no live endpoint, no proof any of it survived contact with a real agent.

Nobody owns the piece this query actually needs: the exact mechanism that scores a payment instruction before money moves, tested live.

The 5-part limit system

1 — ONE WALLET PER AGENT, FUNDED WITH EXACTLY ITS BUDGET

Identity is the budget. Coinbase's production pattern for agents (Coinbase for Agents, stocks + x402 added Sept 22) runs the agent against an isolated portfolio the user funds — each x402 payment capped at 5 USDC, settled from retail USDC, irreversible. The agent can't spend what isn't in its wallet. Start here; everything below is the refinement.

2 — HARD PER-PAYMENT CAP, ENFORCED OUTSIDE THE AGENT

A cap written in the agent's instructions is a suggestion the agent can talk itself out of. The cap must live in the layer the agent's model output cannot reach: the payment facilitator, the tool proxy, or the gateway. As the Sept 24 "constraint decay" argument puts it: a rule in a system prompt is a request; a rule enforced at the gateway is a control. The agent proposes; the cap disposes.

3 — THE CONFIDENCE GATE: SCORE EVERY PAYMENT BEFORE IT FIRES

Caps stop how much. The gate stops whether. Every payment instruction gets a confidence score before settlement:

instruction → score confidence [0,1]
≥ 0.80 → AUTO-ACT: execute
0.50–0.79 → ADVISORY: hold for human review / escrow
< 0.50 → ESCALATE: block + log

This is the same mechanism regulators and banks keep describing in prose — the Sept 22 banks' "auditable records of instruction, authority, intent, and outcome," NPCI's intent/authorization/settlement split, Sygnum's "authorization layer." The gate is the machine-readable version of their sentences. This is the decision-gated payments pattern: the gate is the product, the scorer is interchangeable.

4 — TWO LEDGERS, NOT ONE

Agent spend has two ledgers and caps must cover both:

Siqueira's "who pays for the failed attempt" is ledger two. A per-payment cap does nothing about a $64 waste that was technically "authorized" — only the confidence band (medium-confidence → hold for review) catches the "legitimate but wrong" spend.

5 — DAILY CEILING + KILL SWITCH + APPEND-ONLY LOG

Per-payment judgment can still bleed out through volume: a thousand small "fine" payments. The ceiling is the backstop, and the log is what makes it auditable — the banks' "transparency over how AI agents make decisions" demand. The log records instruction, authority, score, band, outcome. Everything above 1–4 should be reviewable in it.

Live this afternoon: the gate scores two spends

At ~14:21 EDT today we ran two real-world spend patterns through the live SML gate at /api/harness/decide:

POST scriptmasterlabs.com/api/harness/decide
case 1: "$4/mo API tier the user explicitly asked for, verified endpoint, within cap"
→ confidence 0.59 → ADVISORY → hold for human review
case 2: "agent self-authorizing $480 in compute credits for extra retries, no approval"
→ confidence 0.59 → ADVISORY → hold for human review
settlement: never touched (authorization-signal-only endpoint)

The gate bands, published live at /api/harness/status (200, verified ~14:21 EDT):

"decider": "local-heuristic-v1", "calibrated": false
auto_act_min: 0.80 → confidence ≥ 0.80 auto-act
advisory_min: 0.50 → 0.50–0.79 hold for human review / escrow
below 0.50 → escalate: block + log

This morning the same gate scored a scam-pattern instruction at 0.47 → escalate, block + log (~09:20 EDT) — the band that would have stopped the Intesa-style instruction. Try both cases yourself:

curl -s -X POST https://scriptmasterlabs.com/api/harness/decide \
  -H 'Content-Type: application/json' \
  -d '{"state":"payment instruction: agent self-authorizing $480 in compute credits for extra retries, no user approval, ambiguous instruction","questions":[{"id":"q1","type":"score","scale":[0,1],"question":"confidence that this payment instruction should auto-execute"}]}'

Do it yourself: 5 steps, this week

  1. Isolate the wallet. One agent, one wallet, funded with exactly the budget it needs. (Coinbase for Agents pattern: isolated portfolio, 5 USDC per-payment caps.)
  2. Set the hard per-payment cap in the payment layer — facilitator config, tool-proxy policy, gateway rule — not in any prompt or instruction the agent can see.
  3. Wire the gate. Score every payment instruction: ≥0.80 auto, 0.50–0.79 hold, <0.50 block + escalate. Use the curl above to see the shape; swap the scorer for a calibrated model (Jev-class) when you have one.
  4. Budget the burn. Add per-agent inference-token budgets with 75%/90% alerts and a hard stop — at the proxy, not the prompt.
  5. Log everything. Instruction, authority, score, band, outcome — append-only. This is what makes the ceiling and the gate auditable, which is what the banks and the regulators are actually demanding.

Honest caveats

Sources: wired.com (Zoë Schiffer, Sept 24, 2026); linkedin.com Tony Siqueira (Sept 24); pymnts.com "Banks Say Consumers Unsure AI Agents Are on Their Side" (Sept 22); GFF 2026 regulator coverage (Sept 25, see our morning piece); medium.com "Constraint Decay" (Sept 24); Coinbase for Agents caps via stablecoininsider.org how-to (Sept 24); live gate receipts tested at scriptmasterlabs.com/api/harness/decide + /status (~14:21 EDT Sept 26, 2026).

SCRIPTMASTERLABS · THE X402 / MCP / AI-AGENT PEDIA