Skip to content
AI DEFENSE LIBRARY

💸 Unbounded Consumption and Denial of Wallet (LLM10): How to Protect an AI System from Runaway Spend and Financial Exhaustion

Who this is for: Teams operating LLM services and AI agents on pay-per-token / pay-per-inference pricing — where every request to the model costs money, and an uncontrolled stream of calls turns from an availability incident into direct financial damage.

Unbounded Consumption (formerly Model Denial of Service) is a class of vulnerabilities in which an application permits excessive and uncontrolled model output: an overwhelming number of requests, context inflation, resource-heavy computation. The outcomes are denial of service (DoS), service degradation, model theft, and — often the scariest for a business — economic damage, "Denial of Wallet" (DoW): the attacker doesn't take the service down but generates a volume of billable calls that hands the company an unpayable bill. This class is recorded in the OWASP Top 10 for LLMs 2025 as LLM10:2025 Unbounded Consumption. This page walks through the overspend vectors and shows what the Spectorn defense layer (a set of detection and blocking engines that runs within Spectorn) does about them. An honest framing up front: the actual load limiting — rate limiting, quotas, token budgets, and timeouts — lives at your API gateway, not in the detection engines. The defense layer's role here is detection and correlation: recognize a flood or inflation pattern and raise an alert so the gateway and the playbook apply throttling.

Part of the threat series: OWASP LLM Top 10 · Autonomous AI Agents · Excessive Agency · Data Exfiltration.


What Denial of Wallet Is and Why Tokens = Money

In the classic DoS model the attacker's goal is to exhaust a compute resource and make the service unavailable. In the LLM world the economics are different: model output is billed by the unit — for input and output tokens, per inference call, per GPU-second. That shifts the attack's center of gravity.

  • DoS — overload the system so it stops answering legitimate users (degradation, queues, refusals).
  • Denial of Wallet (DoW) — don't take the service down at all, but make it run dutifully at maximum billable load. The service is "healthy," but at the end of the month a bill arrives that can shut the company down. On pay-per-token pricing this is the most insidious form: availability metrics are green while the financial pull is red.
  • Model theft — extract a model's behavior/weights through a series of expensive requests; this is both overspend and intellectual-property theft at once.

Why agentic systems are especially exposed. An autonomous AI agent (see Autonomous AI Agents) doesn't make one call — it recursively plans, invokes tools, reads their output, and queries the model again. A single top-level command unfolds into dozens or hundreds of nested inference calls and API requests. Here DoW can occur even without an attacker: a well-meaning employee asks the agent to "research every competitor and assemble a complete report" — and a poorly designed human-in-the-loop launches hundreds of recursive tool calls, each of which costs money. Overspend is not only malice but also an architectural defect in recursion control.

This is exactly why protection against unbounded consumption is two distinct layers that must not be conflated: infrastructure limiting (the gateway throttles the stream) and behavioral detection (the engine and SOC see that the stream is anomalous and raise an alarm). Spectorn owns the second layer and feeds signals to the first.


🛑 Overspend Vectors and What Spectorn Does About Them

1. Token/input flooding — a flood of requests and inflated input

Risk: The attacker generates a high volume of requests — many back-to-back calls or individual giant prompts with variable-length input deliberately tuned to maximize the number of billable tokens. The goal isn't so much to take the service down as to spin up the meter: on pay-per-token pricing, every extra token turns into money. The stream may come from a single source or be spread across sessions to evade naive thresholds.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Spectorn defense:

  • Engines/components: resource_exhaustion, correlation in your SIEM, Decision Logger.
  • resource_exhaustion recognizes resource-heavy input — an abnormally large prompt and patterns aimed at exhausting a resource — and flags the request before it is sent to the model.
  • A pattern spread over many events is a job for your SIEM: Spectorn sends each finding there with the rule, category, severity and verdict_id; its own SOC correlation (GoMCP) is not deployed in the cloud contours.

What Spectorn honestly does NOT replace: the rate limiting itself. Rate limiting, per-tenant quotas, and token ceilings are settings on your API gateway that physically throttle traffic. Spectorn recognizes that the stream is anomalous and raises an alert; the gateway performs the throttling per the playbook. The engine does not "brake" traffic on its own.

2. Recursive context expansion — inflating the context window

Risk: The attacker forces the system to expand the context again and again: each response is fed back into the input, documents are recursively appended, the conversation history balloons to the window limit. Because inference cost grows with context length, this "winding up of the window" (context-window flooding) turns a single conversation into an expensive funnel — the token count multiplies at every step.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Spectorn defense:

  • Engines/components: resource_exhaustion, correlation in your SIEM.
  • resource_exhaustion recognizes patterns of avalanche-like input expansion and instructions aimed at winding up the context, flagging them as resource-exhausting.
  • Growth in request length within a single session is a context-flooding indicator: build the rule in your SIEM and apply the length/context ceiling at your API gateway.

What Spectorn honestly does NOT replace: a hard ceiling on context size and request length. The maximum window, history truncation, and an input-token limit are settings on the gateway and the application itself, not on the detection engine. Spectorn signals the inflation; the infrastructure enforces the limit.

3. Recursive agent cost attack — recursive agent overspend

Risk: The agent is given a task that unfolds into an uncontrolled tree of calls: "research every competitor and assemble a complete report," "crawl the entire site and index every page." The agent recursively plans, invokes tools, reads the output, and queries the model again — hundreds of nested inference calls and API requests for one command. The danger is that the initiator can be either an attacker or a well-meaning employee: a single poorly designed human-in-the-loop with no recursion ceiling can trigger a DoW event. The agent drifts away from a predictable goal into a mode of endless expansion, sometimes "spinning" with no real progress.

OWASP LLM10:2025 Unbounded Consumption, LLM06:2025 Excessive Agency · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Spectorn defense:

  • Engines/components: goal_predictability, false_completion, correlation in your SIEM.
  • goal_predictability is a behavioral heuristic engine: it flags patterns in the agent's commands that drive it off its intended goal into a runaway-expansion mode — a recursive "crawl everything" is flagged as such a pattern long before the bill balloons.
  • false_completion catches loops with no real progress: the agent reports advancement or spins in place without getting closer to completion — a behavioral marker of cost runaway. The SOC correlates the pairing "goal drift + call spike."

What Spectorn honestly does NOT replace: hard recursion limits and human control. A ceiling on agent depth/step count (max-recursion, max-steps), a budget on the number of tool calls, and a mandatory human-in-the-loop on expensive branches are controls of the gateway and the agent orchestrator. Spectorn recognizes runaway behavior and raises an alarm; the infrastructure stops the chain per the playbook. Least privilege and human-in-the-loop remain mandatory organizational measures (see Excessive Agency).

4. API key theft → Denial of Wallet

Risk: The attacker obtains a stolen API key (leaked in a repository, in logs, via data exfiltration or a confused deputy) and runs a mass stream of expensive inference requests through it — on your dime. This is no longer hypothetical but a documented real incident. According to Sysdig's LLMjacking research, the use of compromised cloud credentials against AWS Bedrock drove costs on the order of $46,000 per day. In another reported case (March 2026) a stolen Google Gemini API key ran a bill up to roughly $82,000 over 48 hours. The service stays "healthy" throughout — the attack hits the wallet, not availability.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Spectorn defense:

  • Engines/components: correlation in your SIEM, Decision Logger, resource_exhaustion.
  • A pattern spread over many events is a job for your SIEM: Spectorn sends each finding there with the rule, category, severity and verdict_id; its own SOC correlation (GoMCP) is not deployed in the cloud contours.
  • The Decision Logger maintains a tamper-evident chain of decisions (SHA-256/HMAC): a provable trail of "when the anomalous stream began and from which source" for forensics and bill disputes. resource_exhaustion flags the resource-heavy requests in that stream.

What Spectorn honestly does NOT replace: key management and financial safeguards. Key rotation and revocation, billing circuit breakers (an automatic stop when the budget is exceeded), per-tenant quotas, and spend alerts are controls of the provider, the gateway, and your billing plane. Spectorn detects the anomalous stream and raises an alarm; the gateway and provider perform key revocation and spend cutoff.

5. Resource-intensive queries — crafted resource-heavy requests

Risk: The attacker shapes individual requests so that each forces the model into prolonged processing: tasks that provoke long generation, multi-step "reasoning," calls to heavy tools. Even a moderate number of such requests yields disproportionate load and cost — many expensive output tokens and a long hold on compute per call.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0029 (Denial of ML Service), AML.T0034 (Cost Harvesting).

Spectorn defense:

  • Engines/components: resource_exhaustion, cognitive_guard, correlation in your SIEM.
  • resource_exhaustion recognizes input aimed at exhausting a resource — constructs that provoke disproportionate processing — and flags it before execution.
  • cognitive_guard signals abnormally heavy requests that fall outside the normal profile; the SOC correlates a series of such events so the gateway can apply a timeout and a cost ceiling per call.

What Spectorn honestly does NOT replace: timeouts and per-call limits. Maximum request processing time (request timeout), an output-token ceiling, and a limit on "reasoning" depth are settings on the gateway. Spectorn recognizes a resource-heavy request and raises an alert; the infrastructure aborts the overrunning processing on timeout.


🛠️ Policy settings

There is no configuration file to deploy: the platform operator sets your tenant's policy at your request, including the scan mode (enforce, or shadow to see what would be blocked without blocking it), allow and deny lists, the block threshold and category weights. The engines that matter most for this sector: resource_exhaustion, goal_predictability, false_completion, cognitive_guard. Start in shadow mode on your own traffic, review what would have been blocked, then enforce.

🚨 Correlation in your SIEM

Spectorn sends each finding to the SIEM you configure as a JSON event over HTTPS (spectorn.ai-finding.v1), with the rule, category, severity and verdict_id. Build multi-stage rules for this sector there, for example: an anomalous spike of events from one sensor/session — an indicator of flooding or a compromised key; an avalanche of tool calls from one agent session in a short window — recursive overspend (DoW). Spectorn's own SOC correlation (GoMCP) is not deployed in the RU and Global cloud contours.

❓ Frequently Asked Questions (FAQ)

What is Denial of Wallet (a wallet attack)? Denial of Wallet (DoW) is an attack in which the adversary doesn't take the service down but generates a volume of billable model calls (tokens, inference) that hands the company an unpayable bill. On pay-per-token pricing this is especially dangerous: the service is formally "healthy," availability metrics are green, yet the financial load can shut the business down. DoW is the key emphasis of the OWASP LLM10 Unbounded Consumption class. A pattern spread over many events is a job for your SIEM: Spectorn sends each finding there with the rule, category, severity and verdict_id; its own SOC correlation (GoMCP) is not deployed in the cloud contours.

What is unbounded LLM consumption (LLM10)? Unbounded Consumption (formerly Model Denial of Service) is the OWASP LLM10:2025 class in which an application permits uncontrolled resource spend: an overwhelming number of requests, context inflation, resource-heavy computation. The outcomes are denial of service (DoS), degradation, model theft, and economic damage (Denial of Wallet). It is especially dangerous for agentic systems with recursive calls, where one command unfolds into hundreds of billable requests.

How do I protect against token overspend and runaway API costs? It's two layers. The infrastructure layer is mandatory: rate limiting, per-tenant quotas, token ceilings, timeouts, and billing circuit breakers on your API gateway. A pattern spread over many events is a job for your SIEM: Spectorn sends each finding there with the rule, category, severity and verdict_id; its own SOC correlation (GoMCP) is not deployed in the cloud contours. The engines see the anomaly and raise an alarm; the gateway throttles the stream. Without infrastructure limits, detection alone won't stop overspend.

Can an AI agent cause a Denial of Wallet on its own? Yes, with no attacker at all. An autonomous agent recursively plans, invokes tools, and queries the model again — one command, "research every competitor and assemble a report," unfolds into hundreds of nested inference calls. If the design has no recursion ceiling and no human in the loop on expensive branches, a well-meaning employee can trigger a DoW event themselves. goal_predictability heuristically flags the agent's drift off its intended goal into runaway expansion, and false_completion catches loops with no progress; a hard max-recursion and human-in-the-loop are set on the gateway.

Does Spectorn do rate limiting? No — and this is a fundamentally honest boundary. Spectorn owns detection: the engines recognize flooding, context inflation, and runaway agent behavior, and each finding reaches your SIEM. The actual throttling — rate limiting, quotas, timeouts, recursion ceilings — is performed by your API gateway as an infrastructure control. Spectorn feeds the gateway signals of "the stream is anomalous, throttle it," but it does not brake the traffic itself. Don't trust framing in which a detection engine "limits load" — that's the gateway's job.

How do I detect a flood attack on an LLM? A flood is visible by frequency, not by a single event. A pattern spread over many events is a job for your SIEM: Spectorn sends each finding there with the rule, category, severity and verdict_id; its own SOC correlation (GoMCP) is not deployed in the cloud contours. At the input level, resource_exhaustion flags abnormally large and resource-heavy requests, and a rule in your SIEM tells a legitimate peak from a stream spread across sessions. The Decision Logger preserves a tamper-evident trail for review. From there the playbook asks the gateway to throttle the source.

What do I do if an API key is stolen? Immediately: revoke and rotate the key, stop spend with the billing circuit breaker, check the tenant's quotas — these are infrastructure actions on the provider and gateway side. A pattern spread over many events is a job for your SIEM: Spectorn sends each finding there with the rule, category, severity and verdict_id; its own SOC correlation (GoMCP) is not deployed in the cloud contours. Real incidents (Sysdig's LLMjacking — on the order of $46,000/day on AWS Bedrock; a stolen Gemini key — roughly $82,000 over 48 hours) show that the bill spins up within hours, which is why early detection is critical.


📚 Sources

Related guides: OWASP LLM Top 10 · Autonomous AI Agents · Excessive Agency in AI Agents · Data Exfiltration · Supply-Chain Risks · Insecure Output Handling

Unbounded Consumption (LLM10): Cost Controls | Spectorn