What are the signs that an LLM service is being targeted for unbounded consumption?

Why This Matters for Security Teams

Unbounded consumption is not just a cost issue. For LLM services, it can become a reliability, availability, and governance problem when prompts, tool calls, retrieval queries, or repeated retries consume far more compute than intended. Security teams should treat it as an abuse pattern that can blur into denial of service, quota exhaustion, and resource theft, especially where the service sits behind shared infrastructure or customer-facing APIs.

Current guidance in the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward managing misuse, resilience, and output validation together rather than treating model traffic as ordinary web traffic. For LLM services, that means watching for abuse of context windows, excessive chaining of agent actions, and traffic that stays syntactically valid while still forcing expensive inference paths. The identity angle matters too: when API keys, service account, or agent identities are weakly governed, attackers can generate high-cost workload using legitimate credentials.

In practice, many security teams encounter unbounded consumption only after latency and cloud spend have already risen, rather than through intentional capacity testing.

How It Works in Practice

In operational terms, unbounded consumption shows up when requests are individually permissible but collectively expensive. That can happen through very large prompts, repeated regeneration loops, retrieval-heavy workflows, recursive agent behavior, or poorly constrained tool use. The service may still authenticate requests correctly, yet every call drains more CPU, GPU, memory, tokens, or downstream API budget than the system was designed to tolerate.

Security and platform teams should monitor both user-visible symptoms and infrastructure signals. Useful indicators include rising p95 or p99 latency, queue growth, increased token counts per request, elevated cache misses, growing error rates after retries, and sudden changes in prompt composition. These signals matter most when they occur without a matching rise in legitimate business activity. They also map well to AI governance practices described in the NIST AI 600-1 Generative AI Profile, which emphasises operational controls for generative AI systems rather than relying on after-the-fact incident review.

• Track tokens, tool invocations, and retrieval calls per session, not just request counts.
• Set per-tenant and per-identity quotas for context length, retries, and downstream calls.
• Correlate model telemetry with IAM logs to spot abused service accounts or agent identities.
• Flag repeated prompt rewrites, looping chains, and abnormal fallback behaviour as abuse indicators.
• Use circuit breakers so one expensive session cannot consume shared capacity indefinitely.

For teams building agentic workflows, the CSA MAESTRO agentic AI threat modeling framework is a useful lens for separating model risk from orchestration risk, because the cost blowout may originate in the agent loop rather than the model itself. These controls tend to break down in loosely governed multi-tenant environments where prompts, tools, and quotas are shared across customers or internal teams because attribution becomes too weak to distinguish normal spikes from abuse.

Common Variations and Edge Cases

Tighter rate limits often improve resilience but can also increase false positives, requiring organisations to balance abuse prevention against developer friction and legitimate burst traffic. That tradeoff is especially visible in support bots, coding assistants, and autonomous workflows where a single business action may trigger multiple model calls.

Some cases are not classic attack traffic. A badly designed integration can create self-inflicted unbounded consumption through retry storms, runaway agent loops, oversized retrieval contexts, or malformed inputs that force the model to keep reprocessing the same state. In those environments, the question is not only whether the service is under attack, but whether the application design makes expensive behaviour possible in the first place. The MITRE ATLAS adversarial AI threat matrix is useful here because it helps distinguish adversarial prompting and resource exhaustion patterns from ordinary reliability defects.

There is no universal standard yet for what exact token thresholds or retry counts should trigger incident response. Best practice is evolving toward baselining by workload, then alerting on deviations that combine cost growth, repeated errors, and abnormal identity usage. That distinction is important in production systems with batch jobs, seasonal peaks, or retrieval-heavy workloads, where a spike may be legitimate but still requires stricter throttling until the cause is understood.

Related resources from NHI Mgmt Group

• What breaks when LLM unbounded consumption is not controlled?
• Who is accountable when an LLM denial-of-service event is triggered by a legitimate user or service account?
• What breaks when organisations do not govern LLM inference access like a credentialed service?
• What should teams do first when a peer-facing service can write unbounded data?