Walk through three distinct ways LLM04 (model DoS) shows up in production

OWASP LLM04 is denial of service against an LLM application. The classical DoS attack ties up CPU or bandwidth; the LLM version ties up the resources specific to LLM apps. Three manifestations matter in production. **Token-flood.** An attacker sends a prompt that causes the model to generate its maximum output every time. Each request occupies a concurrency slot for the full duration. A handful of attackers can saturate your provider concurrency limit and lock real users out. **Recursive loop.** Against agentic systems, the attacker triggers a prompt that pushes the agent into a long tool-call loop. Each step costs tokens and often costs downstream API calls. A single request can issue thousands of tool calls before any timeout kicks in. **Expensive-tool spam.** The agent has access to tools that cost real money per call, vector search, code execution sandboxes, database queries. The attacker induces calls to the most expensive tools, burning the team's budget without needing high request volume. The shared defence is per-dimension ceilings. Every request must have a maximum token budget, a maximum step budget, a maximum dollar budget, and a maximum wall-clock budget. Rate limits per user and per tenant sit on top. The combination ensures that no single request and no single attacker can spend more than a bounded amount of your resources.

OWASP LLM04 (model denial of service) is the family of attacks where an adversary causes disproportionate resource consumption per request. Three production manifestations cover most incidents: - **Token-flood.** Adversarial prompt induces maximum-length output every request. The cost is concurrency slots held for the full generation time. A small number of attackers can saturate your provider's concurrency cap and lock real users out. - **Recursive agent loop.** Against tool-using agents, the prompt forces the agent into an extended tool-call loop. Each iteration costs model tokens, downstream API quota, and time. The attack scales sub-linearly in adversary effort but linearly in defender cost. - **Expensive-tool spam.** Where the agent has access to high-cost tools (vector search, code sandboxes, embeddings on large texts, paid third-party APIs), the attacker steers calls toward the most expensive tools to burn budget faster than per-request quotas would catch. The **shared mitigation** is a per-dimension ceiling stack: - **Token ceiling** per request (max_tokens, max_output_tokens) prevents token-flood. - **Step ceiling** per request prevents recursive loops. - **Cost ceiling** per request in dollars terminates on whichever resource dominates. - **Wall-clock ceiling** per request prevents any of the above from blocking concurrency indefinitely. - **Rate limiting** per user and per tenant prevents a single actor from monopolising the bounded pool. Each ceiling closes a different escape hatch. None of them substitutes for the others; rate limiting alone allows expensive single requests, cost ceilings alone allow concurrent low-cost flood, step ceilings alone do not bound expensive single steps. The production answer is the stack, not any one component.