[Track B] Feedback: LLM10 — Unbounded Consumption

[rocklambros]

Sprint 2 Feedback — LLM10 Unbounded Consumption

This issue collects qualitative feedback on the refreshed LLM10 Unbounded Consumption entry. Submit your Importance and Clarity scores via the Sprint 2 Google Form (single ballot covering both tracks).

• Vote: https://docs.google.com/forms/d/e/1FAIpQLSebmFQyJPOMuw1IorHCJ2FdW98ZT2oLNBuVgYqpPoayW9v6ww/viewform — page through to the LLM10 section
• Read the draft: https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/LLM10_UnboundedConsumption.md
• Voting closes: May 18, 2026 at 23:59 UTC
• Code of Conduct: https://owasp.org/www-policy/operational/code-of-conduct

Scoring rubric

• Importance (1–5): How critical is this risk to LLM application security in 2026?
• Clarity (1–5): How clearly does the entry describe the risk and its mitigations?

How to comment

Reply to this issue with feedback specific to LLM10. Use one comment per topic so the working group can triage cleanly. Format we like:

Section: <which section of the entry>
Issue: <what is wrong, missing, or unclear>
Proposed change: <your suggested fix or addition>
Evidence: <CVE, paper, incident, or research note ID if applicable>

Out of scope here

• Cross-cutting comments → use Discussions
• Questions about Track A candidates → comment on the relevant Track A issue
• Process or governance questions → comment in Discussions

Triage

Working group entry leads classify each comment within 48 hours as:

• actionable — feeds Sprint 3 revision
• clarification — requires reply, not action
• out-of-scope — closed with redirect

Sprint 3 begins May 18 with this issue's triage as input.

[baddilasowmya]

Importance: 4/5 — Confirmed by real-world incidents this year (e.g., CVE-2026-55446 in Langflow), and OWASP's own Q1 2026 exploit round-up cites this category in active attacker activity, so it's clearly not theoretical.
Clarity: 4/5 — The three attack patterns (context window saturation, reasoning loop exploitation, side-channel abuse) are well explained. One suggestion: the mitigation section is strong on prevention (rate limiting, input validation, timeouts) but light on detection. From a SOC perspective, teams need guidance on what unbounded consumption actually looks like in monitoring — e.g., anomalous token-count spikes per session, sustained high-frequency queries from a single source, or cloud billing anomaly alerts as an early warning before performance even degrades. Adding a short "detection signals" subsection alongside the existing mitigations would make this more actionable for blue teams, not just app developers.