What Is Model Denial of Service (MDoS)?

Token counts and latency per request are telemetry data you already emit. You can use them to catch an inference-layer resource attack while it is still running, hours before the provider invoice shows anything. Disproportionate inference consumption degrades service quality for your other users and drives up your costs.

The Open Worldwide Application Security Project (OWASP) tracked model denial of service as LLM04 in its 2023/24 OWASP Top 10 for LLMs and folded it into LLM10: Unbounded Consumption in the 2025 edition.

This guide covers how MDoS attacks exploit token processing, request volume, context windows, internal compute paths, and safeguards; how you detect them through token, latency, rejection, and cost telemetry; and how you mitigate them with budgets, input controls, gateways, and response playbooks.

How MDoS Differs from Traditional Denial of Service

Model denial of service is an attack in which an adversary consumes disproportionate inference compute through interactions with a large language model (LLM). OWASP described it in 2023/24 as an interaction “that consumes an exceptionally high amount of resources, which results in a decline in the quality of service for them and other users, as well as potentially incurring high resource costs.”

Network-layer denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks target bandwidth and server uptime. MDoS targets graphics processing unit (GPU) memory and token-processing capacity. Transformer decode is often constrained by memory bandwidth because serving each generated token requires repeated access to model weights and a growing key-value (KV) cache. Saturation rarely appears as an outage because users see inference latency spikes first.

The DDoS scrubbing that sits in front of your infrastructure operates at Layer 3 and Layer 4, filtering packet headers and connection metadata with no visibility into request contents. Modern web application firewalls (Layer 7) and can inspect request bodies and application programming interface (API) request counts, but standard configurations of both cannot track model tokens, context length, or cache allocation. An abusive 100,000-token prompt looks the same across your stack as a legitimate long-context request.

How Model Denial of Service Attacks Work

The attack surface splits across five mechanisms, each exploiting a different transformer property. Attackers target input size and request volume. They can also target internal compute paths. Requests can remain syntactically valid, so request-count controls may miss low-volume variants.

Resource Exhaustion Through Token Processing

Inference cost scales with token count. One oversized prompt can be far more expensive than a short request before output charges. Retrieval-augmented generation makes oversized prompts routine because a single call may contain whole documents. An attacker can consume disproportionate resources without producing obviously abnormal traffic.

High-Volume Query Flooding

Flooding an LLM endpoint differs from Hypertext Transfer Protocol (HTTP) flooding because each request can be individually valid. Repeated requests consume computational resources and make the service unavailable to legitimate users. Scripted clients can generate this load without a botnet, so per-key request ceilings are the natural control point before examining context-window abuse.

Large Prompt and Context Window Abuse

Context stuffing targets the window itself. Continuous input overflow sends input exceeding the context window, while attackers using a variable-length input flood carefully craft inputs to reach the context-window limit. Recursive context expansion forces repeated expansion and reprocessing. It increases work per request without increasing request volume.

Sponge Attacks

Attackers design sponge examples that drive the model toward worst-case internal computation paths to maximize energy consumption and latency. The 2020 arXiv benchmark on sponge examples found that they raised language-model latency and energy by a factor of 30. T

The National Institute of Standards and Technology (NIST) AI Risk Management Framework lists sponge attacks under action MS-2.7-007 as a threat worth testing against. Your MDoS test plan should exercise these internal compute-path abuses alongside token and request-volume scenarios.

Safeguard Exploitation (DoS via Rejection)

Your AI guardrails are an attack surface. Attackers can exploit safeguard false positives. This can fool the safeguard model into blocking safe content and denying service to LLM users. 

Stealth-oriented prompt tuning produced strings roughly 30 characters long (cited above). When attackers injected those strings into a user’s prompt template, they blocked over 97 percent of user requests on Llama Guard 3. Existing defenses cut the attack success rate to around 40 percent, but drop true positive rates below 50 percent on clean data.

OWASP LLM04 Vulnerability Examples and Attack Scenarios

The 2023/24 LLM04 entry lists six vulnerability examples. Three of them, continuous input overflow, variable-length input flood, and recursive context expansion, sit in the context-window family already covered under Large Prompt and Context Window Abuse above. The remaining three cover tokenization cost, request repetition, and agent orchestration.

• Repetitive long inputs. Each request exceeds the context window, and the attacker sends them back to back. Request volume stays low while token and cache consumption climbs.
• Unusual orthography or sequences. Some inputs are disproportionately expensive to tokenize because of rare character sequences or encodings that fragment into many tokens.
• Agentic queue flooding. Task queues in tools like LangChain or AutoGPT absorb the load, so include AI agent monitoring in scope.

All three patterns can slow or stall the system. Some keep request counts flat while burning tokens, while others raise request volume through calls that each look valid on their own.

Why MDoS Is Harder to Detect than Traditional DoS

A low-rate, high-token workload can burn money while request dashboards stay green with a zero percent error rate. Billing dashboards lag by hours to days. That pushes your mean time to detect past the point where the money is gone.

Bedrock cost data can take up to 24 hours to appear in Amazon Web Services (AWS) Cost Explorer. In shared cloud or software as a service (SaaS) deployments, tenants may share the same provider key. This prevents attribution unless you stamp a tenant identifier on each request.

Near-real-time token throughput and latency metrics provide the detection opportunity.

The Business Impact of Model Denial of Service

MDoS can escalate costs quickly. At $2.00 input-token pricing per million tokens, a flood of 1,000 requests at 100,000 input tokens each generates $200 in input charges alone. Sourcery documented an abuse case that took an OpenAI bill from a $2,000 monthly baseline to $45,000, with a $43,000 abuse bill across 215,000 requests in 48 hours.

Service degradation compounds the financial hit. Attackers can saturate queues or GPU pipelines. This can produce latency spikes and throttling. It can also make the service unavailable. Autoscaling can provision more resources and amplify the cost.

In multi-tenant deployments, one attacker’s KV cache consumes capacity other tenants need and may drive customers away.

How to Detect Model Denial of Service in Production

Detection depends on instrumenting LLM observability at your application layer before requests reach the model. Four signal families cover the attack patterns. You already emit the required telemetry if you log tokens and latency per request. Combining them helps distinguish expensive legitimate sessions from abuse:

• Token usage per session and per user: Tracking p95 and p99 on input and output token counts surfaces outliers greater than 2× p95, though that is a practitioner rule of thumb, so calibrate against your own baseline first.
• Latency percentiles as saturation indicators: Time to first token (TTFT) can degrade before throughput collapses. Treat p95 and p99 TTFT limits as example starting thresholds, then calibrate them against your endpoint baselines.
• Rate of guardrail rejection: A spike in refusals, particularly when the refused prompts look benign, is the direct signature of safeguard exploitation. False-refusal rate belongs in your standing metric set.
• Cost per request trending: An application-specific ceiling beats provider billing exports. As example starting thresholds, alert when cost per request exceeds twice the daily baseline or one session exceeds 10× the average, then tune both values to your workload.

Each signal read in isolation misses mechanisms the others catch. Coralogix’s AI Center includes Token tracking, which breaks down cost per message, session, and agent. Automated anomaly detection also identifies suspicious usage and cost-harvesting attempts.

How to Prevent and Mitigate Model Denial of Service

Prevention requires token-based controls. Two calls to the same endpoint can differ by orders of magnitude in tokens and compute. Enforce limits before the provider call because the invoice arrives too late.

Rate Limiting and Token Budgets

The token bucket algorithm maps onto token budgets: each identity gets a bucket with a capacity and refill rate. Requests arriving against an empty bucket receive an HTTP 429 with a Retry-After header before reaching the provider.

Budgets should count tokens per minute alongside requests per minute. They should track prompt and completion tokens separately, as well as total tokens. Output length remains harder to predict at request time.

Input Validation and Prompt Length Controls

Recommended controls begin with input validation and sanitization, plus strict limits based on the model’s context window. Snyk’s mitigation example rejects input over 5,000 characters. Additional controls cap resource use per request and limit queued actions in systems reacting to LLM responses.

Gateways and Reverse Proxies with LLM Awareness

A standard reverse proxy and an LLM-aware gateway differ in what each reads before deciding. An LLM-aware gateway terminates the client request and reads the body so budget checks happen before the provider bills any tokens.

Capability	Standard proxy (NGINX)	LLM-aware gateway
What it inspects	Packet and HTTP headers	JSON body: model name, message content
Unit it counts	Requests per second	Input tokens pre-request, output tokens post-response
Enforcement scope	HTTP requests/sec, no model-aware accounting	Key, user, team, or session budget

LLM-aware gateways such as Kong’s ai-rate-limiting-advanced plugin count AI tokens requested rather than raw HTTP requests. Kong’s cost strategy, for example, computes (prompt_tokens × input_cost + completion_tokens × output_cost) / 1,000,000 and expresses a per-key budget in dollars instead of requests. It settles against actual prompt and completion token counts, so a long-context call draws down the budget according to its cost.

Monitoring, Alerting, and Response Playbooks

Continuous monitoring of resource utilization works only when thresholds connect to a response path. A threshold breach fires an alert and pages the on-call engineer. The gateway then throttles the offending key or returns a 429. The response team reviews the session’s prompts after the incident.

Fine-grained quotas set computation limits per user session and agent instance, while output-length prediction can truncate potentially malicious responses during generation. Your runbook should identify who owns token budgets and support degraded-mode serving or reserved capacity so one tenant cannot consume the inference tier.

Observability as the Missing Layer in MDoS Defense

Provider billing exports arrive hours to days later, while token and latency telemetry is available per request in near real time. Coralogix’s AI Center pairs its evaluation engine and session-level cost anomaly detection with AI Guardrails, which block or rewrite unsafe prompts inline before they reach the model.

Frequently Asked Questions About Model Denial of Service

What is OWASP LLM04?

LLM04 was the model denial of service entry in the 2023/24 OWASP Top 10 for LLM Applications. The 2025 edition folded it into LLM10: Unbounded Consumption.

What is a sponge attack on an LLM?

A sponge attack uses inputs that attackers tune to maximize energy consumption and latency. These inputs push the model toward worst-case internal computation paths. It needs no request flood because the input drives disproportionate work inside the model.

How is model DoS different from prompt injection?

LLM prompt injection falls under the Execution tactic, while denial of AI service falls under Impact, a split worth carrying into your GenAI security program. Prompt injection manipulates model behavior to exfiltrate data or bypass safety, while MDoS exhausts resources and inflates cost without necessarily changing what the model says.

Can model DoS attacks be automated?

Yes. Adversarial prompt tuning can keep malicious strings short and benign-looking. Automated scripts can generate repeated requests for context-window attacks.

What is the business cost of a model DoS attack?

A short long-context flood can cost hundreds of dollars, while sustained abuse can push a provider bill into five figures. Impact also includes latency, autoscaling, incident response, and customer churn.

You can book a demo to see how Coralogix tracks per-session token consumption and cost anomalies while the tokens are still being spent.