Your public LLM chatbot's cloud bill tripled overnight after a burst of automated requests. What is this and how do you contain it?
Short answer
It is the OWASP LLM10:2025 risk 'Unbounded Consumption', here as denial of wallet: uncontrolled inference on a pay-per-use model drains money and capacity. Contain it with per-user rate limits and quotas, strict input validation, timeouts and throttling, plus logging and anomaly detection. Simply buying more capacity or trusting users leaves the exposure open.
A cost spike from automated traffic is an availability and financial security problem, not just an ops issue. The interviewer wants the right name and layered controls.
What it is
OWASP's LLM10:2025 "Unbounded Consumption" describes applications that allow excessive, uncontrolled inferences, leading to denial of service, financial loss, model theft, and service degradation. Because LLM inference is computationally heavy, especially in the cloud, it is easy to exploit. Denial of Wallet is the variant where attackers run high-volume operations against pay-per-use pricing to inflict unsustainable costs. OWASP also lists model extraction, where crafted inputs collect outputs that let an adversary replicate part of the model.
Containment and prevention
- Rate limiting and user quotas so no single client can consume unbounded inference.
- Strict input validation on size and shape of requests.
- Timeouts and throttling, with dynamic resource allocation.
- Logging and anomaly detection to catch abnormal usage early.
- Graceful degradation to keep partial functionality under load.
- Access controls that limit who can reach the model.
Why the alternatives fail
Scaling up only makes the bill larger. Poisoning and jailbreaks are different risks; a prompt asking the model to refuse does not stop requests from reaching billed inference.
What interviewers want
The name (LLM10, denial of wallet) plus enforcement outside the model.
Likely follow-ups
- How does model extraction relate to unbounded consumption, and how would you spot it in logs?
- Which quotas would you set per user, per API key, and per organization?
- How can graceful degradation keep the service partly available under abusive load?