LLM unbounded consumption exposes a new cost-control attack surface

At a glance

What this is: This is an analysis of OWASP LLM10, where uncontrolled inference usage turns LLM applications into a cost and availability risk.

Why it matters: It matters because IAM and security teams must now govern access, rate, and spend around AI systems that can be abused through legitimate-looking identities, API calls, and automated workloads.

By the numbers:

• A single 200k-token request can cost $4-20 USD depending on the model.
• 500 such requests from automated scripts could potentially drain tens of thousands of dollars in under an hour.
• Your $2,000 bill you’ve budgeted for is now a $47,000 bill.
• The OWASP Top 10 for Large Language Model Applications (2025) identifies this as LLM10: Unbounded Consumption.

👉 Read StackHawk's guide to OWASP LLM10: Unbounded Consumption

Context

LLM unbounded consumption is a resource governance problem, not a traditional application bug. The issue appears when model calls are allowed to consume unlimited tokens, memory, or downstream API cost, which makes AI services easy to abuse at scale and difficult to budget.

The primary security gap is that many teams still treat LLMs like ordinary APIs, even though inference cost and compute load are highly variable. That creates an identity and access dimension as well, because the abuse often comes through normal accounts, automated scripts, or service credentials that need stricter quota, authorization, and telemetry controls.

Key questions

Q: What breaks when LLM unbounded consumption is not controlled?

A: Without controls, attackers can turn legitimate AI usage into excessive compute spend, slow responses, and service instability. The failure is not only technical saturation. It is also economic, because token-heavy or repeated requests can produce a denial of wallet effect before teams recognise the abuse pattern.

Q: Why do LLM APIs need cost controls as well as rate limits?

A: Rate limits alone do not reflect how expensive a request is. A small number of long or complex prompts can cost far more than a large volume of lightweight calls. Effective governance therefore needs token ceilings, per-tenant budgets, and request complexity checks, not just request counts.

Q: How can security teams tell whether AI agent access is drifting out of scope?

A: Look for agents touching systems, data sets, or tools that are outside the intended task boundary, especially when those actions are not part of the approved workflow. Behavioural baselines, entitlement logs, and cross-system correlation are the key signals. If the agent can act meaningfully outside its original purpose, scope drift is already happening.

Q: Who should be accountable for controlling LLM spend risk?

A: Accountability should sit across AppSec, platform engineering, and the business owner of the AI service. Security teams define the guardrails, platform teams enforce them in the gateway and runtime, and service owners own the budget impact and abuse response thresholds.

Technical breakdown

Why unbounded consumption breaks LLM cost models

LLM applications consume resources differently from conventional web services. A single request can trigger large token counts, repeated inference passes, tool calls, and high-cost model variants, all of which scale non-linearly with prompt size and complexity. That makes the abuse pattern distinct from simple request flooding. The attacker does not need to crash the server; they only need to drive expensive compute paths repeatedly until the economics break. In practice, the same exposed endpoint can remain technically available while silently becoming financially unsustainable.

Practical implication: enforce request-size, token, and cost ceilings before inference begins.

How denial of wallet attacks exploit legitimate access

Denial of wallet attacks use normal-looking interactions to generate abnormal spend. Attackers can submit complex prompts, oversized documents, or scripted bursts that look like user activity but force the model to process far more compute than intended. Because the requests are valid at the transport layer, traditional perimeter controls often miss them. The real failure is the lack of per-tenant quotas, user-level throttling, and budget-aware authorization. Where LLMs are exposed through APIs, access control must include spend control, not just authentication.

Practical implication: bind identity, quota, and spend limits together for every AI-facing account or service token.

Why input validation is a security control for AI systems

Input validation in LLM systems is not only about syntax or injection prevention. It also means constraining size, complexity, document volume, and retry behaviour before those inputs reach the model. Without pre-inference controls, even rejected or truncated requests can still incur embedding, chunking, routing, or moderation costs. That is why resource controls belong at the gateway or orchestration layer, not just inside the model application. This is a governance issue for AI operations as much as a technical safeguard.

Practical implication: place validation, throttling, and spend enforcement at the AI gateway rather than in downstream application logic.

NHI Mgmt Group analysis

LLM cost abuse is a governance failure before it is an availability failure. Unbounded consumption is dangerous because it allows a normal user path to become a financial attack path. Once AI usage is billed per token or per compute-heavy request, access management has to include spend boundaries, not just authentication. Practitioners should treat budget enforcement as part of AI identity governance.

Identity controls matter because denial of wallet attacks often arrive through legitimate accounts. The article’s core pattern is not anonymous flooding but authorised use turned abusive at scale. That makes per-user quotas, service-token scoping, and workload attribution essential. Without those controls, teams can identify the request but still fail to contain the actor. Practitioners should connect AI access policy to cost ownership.

Unbounded consumption creates a new named concept: inference spend exposure. This is the gap between allowing model use and controlling how much compute each identity can consume. The more organisations expose models through shared APIs, the more they need policy that limits token volume, retry loops, and batch behaviour. Practitioners should measure this as a control gap, not a capacity problem.

OWASP LLM10 validates that model security and operational security are now inseparable. The attack pattern sits at the intersection of application security, cloud spend, and AI governance, which means no single team owns the full risk. NIST AI Risk Management Framework thinking helps here because the issue spans governance, measurement, and deployment controls. Practitioners should align AI security ownership across AppSec, platform, and finance.

Resource exhaustion attacks on AI are becoming an identity problem in disguise. When abuse comes from service accounts, API keys, or automated agents, the security question becomes who can consume what, how fast, and at what cost. That is a familiar IAM question in a new system class. Practitioners should extend least privilege into usage privilege.

What this signals

Inference spend exposure will become a standard control category as AI usage expands into customer-facing and internal workflows. Teams that can already attribute spend to identity and workload will be better placed to detect abuse, contain blast radius, and prove that model access is being governed rather than merely logged.

The control stack should increasingly resemble IAM plus cloud cost governance: authenticated access, scoped entitlements, quotas, and real-time anomaly detection. In practice, that means AI gateways and orchestration layers need policy enforcement, not just observability, and service owners need thresholds they can defend to finance and risk stakeholders.

For practitioners

• Implement pre-inference request caps Set maximum prompt size, token count, attachment size, and retry frequency at the AI gateway before requests reach the model. That stops oversized inputs from consuming expensive compute even when the request is syntactically valid.
• Bind quotas to identity and workload Assign separate spend, rate, and concurrency limits to end users, service accounts, and automated workloads. Shared limits hide the source of abuse and make it impossible to distinguish normal usage from scripted cost attacks.
• Add budget-aware detection and kill switches Track per-tenant tokens, latency, and cost in real time, then trigger throttling or key revocation when usage crosses defined thresholds. A budget alert is only useful if it can stop the request path quickly.
• Isolate high-cost inference paths Route expensive tasks such as large-document analysis, code generation, or multi-step reasoning into separate pools with stricter controls. Isolation limits tenant blast radius and prevents one workload from exhausting the entire service.

Key takeaways

• LLM unbounded consumption turns ordinary AI usage into a cost and availability attack path.
• The evidence shows that a small number of expensive requests can create outsized budget damage very quickly.
• Teams need quota, validation, and spend enforcement before inference, not after the bill arrives.

Key terms

• Unbounded Consumption: Unbounded consumption is the failure to cap how much compute, token volume, or downstream cost an AI request can consume. In LLM environments, it turns legitimate use into a financial and availability attack surface when input size, retries, and model complexity are left unchecked.
• Denial of Wallet: Denial of wallet is an attack that weaponises pay-per-use pricing to create unsustainable cloud or AI spend. The attacker does not need to destroy infrastructure. They only need to trigger enough expensive usage to make the service economically unsafe to operate.
• Inference: Inference is the process of using a trained model to generate outputs from new inputs. In security terms, it matters because inference cost can vary dramatically based on prompt size, tool calls, and model selection, which makes it a target for abuse and cost escalation.
• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.

What's in the full article

StackHawk's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of the three unbounded consumption attack patterns and how each one behaves in production
• Practical control guidance for input validation, rate limiting, and budget monitoring across AI endpoints
• Examples of detection and response logic for resource-heavy prompts and scripted abuse
• StackHawk's LLM security testing coverage for OWASP LLM10 and related implementation checks

👉 The full StackHawk post covers attack patterns, control placement, and testing guidance for AI applications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the identity controls that underpin safer AI and broader access governance.