1. What LLM04 Actually Is
Model DoS is the availability and cost-abuse risk unique to probabilistic, token-metered systems. A conventional API request might be expensive because of database work. An LLM request can be expensive because the attacker controls prompt length, retrieved context volume, output length, sampling behavior, tool iterations, and sometimes model tier. The unit of exhaustion is not only requests per second; it is tokens, seconds of GPU occupancy, KV-cache pages, queue slots, and downstream tool work.
For self-hosted inference, the important detail is that GPU capacity is shared through schedulers and batching engines. A small number of pathological requests can degrade everyone else by occupying the context window, causing long decode phases, reducing batch efficiency, or forcing cache eviction. A cloud API hides those details behind a bill. On-prem, they become your SLO.
Availability is a security boundary
When the model backs a support desk, SOC assistant, trading workflow, or operational runbook, inference starvation is not a nuisance. It can block decision-making and force staff onto unsafe manual fallbacks.
2. Attack Shapes (Defanged)
Defanged examples only
The shapes below are written so defenders can recognize pressure patterns in telemetry. They deliberately avoid copy-paste prompts.
2.1 Context flooding
The attacker submits maximum-length inputs, uploads very large documents, or triggers retrieval over broad corpora so the assembled prompt approaches the context limit. The model spends capacity pre-filling tokens that add little useful information, and legitimate requests wait.
2.2 Output-stretching
The request is framed to make the model produce extremely long answers or repeated structured output. Decode time dominates, streaming connections stay open, and the queue backs up even if request count looks normal.
2.3 Retrieval and tool amplification
The model or orchestration layer is nudged into repeated search, broad top-k retrieval, or multi-tool fan-out. The LLM call is only the visible part; the real exhaustion happens in vector search, reranking, document fetching, or a chain of tool invocations.
2.4 KV-cache starvation
On engines such as vLLM or TensorRT-LLM, long contexts and long generations pressure the KV cache. When cache space is scarce, the scheduler admits fewer useful requests, evicts work, or suffers latency spikes. This can happen without classic network volumetric traffic.
3. Blue-Team Detection
Model DoS detection must combine application telemetry with inference-server metrics. A WAF request counter alone will miss token-level abuse. The SOC needs to see prompt tokens, completion tokens, context-window usage, queue delay, time-to-first-token, tokens per second, active sequences, cache pressure, tool count, and tenant identity.
| Metric or event | Suspicious pattern | Action |
|---|---|---|
| Prompt tokens per principal | High percentile jumps or repeated near-limit requests | Throttle, require smaller context, or route to review |
| Completion tokens | Long generations with low user value or repeated formats | Enforce output caps and stop conditions |
| TTFT / queue delay | Latency grows while request count stays flat | Investigate context flooding or KV-cache pressure |
| Tool calls per turn | Fan-out above policy or repeated retries | Trip circuit breaker and log as security event |
| GPU cache / active sequence pressure | Cache saturation correlated to one tenant or route | Isolate queue and apply tenant quotas |
Map these events to MITRE ATLAS as availability impact against an ML system, and to MITRE ATT&CK at the infrastructure layer where the activity resembles resource hijacking, endpoint DoS, or application-layer exhaustion.
4. Mitigation and Build Controls
- Token budgets by principal. Apply quotas to prompt tokens, completion tokens, retrieved context tokens, and tool calls. Request-per-minute limits are necessary but not sufficient.
- Admission control. Reject or down-tier requests before they enter the GPU queue when they exceed policy. Do not let the most expensive requests compete equally with normal traffic.
- Context shaping. Cap top-k retrieval, deduplicate chunks, summarize long documents offline, and enforce per-source context budgets.
- Output controls. Set maximum completion tokens, stop sequences, streaming timeouts, and task-specific schemas for structured jobs.
- Queue isolation. Separate tenants, unauthenticated traffic, batch jobs, and administrative workflows. A noisy tenant should not starve a privileged incident-response assistant.
- Tool circuit breakers. Limit tool recursion, fan-out, retries, and external calls per turn. When a breaker trips, return a safe error and alert.
- Graceful degradation. Fall back to smaller models, retrieval-only answers, cached responses, or human triage queues instead of failing open.
# ILLUSTRATIVE - per-turn budget envelope
budget:
prompt_tokens: 12000
completion_tokens: 1200
retrieved_chunks: 8
retrieved_tokens: 6000
tool_calls: 3
wall_clock_seconds: 45
egress_hosts: allow_list_only
on_budget_exceeded:
action: stop_and_log
user_message: request_too_large_for_policy5. Mapping to WSTG, ATLAS, and Related LLM Risks
| Failure mode | OWASP WSTG / ASVS lens | MITRE view | Related LLM risks |
|---|---|---|---|
| Large input and file abuse | Input validation, upload limits, and resource management | Application-layer resource exhaustion; ATLAS availability impact | LLM01, LLM03 |
| Tool fan-out | Business-logic abuse and authorization around sensitive functions | Abuse of execution through orchestration layer | LLM07, LLM08 |
| Tenant starvation | Access control and multi-tenant isolation testing | Impact through service degradation | LLM10 |
| Cost exhaustion | Rate limiting and abuse-case testing | Resource hijacking and availability impact | LLM09 |
The related-risk overlap matters. A prompt injection that forces tool loops is LLM01 plus LLM04. An over-permissioned agent that can retry expensive operations is LLM08 plus LLM04. Availability controls should therefore live in the same policy layer as tool permissions and prompt safety, not in a separate billing dashboard.
Pressure-Test Availability Before Launch
The practical test is whether these controls survive contact with a realistic attacker and a realistic SOC. Use the AI red-teaming methodology to pressure-test the failure modes, the blue-team service to turn the telemetry into detections, and the contact form to request a focused review of your own on-prem LLM stack.