🎯 What “Unbounded Consumption” means (plain English)

Unbounded Consumption happens when users (or attackers) can make your AI system do too much work—too many requests, too many tokens, too many tool calls, too many retries—without effective limits.

Think of it as “resource exhaustion,” but for modern LLM systems where the resource is:

• tokens (input + output),
• tool calls (agent steps),
• latency (slow jobs piling up),
• and money (pay-per-use cloud inference).

⚡ Why this is a 2025–2026 “real problem” (not theory)

OWASP explicitly expanded what used to be thought of as “denial of service” into a broader category: Unbounded Consumption—because the harm is not only downtime. It’s also unexpected cost and resource misuse in large-scale LLM deployments.

If you run a customer-facing chatbot, a RAG assistant, or an agent that can use tools, you should assume cost-abuse and runaway usage will happen eventually—accidentally or intentionally.

🧨 The 7 most common real-world failure patterns

Here are the patterns OWASP highlights (plus a practical “agent loop” pattern teams see constantly):

✅ The “Anti-Runaway” controls that actually work (copy/paste)

Use this as a baseline checklist. You don’t need all of it on day one—but you do need a plan.

🔐 A) Authentication and access boundaries

• Require authentication for any non-trivial usage (avoid open anonymous endpoints).
• Role-based access for advanced features (long context, file uploads, tool access).
• Separate dev/staging/prod keys and quotas.

🧱 B) Hard limits (the non-negotiables)

• Max input size (characters/tokens) and reject early.
• Max output tokens per request.
• Max context window usage per session (cap conversation history growth).
• Max concurrent requests per user/org.

🧮 C) Budgets and quotas (prevent denial-of-wallet)

• Daily/weekly token budgets per user and per org.
• Spend caps per API key/environment.
• Tiered limits: free trial / standard / elevated (with review).

⏱️ D) Timeouts, throttling, and graceful degradation

• Timeout expensive requests (don’t let them run forever).
• Throttle repeated retries and request storms.
• Graceful degradation: partial functionality under load instead of full failure.

🧰 E) Agent/tool controls (stop loops and “rogue” escalation)

• Max steps per run (hard stop).
• Max tool calls per run (hard stop).
• Queued action limits (don’t allow unlimited “pending actions”).
• Read-only by default for tools; write actions require human approval.

🔍 F) Monitoring and anomaly detection (make it observable)

• Track cost per user/org and alert on spikes.
• Track tokens per request and tokens per session.
• Track tool-call volume and step counts for agents.
• Track latency (p50/p95) and timeouts; cost incidents often show up as performance incidents first.

🧾 G) Reduce extraction risk (high-level)

• Rate limits and quotas reduce high-volume probing.
• Limit exposure of extra probability details (only provide what’s needed).
• Watermarking (where applicable) can help detect unauthorized reuse patterns.

🧯 “First 30 minutes” playbook for a cost/runaway incident

If you suddenly see a cost spike or throughput collapse, your goal is containment first—then diagnosis.

1. Throttle immediately: tighten per-user and per-org rate limits.
2. Reduce max tokens: lower input/output caps temporarily.
3. Disable high-cost features: long-context mode, file uploads, web browsing, or expensive tools.
4. Cap agent loops: reduce max steps/tool calls and force draft-only mode for actions.
5. Identify the top spenders: users/keys/IP ranges and temporarily block or require step-up verification.
6. Preserve evidence: request metadata, token counts, tool-call logs, timestamps (privacy-safe).
7. Post-incident fix: add regression tests, update quotas, and create a permanent alert rule.

Pair this with a full incident routine: AI Incident Response (Practical Playbook)

🧪 Mini-labs (quick exercises that prevent surprise bills)

Mini-lab 1: “Top 10 most expensive prompts” review

1. Export usage logs for the last 7 days (token counts + cost).
2. List the 10 most expensive sessions/prompts.
3. Decide: should these be blocked, capped, cached, or moved behind a higher tier?

Mini-lab 2: Agent loop test

1. Run your most complex agent workflow with step limits set to 10, then 20.
2. Verify the agent stops safely (clear message + next steps) when the limit is reached.
3. Add a “human approval required” step for any write action.

Mini-lab 3: Denial-of-wallet simulation (safe)

1. Create a test API key with strict quotas.
2. Simulate bursts of usage (within your test environment) and verify alerts trigger.
3. Verify the system degrades gracefully instead of failing hard.

🚩 Red flags that should slow down your rollout

• No rate limiting and no quotas (“unlimited by default”).
• No max token caps or step limits (“it will be fine”).
• Agents can call tools repeatedly with no loop controls.
• No cost monitoring per user/org/key.
• Logs exist, but you can’t tie spend to a user/key/workflow.

🔗 Keep exploring on AI Buzz

• OWASP Top 10 Risks for LLMs & GenAI Apps (2025) Explained
• OWASP Top 10 for Agentic Applications (2026) Explained
• AI Monitoring & Observability
• MCP Security for Beginners (Avoid Rogue Tool Calls)
• OWASP AI Testing Guide v1 (Test AI Like It’s Production)
• OWASP AIVSS (Score Agent Risks Fast)

📚 Further reading (official references)

• OWASP GenAI Security Project: LLM10 Unbounded Consumption
• OWASP GenAI: 2025 Top 10 Risks & Mitigations
• MITRE CWE-400: Uncontrolled Resource Consumption
• OWASP BLA10: Resource Quota Violations

🏁 Conclusion

Unbounded Consumption is the “LLM billing incident” risk category: too much inference, too many tokens, too many steps, and too little control.

If you want a safe baseline: set hard limits, add quotas, cap agent loops, monitor cost per user/org, and keep an incident playbook ready. That’s how you ship LLM apps without surprise outages—or surprise bills.