Why LLM provider spending limits do not stop runaway AI agents

What provider spending limits are good for

Hard spending limits and billing alerts in a provider console are worth configuring. OWASP's guidance on unbounded consumption recommends them for all third-party AI services. It lists them alongside gateway or middleware rate limiting and input size limits, not as a standalone safeguard. That placement is the right reading: a spending limit is one layer in a set of controls.

The limitation is structural. A spending limit is a billing construct. It is evaluated against accumulated usage for an account, project, or key. It has no representation of which agent made a request, why, what tool the model asked to invoke, or whether the same call has now been made forty times in a row. It answers the question "how much has this account consumed?" and not "is this agent behaving as intended?"

That distinction matters for platform teams because the two questions call for different mechanisms. The first is answered from usage totals. The second has to be answered inside the request path, with the agent, session, and tool call in view.

Failure modes a billing-level limit does not address

The table below separates what a limit scoped to an account or key can express from what a control in the execution path can express. The point is not that billing limits are useless, but that they act on a different object.

• Runaway loops: A billing limit sees rising spend and, at best, reacts when a threshold is crossed. Runtime enforcement can apply call-count, retry, and chain-depth thresholds to the loop itself and stop it at the Nth iteration.
• Tool-call fan-out: Repeated calls to tools or MCP servers are not visible as a pattern in usage totals. Runtime enforcement can rate limit per tool and per tool chain.
• Non-token side effects: A write to a downstream system or a data return through a tool executes outside the model call and carries no token cost to cap. Only a policy decision on the tool call can allow, block, or escalate it.
• Multiple providers and keys: A limit configured in one console governs that console's usage. An agent that spans several models, providers, or keys needs one policy applied consistently in the path.
• Enforcement timing: A limit tied to reported usage depends on when usage is counted and reported. A runtime check evaluates before the call proceeds.
• Blast radius: When a cap is defined at account or key scope, reaching it affects every workload sharing that scope. Runtime limits can target the one session, agent, or tenant that misbehaves.

Three runaway scenarios, and which control acts

Consider first a plain iteration loop. OWASP describes an agent that can autonomously loop or chain external tool calls without rate limits or budget controls. In its illustrative scenario, which is a threat model and not a documented incident, a bot runs through a long session and exhausts a monthly API budget within the first couple of hours. A spending cap eventually ends this, but only after the budget is gone. A chain-depth or call-count limit ends it at a threshold set for that agent.

Now consider fan-out. An agent decomposes a task into subtasks and calls the same tool or MCP server repeatedly, perhaps in parallel. OWASP notes that agents adapt dynamically as they decompose tasks, which can evade static checks. Each call may be small. The harm comes from the pattern, which only a per-tool or per-tool-chain limit can observe.

The third case is not a runaway at all. OWASP is explicit that excessive agency involving high-impact operations is not a runaway-iteration problem: a single action by an agent with access to several high-value systems can cause irreversible cross-system impact. One write, one export, one deletion. No spend threshold is ever approached. The relevant control is least privilege at the action level and human approval before the action executes.

What audit-ready evidence looks like

A usage or billing report describes consumption. It does not describe what an agent was permitted to do or why a particular call was stopped. Evidence generated by enforcement answers a different question: what limits were in force, and what happened when an agent met them.

For each decision, a useful record identifies the agent and session, the model or tool involved, the policy that applied, the outcome (allow, block, rate limit, or escalate), the time, and, for escalations, who approved or declined. Because the record is produced at the moment of the decision, it does not need to be reconstructed from separate systems afterward. Consistent records across models, providers, tools, and MCP servers matter most where a single agent spans all of them.

OWASP's guidance says production agents should retain evidence of their controls, and that documented limits on tools, data access, and action authority help demonstrate that limits were defined. Retention period and data residency are configuration questions to settle with compliance teams early.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, and MCP servers, covering allow, redact, block, rate limit, and escalate for human approval on individual interactions and tool calls. The audit-ready evidence it produces is generated by enforcement and mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST.