What are the signs that a model denial of service attack is underway?

What a model denial of service attack looks like in live operations

A model denial of service attack is not just “the model is slow.” The useful signal is a pattern of resource exhaustion that is hard to explain by normal traffic mix: latency climbs, inference jobs linger, queue depth rises, and the system starts failing on inputs that are intentionally expensive to process. That can happen even when the service is still technically up, which is why teams should watch behaviour rather than only outage status.

For AI services, the boundary between ordinary load and hostile load can be blurred. A burst of legitimate-heavy prompts, a poorly tuned client, or a malicious actor can all produce similar symptoms at first. The differentiator is usually persistence, concentration on cost-amplifying requests, and the way the workload changes under stress. MITRE’s adversary-oriented framing is useful here because it helps teams separate load symptoms from exploitation patterns and ask what an attacker is trying to exhaust or monopolise. MITRE ATT&CK Enterprise Matrix

In practice, many security teams notice the attack only after queues and timeout rates rise, rather than through a deliberate alert tied to cost-amplifying request patterns.

How the attack shows up across the inference path

Model denial of service usually manifests where the system has the most expensive bottlenecks: token generation, context handling, retrieval steps, safety checks, upstream orchestration, or shared GPU and CPU pools. The attacker does not need to “break” the model. They only need to force the service into work that is disproportionately expensive relative to the request volume they send.

• Large prompts or extreme context lengths can drive disproportionate processing time.
• Repeated retries can amplify queue pressure and inflate apparent demand.
• Many concurrent requests can starve shared capacity, especially when rate limits are weak.
• Tool-using or agentic workflows may compound the effect by triggering multiple downstream calls per request.

That is why operators should inspect both model telemetry and surrounding platform telemetry. If only the model layer is monitored, the real choke point may be missed. If only infrastructure alerts are monitored, teams may not see that the same prompt shape or request pattern is driving the exhaustion. The strongest signals tend to be correlated: unusual prompt complexity, growing tail latency, rising GPU or memory pressure, and a widening gap between accepted requests and successfully completed requests. CISA’s general advisory material is a useful external reference for recognising active cyber disruption patterns even when the exact abuse path is AI-specific. CISA cyber threat advisories

In environments that use retrieval or external tools, the failure can also spread laterally across dependencies, so the visible symptom may be an application slowdown before the model itself appears saturated.

When a slowdown is really an abuse pattern

Tighter request controls often improve resilience but increase friction for legitimate users, so organisations have to balance service quality against abuse resistance. The main edge case is that not every expensive workload is malicious. Large documents, code-heavy prompts, batch workflows, and evaluation jobs can create a similar footprint, which means teams need context before declaring an attack.

Guidance versus consensus: there is broad agreement that sustained resource exhaustion is the core issue, but there is less consensus on which single metric best proves malicious intent. Some teams focus on request rate, others on token volume, and others on queueing and cost per request. In practice, the right answer is usually to use all three together and look for an abnormal concentration of expensive work from the same source, tenant, workflow, or prompt family.

Another edge case is partial degradation. The service may still answer some requests quickly while failing only on long-context or tool-heavy inputs. That does not rule out an attack. It can indicate selective pressure against the costliest execution path. MITRE ATLAS adversarial AI threat matrix is especially relevant where the abuse is shaped around AI-specific execution paths rather than generic infrastructure saturation.

Risk and Threat Considerations

Model denial of service is a material availability and governance risk because it can keep a service online while still degrading user trust, response quality, and operational continuity. The exposure is greatest where shared inference capacity, weak throttling, or expensive tool chains let a small number of requests consume a disproportionate share of resources.

Failure mechanism: The attacker or abusive workload amplifies compute cost per request through large contexts, repeated retries, concurrency spikes, or chained model/tool calls until queues, latency, or memory pressure exceed acceptable service levels.

Impact: Users see timeouts, failed completions, stalled workflows, and unpredictable performance, and the organisation may also absorb elevated cloud spend, lost productivity, and reduced confidence in the system’s reliability.

Practitioner Guidance

What to prioritise: Treat sustained tail-latency growth plus queue buildup as the earliest operational trigger, not complete outage. That combination usually tells you the service is being pushed toward exhaustion before standard availability alarms fire.

What to verify: Confirm whether the load spike is concentrated in a small set of sources, prompt shapes, tenants, or workflow paths. If the expensive traffic is diverse and tied to legitimate batch work, the response should be capacity management; if it is concentrated and repetitive, treat it as abuse until proven otherwise.

Decision rule: If failures appear mainly on unusually large, complex, or tool-heavy inputs, investigate the cost-amplifying path first. If all request types degrade uniformly, look harder at infrastructure saturation or upstream dependency failure rather than assuming model-specific denial.

Practitioner takeaway: The most reliable sign of an active model denial of service is not simple slowness, but a sustained mismatch between request volume and the amount of compute each request is forcing the service to burn.

Related resources from NHI Mgmt Group

• What are the signs that an identity attack is underway even when there is no obvious service outage?
• What are the signs that a denial-of-service attack or insider threat may be unfolding?
• What are the signs that a denial-of-service flaw is a high-leverage problem?
• What are the signs that an adversarial attack is affecting AI model outputs?