Spend7

Spend limits an agent cannot talk its way past

A budget written into a system prompt is a suggestion. The agent that overspends is usually not the one that was told to; it is the one that looped, or that was handed a task whose cost nobody estimated, or whose credential ended up somewhere else.

A spend limit belongs at the payment, in something the agent does not control. Spend7 holds the caps; the agent's payment client asks before it spends; the answer is allow, flag or deny. Nothing in the prompt can move the cap, because the cap is not in the prompt.

Caps are rolling, not calendar. A daily cap means the last 24 hours, which is what you actually meant, because a calendar cap resets at midnight in a timezone nobody agreed on and lets an agent spend twice its limit across a boundary.

Every cap that applies is evaluated, not just the tightest, and the response shows all of them with how much is used. A manager agent can read the headroom before delegating rather than discovering it on a refusal, and a dashboard can show you which cap is about to bind before it does.

Only payments that were not denied count towards a cap. A denied payment never moved money, and counting it would let a burst of denials lock out the legitimate payment that follows.

What that actually is, in the product

  • Scopes: global, per agent, per merchant, per category, or a specific agent at a specific merchant.
  • Windows: per payment, or rolling hour, day, week or month.
  • A cap can be decisive (deny on breach) or advisory (flag on breach), set per cap.
  • Merchant allowlists and blocklists, and category blocks, evaluated alongside the caps.
  • The whole policy is replaced in one transaction, so it can never be half-applied.
spend7.com/dashboardPreview
Plan
Pro
Checks today
1,204
Caps active
6
Spend limits
research-agent-01 · daily62%
shopping-agent · daily91%
Transaction log
research-agent-01allow
shopping-agentdeny
procurement-agentflag

Questions

How do I set a spend limit for an x402 agent?
Create an agent-scoped cap against the agentId your payment client sends, then call /api/v1/risk-check before each x402 settlement. The cap is enforced identically whatever the rail; the rail only changes which extra protocol checks run alongside it.
What happens when an agent hits its cap?
The check returns deny with the cap that was breached, how much was already spent in the window, and what this payment would have taken it to. Your client refuses the payment. If you would rather be told than blocked, set that cap's action to flag and it becomes advisory.
Can I test a spend policy before adopting it?
Yes: send the policy and a sample history in the request's context object and the check scores statelessly against exactly what you sent, reading nothing stored and writing nothing. It is the same engine, so what you see is what the stored policy would do.
A real-time fraud detection API built for payments no human is watching When an agent payment goes wrong, the evidence already exists API reference →