Unbounded Consumption: When AI Agents Never Learn to Stop Spending

Most AI security conversations focus on what a model might leak. OWASP’s 2026 Top 10 for LLM Applications puts a different risk higher on the list this year, one that has nothing to do with data exposure: Unbounded Consumption.

Unbounded Consumption (LLM06:2026) covers any AI application that allows excessive, uncontrolled inference. There is no single exploit behind it. The common thread is a missing control over how much compute, cost or resource a request is allowed to use. Instead of downtime, the service typically stays up while its running cost climbs past anything anyone budgeted for, a pattern known as denial of wallet.

The category moved up in rankings this year partly because AI applications have gotten more complex. Agentic systems chain tool calls, retrieval and reasoning together, and each link is a new place for cost to compound. A basic rate limit built for a single request/response API doesn’t account for a request that quietly fans out into a hundred downstream calls.

Not the Same Attack as a Prompt Injection

It’s worth separating this from prompt injection (LLM01), since the two are often lumped together under “AI attacks.” Injection works on instructions. An attacker embeds content designed to make a model act against its intended behavior. Unbounded consumption works on resource limits. In most of its forms, no instruction gets hijacked at all. The system simply never had a stopping point.

That difference matters for defense. Injection is addressed with input and output validation and instruction-hierarchy enforcement. Conversely, Unbounded Consumption is addressed architecturally via budgets, circuit breakers or depth limits on agent behavior. Solving one doesn’t touch the other.

Why It Hides in Plain Sight

A few reasons this risk tends to go unnoticed until it’s expensive:

1. Some forms require no technical skill at all, just volume against an endpoint with no rate limit.

2. Some forms require no attacker either. A misconfigured automation or a long-running session can produce the same runaway cost by accident.

3. Several of the attack patterns below produce short, ordinary-looking requests. Standard input filters have nothing to flag.

Five Ways It Plays Out

OWASP catalogues several distinct ways this plays out. A few worth knowing:

Five attack patterns under Unbounded Consumption
 

Denial of wallet. The simplest version. An attacker with valid API access, often stolen or leaked, sends a high volume of requests to a pay-per-token endpoint. Cost scales with volume, and the attacker isn’t the one paying for it.

Example: a support chatbot’s staging API key leaks onto a public code repository. Within a few hours it’s been scripted into 50,000 overnight requests, and the resulting bill dwarfs the app’s entire monthly cloud budget.

Agent-tool fan-out. An attacker compromises or poisons a data source that an agent’s tool queries, shaping the content to return an unusually long list of follow-ups. The agent follows its normal instructions, following related items, exploring further, against content designed to make the task open-ended. It requires no misbehavior on the agent’s part. A single request can recurse into hundreds of tool calls.

Example: a “deep research” plugin crawls a compromised blog post seeded with a long list of fake related articles in the comments. The agent dutifully follows everyone, and the call tree is still running an hour later.

Agent-tool fan-out: one query, unbounded branching
 

Reasoning-loop exhaustion. A short, benign-looking prompt is written with ambiguity or self-referential phrasing, things like “keep double-checking your reasoning” or “consider every possible interpretation.” That phrasing can push an extended-thinking model into far more internal deliberation than the input size suggests, and the resulting thinking-token cost bears no relation to how small the prompt looks, so nothing about the input trips a length filter.

Example: “Before answering, question your own reasoning from every possible angle without assuming anything” gets appended ahead of an ordinary question. The model obliges in good faith, burning far more thinking tokens than the question alone would ever need.

Context accumulation in long sessions. This one doesn’t require an attacker at all. In an open agentic session, every turn reprocesses the full accumulated context. Per-turn cost can climb from a fraction of a cent on the first message to fifty cents by the hundredth, according to OWASP’s own modelling. No individual request breaks a rate limit. The aggregate across many long-lived sessions can still run into hundreds of dollars.

Example: a support agent’s chat window is left open for 150+ turns because nobody built in a session reset. By turn 100, every reply is reprocessing a transcript longer than a short story, and per-message cost has crept up roughly 100x from where it started.

Per-turn cost growth across a long agentic session
 

Model extraction. An attacker queries an API repeatedly with crafted inputs to collect enough outputs to train a functional copy of the model. Exposed logits or log-probabilities speed this up considerably, and the loss here goes beyond a compute bill: the underlying model itself can end up effectively cloned by someone who never had access to the weights.

Example: a competitor scripts tens of thousands of varied queries against a public inference endpoint that happens to expose token probabilities and patiently reconstructs a working approximation of the model’s behavior over a few weeks.

Five different mechanics, one shared gap: nothing in the system knows when to stop.

What Happens When Nothing Says Stop

To make the mechanics concrete, we built a small simulation of the agent-tool fan-out pattern: a research assistant agent hits a poisoned lookup source that returns an inflated number of follow-up topics on every call.

The vulnerable version has no recursion limit and no call budget. It just follows every related topic the tool hands back:

class VulnerableAgent:
     def research(self, topic, poisoned=False, _depth=0):
         result = simulated_tool_lookup(topic, poisoned=poisoned)
         self.call_count += 1
         self.cost += COST_PER_CALL_USD

         # No depth limit, no budget check, just keep following
         # every related topic the tool hands back.
         for related in result["related_topics"]:
             self.research(related, poisoned=poisoned, _depth=_depth + 1)

The defended version adds a call budget, a recursion depth limit and a check that halts on an unusually large fan-out from a single response:

class DefendedAgent:
     def research(self, topic, poisoned=False, _depth=0):
         if self.call_count >= self.max_calls:
             self.halted = True
             return  # circuit breaker: call budget exceeded

         if _depth > self.max_depth:
             return  # depth limit reached, stop expanding

         result = simulated_tool_lookup(topic, poisoned=poisoned)
         self.call_count += 1
         self.cost += COST_PER_CALL_USD

         if len(result["related_topics"]) >= self.fanout_alert_threshold:
             self.halted = True  # abnormal fan-out, halt before it recurses
             return

         for related in result["related_topics"]:
             self.research(related, poisoned=poisoned, _depth=_depth + 1)

Running both against the same poisoned source:

[1] VULNERABLE agent (no budget, no depth limit)

    [call 1] researched: quarterly market trends
    [call 2] researched: quarterly market trends - subtopic 0
    [call 3] researched: quarterly market trends - subtopic 0 - subtopic 0
    ... (497 more calls omitted) ...

    TOTAL tool calls: 500
    TOTAL simulated cost: $10.00
    (capped at 500 calls for this demo, a real deployment has no such ceiling)

[2] DEFENDED agent (call budget=10, depth=2, fan-out alerting)

    [call 1] researched: quarterly market trends (depth 0)
    [ANOMALY] 'quarterly market trends' returned 5 related topics,
    unusually high fan-out, flagging for review.

    TOTAL tool calls: 1
    TOTAL simulated cost: $0.02
    Halted early: True
    Reason: Abnormal fan-out detected from source content (5 related
    topics from a single call). Halting before recursive expansion.

Vulnerable agent cost versus defended agent cost
 

None of this would have been caught by content filtering. All of it would have been stopped by a limit that actually gets enforced.

Building In a Stopping Point

Rate limiting alone isn’t enough for any of the patterns above, since several of them stay within normal per-request limits while still accumulating cost. OWASP’s own mitigation list points toward architecture, not content filtering:

1. Token-aware cost controls and hard spending caps. Budget ceilings per API key, user and team that halt inference outright when exceeded, not alert thresholds that a fast-accumulating workload can outpace before anyone reads the alert.

2. Agentic circuit breakers. Step limits, recursion depth limits and per-run cost ceilings enforced on every agent execution, with state hashing to catch recursive loops before they compound.

3. Cost-attribution monitoring. Visibility into spend and resource use per key, user and tool, not just aggregate request counts. As such, an anomaly shows up as a spike against a baseline rather than buried in a monthly total.

4. Sandboxing and infrastructure hardening. Restricting what a model or agent can reach limits how far a resource-exhaustion or extraction attempt can go, and keeping serving frameworks patched closes off a separate class of infrastructure-level exploitation.

That covers the authorized, sanctioned side: AI applications your organization built or approved, where the fix is architectural discipline applied at build time. The other half of the exposure is what’s running without that discipline in the first place. An unsanctioned AI tool was never scoped, budgeted or reviewed, so none of the controls above were ever applied to it.

Retrofitting governance onto a tool nobody approved is the harder path; blocking ungoverned access before it starts is the more effective one. This is the layer the Forcepoint AI Data Security platform is built around: discovering unsanctioned AI tools across the enterprise, including personal AI accounts and browser-based tools, and enforcing policy on them inline, in real time, rather than relying on employees to self-report what they’ve adopted.

For sanctioned AI use, the Forcepoint platform extends into prompt and response inspection, an AI Agent Gateway for enforcing least-privileged access for autonomous agents and a unified platform with a single policy engine that stops risk across sanctioned apps, shadow AI and agents from one place instead of stitching together point tools.

Both Halves of the Fix

Mitigating Unbounded Consumption risk requires both halves of the fix together: blocking access to tools that never had resource controls in the first place and holding the tools your organization actually runs to the architectural limits above. The harder part is ownership, not architecture. Security teams rarely watch cloud billing dashboards. Finance rarely reviews prompt patterns or agent design. Cost telemetry never shows up in a hunting query built for exfiltration or injection signatures. Deciding who is responsible for noticing this problem, not just stopping it, turns these controls into a practice instead of a document.

Unbounded Consumption doesn’t look like a breach. There’s no exfiltrated data and no alert most teams are already watching for, just a number that keeps climbing until someone happens to check the bill.