All research

Preventing Unbounded LLM Consumption

Mitigate OWASP LLM10 Unbounded Consumption risks with layered controls across edge, orchestration, quotas, and real-time proxy budgets.

9 min read

Preventing Unbounded LLM Consumption

LLM features can expose variable-cost operations through a public or semi-public interface. Excessive requests, oversized inputs, long outputs, repeated retries, tool loops, or costly multimodal and external-tool calls can raise costs or reduce service availability. The impact depends on access controls, provider pricing, quotas, and the attacker's ability to create requests.

OWASP's 2025 LLM Top 10 names this risk LLM10: Unbounded Consumption. See the OWASP description and mitigations. Avoid a single attacker-to-victim “amplification factor”: it depends on assumptions about attacker cost, model rates, request volume, and infrastructure.

1. Cost and exposure model

For each request, estimate the maximum exposure from all billable components:

C_{request} = I_u r_{input} + I_c r_{cached} + O r_{output} + C_{tools} + C_{media} + C_{other}

Model the worst-case concurrent and sustained request volume as well as average usage. Apply current provider rates and account for cache-write, search, image, audio, storage, and other charges where applicable. Usage caps should be enforced before or during work, not only through end-of-month billing alerts.

2. Threat cases

  • A user submits unusually large or repeated requests.
  • Automated accounts or bots consume free trials or shared quotas.
  • A prompt or tool workflow causes repeated steps, expensive retrieval, or long output.
  • A background job retries a failing request without a limit.
  • An exposed API key or misconfigured service permits unintended traffic.
  • Indirect prompt injection persuades an agent to invoke tools or retrieve data outside the intended task.

Prompt injection and resource exhaustion overlap in some systems, but they are different problems. A prompt classifier cannot replace authorization, resource limits, or scoped tools.

3. Layered controls

At the edge

  • Authenticate callers and apply quotas by account, tenant, and endpoint. IP limits are useful for anonymous traffic but insufficient by themselves.
  • Cap request bytes and validate file type, page count, image dimensions, and other modality-specific properties before expensive parsing.
  • Apply per-request and rolling token budgets. Estimate input tokens before dispatch when feasible, then reconcile with provider usage afterward.
  • Use abuse detection and bot controls appropriate to the product, while avoiding reliance on a single signal.

In orchestration

  • Set model-specific output limits, deadlines, maximum tool calls, maximum agent steps, and a total task budget.
  • Bound retries, use backoff for transient errors, and avoid retrying permanent validation or authorization failures.
  • Require explicit authorization for side-effecting tools; scope credentials and validate tool arguments independently.
  • Detect repeated actions or identical errors and terminate with a safe, observable result.
  • Limit concurrency and queue expensive jobs with cancellation and tenant fairness.

In operations

  • Track token and tool usage by request, tenant, feature, model, and outcome.
  • Alert on unexpected rates and spend; test that limits still work during provider errors and partial outages.
  • Keep provider keys server-side, rotate them, separate environments, and restrict their permissions.
  • Define graceful degradation, such as refusing oversized work, switching to a safe lower-cost workflow, or asking the user to narrow the request.

4. Policy examples need workload tuning

Fixed thresholds such as “60 requests per minute” or a “50 KB payload cap” are not universal recommendations. Derive limits from expected product use, model tokenization, endpoint constraints, latency targets, abuse analysis, and provider quotas. Apply distinct policies for synchronous chat, batch processing, uploads, and agent workflows.

Do not expose a streaming response as if it were free to abort: generated tokens may already be billable. Early termination can limit further generation, but streaming filters must also handle partial output and user-visible truncation safely.

References

Cite this research note

BibTeX entry for academic citations, literature trackers, and generative research synthesizers:

@article{glyiq2026_preventing_unbounded_consumption,
  title = {Preventing Unbounded LLM Consumption},
  author = {Irfan, GlyIQ Infrastructure},
  journal = {GlyIQ Infrastructure Research Notes},
  year = {2026},
  url = {https://glyiq.com/research/preventing-unbounded-consumption}
}

Continue reading

cost optimization

Controlling LLM API Cost: A Practical FinOps Guide

A practical engineering guide for LLM API cost control, token accounting, model selection, prompt size, retries, caching, and bounded agent limits.

architecture

Caching for LLM Applications: Response Reuse and Prompt Prefixes

Three distinct caching mechanisms for LLMs: exact-response caches, semantic cache risks, provider prompt prefix reuse, and cost models.

evaluation

Retrieval-Augmented Generation and Long-Context Input

A decision guide for choosing what evidence to send to a model: retrieval pipelines, context budgets, latency, and cost modeling.