AI Agent Spending Limits

How much should an agent be allowed to spend — and why "how much" is only half the answer.

The question

Agents burn tokens, call paid APIs, trigger cloud spend and move money. Teams answer with limits: a per-transaction cap, a daily budget, a whitelist. That instinct is right — but a limit answers how much, while the harder question is whether this specific payment is allowed at all.

Why a limit alone is insufficient

A spending limit is necessary, but it is not a complete authorization model. Limits constrain quantities; they don't judge intent:

• A $50 cap doesn't stop five $40 calls — transaction splitting changes the effective total.
• A daily budget doesn't stop a retry storm that spends the whole day in one incident.
• Parallel actions can race a budget check: two concurrent requests both see "budget remaining" and both pass.
• A limit never asks who is this recipient? — the wrong merchant gets the money as long as it fits the cap.

Limits are the frame. Authorization is the judgment inside the frame.

Threat / failure modes

• Runaway loop — an agent retrying a failing action, each retry within the cap, until the budget is gone.
• Splitting — dividing one large payment into many cap-sized ones.
• Concurrency race — N parallel requests passing a shared budget check.
• Wrong recipient — a trusted cap, an untrusted destination (typo, injection, tampered parameter).
• Stale authorization — "approved" once, replayed later after the policy changed.

Architecture: limits inside an authorization decision

payment request (amount, recipient, agent)
        │
        ▼
authorize()  ── evaluated in one place, atomically:
        │       ├── per-transaction cap
        │       ├── budget window (daily/monthly, cumulative, per agent)
        │       ├── merchant / recipient policy (allow / block)
        │       ├── approval threshold (over $X → human)
        │       └── identity (which agent is spending)
        ▼
ALLOW (signed grant) / APPROVAL (human) / DENY
        ▼
executor verifies the grant — then, and only then, the rail executes

Because every check happens outside the agent loop, in one atomic decision, splitting and racing can't dodge it: the budget counter is updated in the same step as the decision, and execution requires the grant.

Minimal policy

# policy.yaml
version: "2.1.0"
policy:
  budget:      { daily: 100, monthly: 1000 }   # cumulative windows
  transaction: { max: 50 }                      # per-payment cap
  merchants:
    allowed: [openai.com, mcdonalds.com]        # recipient policy
    blocked: [scam-vip.com]
  approval:    { over: 30 }                     # over $30 → human
agents:
  shopping-agent:
    budget:      { daily: 50 }
    transaction: { max: 25 }

from spendshield import SpendShield
shield = SpendShield(dry_run=False)
shield.load_policy("policy.yaml")
r = shield.authorize(agent="shopping-agent", amount=40, to="openai.com")
# $40 > $30 approval line → APPROVAL (human decides)
r = shield.authorize(agent="shopping-agent", amount=45, to="scam-vip.com")
# → DENY (blocked merchant), regardless of budget

ALLOW / APPROVAL / DENY in practice

Where SpendShield fits

SpendShield implements this model — limits as one part of a deterministic authorization decision, enforced with a signed single-use grant that execution must consume. Open source, MIT, Python + MCP. Try the interactive policy playground to feel the difference between a cap and a decision.

• Library: pip install spendshield
• MCP: uvx --from spendshield spendshield-mcp --policy policy.yaml

Related pages

← Home · GitHub · MIT licensed