LLM unbounded consumption exposes a new cost-control attack surface

At a glance

What this is: This is StackHawk's analysis of OWASP LLM10, showing how unbounded consumption in LLM apps can create denial-of-wallet attacks, service disruption, and costly overuse.

Why it matters: It matters because IAM, AI security, and platform teams need to govern who can spend compute, how much they can consume, and when usage must be throttled before costs escalate.

By the numbers:

• A single 200k-token request can cost $4 to $20 USD depending on the model, according to StackHawk.
• 500 such requests from automated scripts could drain tens of thousands of dollars in under an hour, according to StackHawk.
• StackHawk says a $2,000 monthly budget can become a $47,000 bill when unbounded consumption is left unchecked.

Context

LLM unbounded consumption is a governance problem as much as a technical one. The failure begins when teams treat inference like a normal API call, even though each request can drive heavy compute, token use, and variable cost. In practice, this creates a security boundary around spend, not just availability, and that boundary is often missing.

The identity angle is real because the risk is not only excessive traffic, but uncontrolled use by authenticated users, shared service accounts, bot traffic, or automation that can keep calling the model until budgets are exhausted. Once consumption is tied to cloud billing and shared tenancy, access control, quota management, and cost monitoring become part of the security model, not just finance operations.

Key questions

Q: What breaks when LLM applications do not enforce request limits before inference?

A: Without pre-inference limits, attackers can push large prompts, long contexts, or repeated calls into the model and force the organisation to pay for the abuse. The failure is not just performance loss. It is spend amplification, tenant starvation, and delayed detection because the expensive work already happened before any post-request control could act.

Q: Why do oversized LLM requests create both security and financial risk?

A: An oversized request consumes more tokens, memory, and compute than a normal API call, so the same access path can be used to degrade service and inflate cloud bills. The risk becomes security-relevant because the attacker is exploiting a control gap in how the system authorises and bounds consumption, not merely using the product heavily.

Q: How do teams know if LLM cost controls are actually working?

A: Look for stable cost per feature request, bounded cost per agent run, and no widening gap between median and p99 spend. If alerts, caps, and kill switches are working, unusually expensive runs should be visible early and contained before they distort invoices or customer margins.

Q: Should organisations treat LLM quota management as part of IAM?

A: Yes. If a user, service account, or agent can trigger expensive inference, then identity determines financial impact as well as access. Quotas, budgets, and throttles should be bound to identities and tenants, because the control question is not only who can call the model, but how much damage that caller can do.

Technical breakdown

Why unbounded LLM consumption is different from ordinary API abuse

Unbounded consumption happens when an application allows requests whose size, frequency, or computational complexity is not bounded before inference. Unlike conventional APIs, LLM calls can scale cost with token count, context length, and output generation, so one request can be far more expensive than many standard web calls. Attackers exploit that asymmetry with oversized prompts, long documents, and automated request floods. The result is not only service degradation, but spend amplification that turns usage into a financial attack surface.

Practical implication: enforce limits on request size, token count, and per-principal spend before the model is invoked.

How denial-of-wallet attacks work in LLM systems

Denial of wallet is the cost-driven cousin of denial of service. The attacker is not trying to crash the server through network volume alone, but to force the model to burn expensive inference cycles until cloud bills become unsustainable. Because many LLM deployments rely on pay-per-use infrastructure, the abuse can happen quickly and quietly if monitoring is weak. Shared pools make this worse because one account or tenant can create resource starvation for others, especially when quota boundaries are absent or soft.

Practical implication: isolate tenants and hard-cap budgets so one user cannot drain shared inference capacity.

Why resource controls must sit ahead of inference, not after it

The article's key control point is pre-inference enforcement. If input validation, rate limiting, and quota checks happen only after the request reaches the model, the expensive work may already be underway. That is why cost control in LLM environments belongs at the gateway or policy layer, where the system can reject oversized inputs, throttle bursts, and apply tenant-specific budgets before compute is consumed. This is especially important where automation or agents can issue repeated calls without human review.

Practical implication: place policy enforcement at the request boundary so abusive prompts never reach the model runtime.

Threat narrative

Attacker objective: The attacker wants to turn model usage into an economic and operational failure by draining budget, starving capacity, or harvesting model behaviour.

1. Entry occurs through free trials, public interfaces, or authenticated automation that can submit large or repeated prompts.
2. Credentialed or scripted access then drives oversized inputs, long context windows, and expensive inference paths that amplify compute consumption.
3. The attacker objective is to exhaust cloud budget, degrade service, or use systematic querying to support model extraction and functional replication.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unbounded consumption is a governance failure, not just an abuse pattern. The article shows that the control gap is not whether the model can answer a request, but whether the organisation can bound the cost of answering it. That makes consumption policy part of AI governance, spend management, and access control in the same control plane. Practitioners should treat budget exhaustion as a security outcome, not an accounting surprise.

Cost controls belong at the request boundary because inference itself is the expensive act. Once the model starts processing a massive prompt, truncation and logging do not undo the spend already incurred. That is why the meaningful control is pre-inference enforcement, especially for authenticated users, bots, and automated agents that can loop at machine speed. Practitioners should move policy checks closer to gateway admission than to post-hoc monitoring.

LLM spend is becoming a new form of blast-radius control. In traditional security, teams limit the damage a compromised identity can do by reducing privilege scope. In LLM systems, the same logic applies to token budgets, context windows, tenant pools, and request frequency. That makes spend ceilings and quota isolation a first-class part of identity and platform governance. Practitioners should design for bounded trust, not open-ended model access.

OWASP LLM10 exposes a cost-control attack surface that existing web controls do not fully cover. Rate limiting, authentication, and logging matter, but they are insufficient if they do not account for token economics and model-level compute intensity. The security model has to reflect the fact that one expensive request can matter more than hundreds of cheap ones. Practitioners should align AI security controls with workload cost behaviour, not just traffic volume.

Shared LLM environments need tenant-aware governance because abuse crosses financial and operational boundaries. When one tenant can consume disproportionate inference resources, the issue becomes both fairness and resilience. That is especially important in platforms that mix human users, service accounts, and autonomous automation. Practitioners should segment spend, isolate tenants, and treat anomalous consumption as a security signal.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• Read next: AI Security Platform Buyer's Guide

What this signals

LLM spend limits are becoming a governance control, not a procurement afterthought. Teams that only watch model accuracy will miss the more immediate failure mode: authenticated abuse that converts usage into uncontrolled cloud spend. The operational signal is simple. If cost can rise faster than the security team can see it, the boundary is not governed.

Token economics now shape blast radius. A single principal that can issue expensive prompts can create the same kind of concentration risk that overprivileged service accounts create in classic infrastructure. That is why quota design, tenant isolation, and identity-linked cost attribution need to sit inside AI control design, not around it.

Unbounded consumption is the sort of risk that exposes weak links between IAM and AI governance. If the organisation cannot say which identity spent what, on which workload, and under what budget, then the control model is incomplete. Practitioners should align AI gateways, IAM records, and spend monitoring so abuse is visible at the identity level.

For practitioners

• Implement pre-inference request gating Reject oversized prompts, excessive context windows, and expensive request patterns before they reach the model runtime.
• Set hard tenant and principal quotas Assign per-user, per-service-account, and per-tenant spend ceilings so no single identity can drain shared inference capacity.
• Add cost-aware anomaly detection Monitor token volume, latency spikes, burst rate, and unusual query shapes to detect denial-of-wallet behaviour early.
• Isolate high-risk workloads Separate free trials, public demos, and automated integrations into distinct pools so abuse does not starve production traffic.
• Log consumption by identity Tie every request to a user, service account, or automation source so abuse can be attributed, throttled, and investigated quickly.

Key takeaways

• LLM unbounded consumption turns model access into a budget-exhaustion attack surface when request size and frequency are not bounded.
• The core failure is allowing expensive inference to begin before policy checks, quotas, and tenant controls have a chance to act.
• Treat request limits, spend ceilings, and identity-linked attribution as security controls for AI workloads, not just cost management features.

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.
• Pre-Inference Enforcement: Pre-inference enforcement is the practice of applying policy, quota, and validation controls before a request reaches the model runtime. It is critical for AI security because once inference starts, the expensive work and most of the cost have already been incurred.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and the access control patterns that matter when automation can spend at machine speed. It is designed for practitioners who need to connect identity governance to real operational risk across modern security programmes.