Notifications
Clear all
Topic starter
02/08/2026 9:41 am
TL;DR: OWASP’s LLM10: Unbounded Consumption describes how oversized prompts, expensive inference paths, and automated request floods can turn AI usage into a denial of wallet, with one 200k-token request costing $4 to $20 and 500 scripted requests draining tens of thousands of dollars in under an hour, according to StackHawk. The real control problem is not just abuse detection but enforcing resource limits before the model is asked to spend compute.
NHIMG editorial — based on content published by StackHawk: Understanding and Protecting Against LLM10: Unbounded Consumption
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Bind quotas to identity and workload Assign separate spend, rate, and concurrency limits to end users, service accounts, and automated workloads.
- 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.
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
👉 Read StackHawk's guide to OWASP LLM10: Unbounded Consumption →
LLM unbounded consumption: are your controls keeping up?
Explore further
02/08/2026 12:35 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: LLM unbounded consumption exposes a new cost-control attack surface
