What is LLM Denial of Service (DoS)? Types and Defenses

LLM DoS is a runtime availability problem

LLM DoS risk appears during execution, where user prompts, retrieved context, model responses, agent actions, and tool calls all compete for capacity. The impact can include excessive token usage, higher latency, exhausted quota, unexpected cost, overloaded downstream systems, or unavailable AI workflows.

Because these attacks can be semantically expensive rather than simply high volume, defenses need to evaluate more than request count. Runtime controls should consider prompt size, output length, context growth, agent iteration behavior, tool use, identity, and budget before expensive execution continues.

Common types of LLM DoS attacks

LLM DoS pressure points

Availability risk can emerge at multiple points in an AI workflow, not only at the model API boundary. The most important pressure points are the places where cost, latency, context size, agent execution, or downstream systems can grow unexpectedly.

Architecture patterns that reduce exposure

The strongest LLM DoS defenses are enforced before expensive execution occurs. Enterprises should place a runtime control layer between users, applications, models, agents, tools, and downstream systems. This layer should evaluate identity, policy, prompt size, context size, model selection, tool permissions, and budget before the request is allowed to proceed.

Isolation is equally important. Shared quotas can turn one abusive user, tenant, API key, agent, or workflow into a broader outage. Quotas should be separated by tenant, user, application, model, agent, and workflow where operationally feasible. This prevents one high-cost interaction pattern from exhausting capacity needed by other business processes.

Agentic systems need additional boundaries. A bounded agent design sets maximum iterations, maximum tool calls, maximum elapsed time, maximum context size, and explicit stop conditions. Tool access should follow least privilege. Agents should not receive broad access to write operations, financial actions, production systems, or high-cost APIs unless there is a clear need and a control path. For high-impact actions, human authorization can reduce both DoS and excessive-agency risk.

Practical runtime controls for LLM DoS defense

Effective controls combine rate, token, context, output, concurrency, and tool policies. Request-per-minute limits alone are not enough because two requests can have very different cost profiles. A short prompt with a short answer may be low risk, while a single large prompt that requests a long structured response and triggers multiple tools can consume materially more resources.

Start with hard limits at the AI gateway or runtime layer. Enforce request-per-minute, token-per-minute, concurrent-session, context-size, and output-token limits. Output caps are especially important for expensive-output attacks because they limit how long the model can continue generating. Timeouts and circuit breakers should apply to model calls, retrieval calls, tool invocations, and agent loops. If a downstream system begins failing or slowing, the AI application should degrade gracefully rather than retry indefinitely.

Prompt and query validation can help identify unusually large inputs, repeated patterns, recursive instructions, or requests likely to trigger high-cost output. These checks do not need to determine user intent perfectly to be useful. They can classify risk, route suspicious requests to stricter limits, require approval, or reject clearly abusive input. For asynchronous or long-running work, queueing and resource allocation limits can protect interactive workflows from being starved.

Detection, evidence, and incident response

Detection should focus on AI-specific usage patterns and execution behavior. Useful evidence includes prompt and response size, token consumption, context growth, model selection, tool invocations, agent iterations, policy outcomes, latency, retries, and downstream errors.

When an incident occurs, response teams need enough runtime evidence to understand whether the issue came from abusive prompts, faulty workflows, recursive agent behavior, excessive retrieval, long output generation, or overloaded tools and APIs. That evidence can also support later governance review and policy tuning.

How Trussed AI fits into an enterprise control model

Trussed AI supports an enterprise control model by helping teams apply governance and runtime controls where AI activity is executed, observed, and audited.

• Runtime policy enforcement: Apply controls at the point where prompts, agents, tools, and downstream actions are executed.
• Agent permissions: Reduce excessive agency by limiting what agents can do and which tools they can access.
• Tool approval workflows: Introduce review for sensitive or high-impact tool actions rather than allowing unrestricted autonomy.
• Runtime monitoring: Observe AI-specific usage patterns, policy outcomes, and execution behavior for investigation and response.
• Audit logging: Maintain governance evidence for AI activity, decisions, permissions, and runtime events.