AI inference runs on scarce, expensive accelerators, so an AI service can be knocked over by far fewer requests than a web server, and sometimes by a single request that asks for a great deal of useless work. MITRE ATLAS tracks this as AML.T0029 Denial of AI Service, in the Impact tactic (AML.TA0011). ATLAS describes adversaries flooding AI-enabled systems with requests to degrade or shut them down, and crafting inputs that consume heavy amounts of useless compute. This guide covers what makes AI services different from ordinary denial of service targets, the request patterns and resource signals to watch, the five ATLAS mitigations linked to the technique and how to set them, and how to respond. It is written for platform engineers running inference, owners of LLM applications and agents, and SOC teams. The OWASP view of the same risk is in the OWASP LLM Top 10 LLM10 Unbounded Consumption Guide, which this page links rather than repeats.
Key takeaways
- Cost per request is the weak point. One long-context, long-output or tool-heavy request can tie up an accelerator for seconds or minutes, so request counts alone understate load. Limit tokens, time and steps per request, not only requests per minute.
- Two attack shapes. ATLAS covers floods of requests and inputs crafted to need heavy useless compute. Research on sponge examples reported energy increases by a factor of 10 to 200 on vision and language models.
- Agents multiply the blast radius. A single agent task may trigger many model calls, retries and tool actions. ATLAS mitigation AML.M0036 says to limit iterations, retries, tool calls, parallel tasks, delegation depth and downstream spending.
- Identity is part of availability. ATLAS ties access control (AML.M0019) to this technique, and the AIKatz case shows that a stolen user token can be used to trip a provider's bot limits and get the real user banned.
- Know the neighbours. Spending the victim's money is AML.T0034 Cost Harvesting, and degrading a model with junk inputs is AML.T0046 Spamming AI System with Chaff Data. Denial of AI Service is about availability, though one attack often causes all three.
How the technique works
ATLAS gives three points in its description: adversaries may flood AI-enabled systems with requests to degrade or shut down the service; many AI systems need significant specialised compute and are often expensive bottlenecks that can be overloaded; and adversaries can craft inputs that need heavy amounts of useless compute. The technique applies to predictive, generative and agentic AI, and ATLAS rates its maturity as demonstrated. It has no sub-techniques. The enterprise ATT&CK equivalents are T1499 Endpoint Denial of Service, in particular T1499.003 Application Exhaustion Flood, and T1498 Network Denial of Service; this page covers only what is specific to AI.
| Attack shape | What drives the load | Why AI makes it worse |
|---|---|---|
| Request flood | High request volume or concurrency from one or many sources | Inference capacity is bounded by accelerator count and memory; autoscaling GPUs is slow and expensive compared with web tiers |
| Expensive input (sponge) | Inputs crafted to maximise latency or energy per inference | Cost varies widely by input; Shumailov and colleagues reported energy increases of 10 to 200 times on established models, transferable across CPUs, GPUs and an ASIC simulator |
| Context and output exhaustion | Inputs at or beyond the context window, or prompts that drive maximum output length | Memory and time scale with tokens; OWASP LLM10 lists variable-length input floods and continuous input overflow |
| Non-terminating generated work | Prompts that lead an application to run generated code or loops that never end | LLM apps that execute model output inherit its runtime; see AML.CS0016 below |
| Agent loop amplification | Tasks that cause repeated planning, retries, tool calls or delegation | One user request fans out into many model calls and external actions |
| Account-level denial | Abuse of a victim's own session to trigger provider limits or delete their data | The user is locked out even though the service stays up for everyone else |
Real cases
| Case | What happened | Lesson for defenders |
|---|---|---|
| ATLAS AML.CS0016 MathGPT | A public app turned user questions into Python code generated by an LLM and executed it. A prompt injection made the model produce code that never terminated; the app became unresponsive until the host restarted. The same actor reached environment variables and the app's API key | Never execute model output without a sandbox, a time limit and memory limits |
| ATLAS AML.CS0036 AIKatz | Researchers at Lumia extracted authentication tokens from the memory of LLM desktop applications. ATLAS records that an attacker could delete the victim's chats, and spam prompts to hit the provider's anti-bot limits so the victim is banned | Session tokens for AI apps are availability controls too; protect them and watch for sudden rate-limit breaches on one user |
| Sourcegraph 2023 (NHI Mgmt Group breach page) | A leaked site-admin token was used to raise API rate limits and publish a proxy to the underlying LLM; Sourcegraph responded by temporarily reducing rate limits for all free users | The identity that can change rate limits is part of the denial of service attack surface. See Sourcegraph Breach 2023 |
Detection
Monitor in units of cost, not only requests. A dashboard that shows requests per second will look normal while ten long-context requests saturate a GPU pool.
| Signal | Points to | Source |
|---|---|---|
| Rise in queue depth, time to first token or p95 latency without a matching rise in requests | Expensive inputs or output exhaustion | Inference server metrics (queue, batch, token throughput) |
| Requests near the maximum context or maximum output length from one key or cluster | Context and output exhaustion | Gateway logs with input and output token counts |
| Per-request latency or energy far above the model's normal distribution for that input size | Sponge-style inputs | Per-request timing and accelerator utilisation |
| Agent runs hitting step, retry or tool call ceilings, or loops repeating the same tool call | Agent amplification | Agent orchestration traces |
| Code execution sandboxes hitting time or memory limits | Non-terminating generated code | Sandbox runtime logs |
| Burst of limit breaches on a single user session from new devices or networks | Stolen session used for account-level denial | Identity provider and application session logs |
| Changes to rate limit or quota settings outside change windows | Abuse of administrative access | Admin audit logs |
Measuring it
- Cost-weighted availability: service level measured as time to first token and completion latency at p95 and p99, per model.
- Limit coverage: share of endpoints and agent workflows with input token, output token, execution time and step limits set.
- Top-consumer share: share of accelerator time used by the top 1 per cent of keys, reviewed daily.
- Timeout rate: share of requests ended by timeout or ceiling, with trend; a sudden rise is an early warning.
- Recovery time: minutes from saturation alert to restored latency in exercises and incidents.
Prevention: ATLAS mitigations mapped
ATLAS release 2026.10 links five mitigations to AML.T0029. Cross-technique rollout is covered in the MITRE ATLAS Mitigations Guide.
| ATLAS mitigation | What ATLAS says for this technique | Settings to define |
|---|---|---|
| AML.M0004 Limit AI Service Query Volume and Rate | Limit the number of queries users can make in a given interval | Rate, burst and concurrency per user, key, tenant and device, plus daily or monthly quotas; watch for limit evasion through account rotation |
| AML.M0036 Limit AI Workload Resource Consumption | Limit the resources individual requests consume | Maximum input size and context, output tokens, batch size, execution time, memory; for agents, iterations, retries, tool calls, parallel tasks, delegation depth and spend; timeouts, cost ceilings and circuit breakers across the whole workflow |
| AML.M0015 Predictive AI Adversarial Input Detection | Assess queries before the inference call, or enforce a timeout policy for queries that use excessive resources | Pre-inference checks on size and structure; per-request timeout |
| AML.M0019 Control Access to AI Models and Data in Production | Access controls on model APIs can stop excessive querying that disables the system | Authentication on every endpoint, no anonymous inference, tiered access |
| AML.M0035 AI Red Team | Submit adversarial workloads, exercise dependency failures, then apply quotas, concurrency limits, timeouts, resource isolation and graceful degradation based on findings | Load and abuse tests in each release cycle |
- Isolate tenants and priorities: separate pools or priority queues for paying, internal and free traffic, so a flood on one tier does not starve the rest. See the GPU and AI Cluster Multi Tenancy Security guide.
- Degrade gracefully: OWASP LLM10 recommends keeping partial functionality under heavy load. Fall back to a smaller model, shorter outputs or cached answers rather than failing outright.
- Sandbox generated code: any application that runs model output needs a separate runtime with CPU time, memory and network limits.
- Plan capacity for the worst case: the sponge examples authors recommend analysing energy use from a worst-case rather than average-case view. Size limits on the most expensive input you accept, not the typical one.
- Front the model with a gateway: enforce token-aware limits and per-key accounting in one place. See the AI Gateway and LLM Gateway Guide and the vLLM, Triton and NVIDIA NIM Inference Server Security Guide.
Choosing limits by deployment
| Deployment | Main exposure | Limits that matter most |
|---|---|---|
| Public chat or LLM API | Floods from many accounts; long-context abuse | Verified tiers, token-aware rate limits, per-tier pools, edge DDoS protection |
| Internal LLM app on a shared GPU pool | One team or job starving others | Per-team quotas, priority queues, maximum context and output per request |
| Agent platform | Loops, retries and fan-out from one task | Step, retry, tool call, parallelism, delegation depth and spend ceilings per run |
| App that executes model output | Non-terminating or heavy generated code | Sandbox with time, memory and network limits; kill on breach |
| Self-hosted model at the edge or on premises | Small fixed capacity | Strict concurrency, input size limits, authentication even on internal networks |
Small teams using a hosted model API mostly inherit the provider's capacity protections, but still own the application layer: output token caps, agent step limits, sandboxing and per-user limits in their own app. A per-user limit in your app also stops one abusive user from consuming the whole organisation's provider quota, which would deny service to everyone else. See AI Agent Rate Limits.
Where identity fits
Every limit in this guide is keyed to an identity: a user, an API key, a tenant or a workload. Our recommendations (NHI Mgmt Group):
- No anonymous inference: require authentication so limits can be applied and abusive callers removed.
- One key per workload: a shared key across services means one runaway job exhausts the quota for all of them, and the key cannot be revoked without an outage.
- Protect the limit controls: rate limit and quota settings should be changeable only by a small, monitored admin group, with short-lived credentials. The Sourcegraph case shows what one leaked admin token can do.
- Protect user sessions: AIKatz shows that a stolen session token can be used to get a real user banned. Bind sessions to devices where the platform supports it and alert on sudden limit breaches.
Response
- Confirm the shape: flood, expensive inputs, agent loop or account-level abuse, using the detection table above.
- Protect priority traffic: shift paying or internal traffic to a protected pool and shed lowest-priority tiers first.
- Tighten limits: lower maximum context and output, reduce concurrency for the affected tier, and block or throttle the keys and accounts involved.
- Kill runaway work: stop looping agent runs and sandboxed executions that hit ceilings; check whether any agent spent money or acted externally.
- Check identity abuse: look for leaked or stolen keys, sessions or admin credentials behind the traffic and rotate them.
- Recover and review: restore limits stepwise, record the incident against AML.T0029, and add the input pattern to red team tests. For network-level floods use the DDoS Response Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0029; tactic AML.TA0011 | Technique |
| MITRE ATLAS related | AML.T0034 Cost Harvesting, AML.T0046 Spamming AI System with Chaff Data, AML.T0051 LLM Prompt Injection | Neighbouring impact techniques and a common enabler |
| MITRE ATLAS mitigations | AML.M0004, AML.M0015, AML.M0019, AML.M0035, AML.M0036 | Mitigations ATLAS links to the technique |
| MITRE ATT&CK | T1499, T1499.003, T1498 | Enterprise denial of service equivalents |
| OWASP Top 10 for LLM Applications 2025 | LLM10 Unbounded Consumption | Variable-length input flood, resource-intensive queries, timeouts, graceful degradation |
| NIST SP 800-53 Rev. 5 | SC-5, SC-6, SI-4, AC-3 | Denial of service protection, resource availability, monitoring, access enforcement |
| NIST CSF 2.0 | PR.IR-04, DE.CM-09, RS.MI-01 | Adequate capacity, runtime monitoring, containment |
For the general application layer view, see the Denial of Service at Application Layer Guide.
Common failure patterns
- Request limits without token limits: a per-minute request cap that still allows maximum context and maximum output on every call.
- Executing model output unbounded: generated code run in the application process with no time or memory limit, as in AML.CS0016.
- Agents without ceilings: no cap on steps, retries or tool calls, so one bad task loops until the budget or the pool runs out. See the Denial-of-Wallet and AI Agent Cost Runaway Guide.
- One shared pool: free, paid and internal traffic on the same accelerators with no priority, so any flood hits everyone.
- Average-case capacity planning: sizing on typical prompts while accepting inputs that cost many times more.
- Unprotected limit settings: rate limits that a single long-lived admin token can raise.
Practitioner checklist
- Require authentication on every inference endpoint and issue one key per workload.
- Set rate, burst, concurrency and quota limits per user, key and tenant, measured in tokens as well as requests.
- Cap input context, output tokens and execution time per request, and enforce timeouts at the gateway and the server.
- Cap agent steps, retries, tool calls, parallel tasks, delegation depth and spend per run.
- Run any generated code in a sandbox with time, memory and network limits.
- Separate pools or priority queues for paid, internal and free traffic, with a graceful degradation plan.
- Monitor queue depth, time to first token, p95 latency and top-consumer share, with alerts.
- Restrict and audit who can change rate limits and quotas.
- Include expensive-input and agent-loop tests in AI red team and load testing each release.
Standards and references
- MITRE ATLAS: Denial of AI Service
- MITRE ATLAS: Limit AI Workload Resource Consumption
- MITRE ATLAS: Achieving Code Execution in MathGPT via Prompt Injection
- MITRE ATLAS: AIKatz: Attacking LLM Desktop Applications
- OWASP: LLM10:2025 Unbounded Consumption
- Shumailov et al.: Sponge Examples: Energy-Latency Attacks on Neural Networks (IEEE EuroS&P)
- Sourcegraph: Security update (August 2023)
Related NHI Mgmt Group resources: OWASP LLM Top 10 LLM10 Unbounded Consumption Guide · Denial-of-Wallet and AI Agent Cost Runaway Guide · MITRE ATLAS AML.T0046 Spamming AI System with Chaff Data · MITRE ATLAS Guide