Does denial-of-service require stealing data?

No. It targets availability and can occur without a confidentiality breach.

Is DDoS different from DoS?

DDoS is a distributed form involving multiple sources; both concern disrupted access or operation.

Can an AI system suffer availability problems from a few requests?

Potentially, if those requests consume disproportionate resources or encounter a defect. Traffic volume is only one part of the threat and capacity picture.

AI Glossary / Governance, ethics and safety / Intermediate

Denial-of-service

Definition

Denial-of-service, commonly abbreviated DoS, is the prevention of authorized access to a resource or a delay that makes required operations unavailable when needed. A denial-of-service attack deliberately causes such disruption. In AI services, the affected resource may be network capacity, processing time, memory, a request queue, or a necessary external dependency.

What it means

A service need not be completely offline to be unusable. If an assistant takes an hour to answer a time-sensitive question, availability may have failed even though a response eventually arrives. Attacks are one cause of unavailability, but overload, configuration errors, and ordinary failures can produce similar symptoms. Investigation should distinguish the observed loss of service from assumptions about intent. Distributed denial-of-service, or DDoS, involves multiple sources contributing to the disruption. The distinction describes the source pattern, not a separate definition of the availability goal.

How it works

A service has finite resources and dependencies. When demand exceeds what it can handle, requests may queue, time out, or be rejected. Deliberate abuse can exploit this imbalance or trigger resource exhaustion in other ways. AI workloads add variation: two requests can require very different amounts of computation, and long-running tasks can occupy capacity needed by other users. Defensive design uses appropriate admission controls, resource limits, timeouts, monitoring, and capacity planning. Dependency failures also need handling so that a stalled tool or remote service does not hold resources indefinitely. The right controls depend on the legitimate workload and service objectives.

Three practical examples

An AI help desk limits concurrent expensive jobs per account so that one source cannot occupy all available workers.
A document-analysis service sets documented size and processing limits, with a clear response when a legitimate request exceeds them.
A team tests how its assistant behaves when a necessary search service is unavailable, providing an honest fallback instead of an endless wait. These are defensive availability measures, not techniques for generating attack traffic.

Think of it this way

Think of a service counter with a limited number of staff. If all staff are occupied for long periods, other customers cannot receive timely help. A queue can absorb a short burst, but cannot solve an indefinitely higher arrival rate. The analogy has limits because digital systems have many shared resources and can fail through software defects or dependencies as well as queues. It nevertheless explains why availability involves both capacity and fair access to that capacity.

Worked example

Imagine an AI service with twenty workers. Each ordinary request occupies one worker for two seconds, so a simplified ideal capacity is twenty divided by two, or ten requests per second. If fifteen such requests arrive per second for sixty seconds, 900 requests arrive while at most 600 finish under these assumptions. The queue grows by about 300 requests. A larger queue delays rejection but does not increase processing capacity. If some requests instead take twenty seconds, the same twenty workers can complete only about one such request per second in steady state. This arithmetic ignores startup effects and other bottlenecks, but shows why request count alone may not capture load. A real capacity model should reflect service-time variation and the resources used by different request types.

Illustrative case study

Fictional case: Poplar Answers notices that a small number of document jobs occupy most processing workers, causing ordinary questions to time out. The team separates job classes, introduces appropriate concurrency limits, and adds visibility into queue age and resource use. It checks whether the unusual workload is legitimate before labeling it an attack. The revised design is tested with approved load scenarios and clear stop conditions. The case illustrates how diagnosing resource use can improve resilience without making unsupported claims about malicious intent.

Common misconceptions and mistakes

Not every outage is a denial-of-service attack. Evidence is needed to distinguish deliberate interference from ordinary overload or failure. Adding servers is also not a universal solution if a different dependency remains the bottleneck. A rate limit based only on request count may miss major differences in computational cost. Conversely, overly strict limits can deny service to legitimate users. Another mistake is equating an available login page with a working service: the actual task may still fail because retrieval, model execution, or a downstream tool is unavailable.

Business use

Define acceptable response times and failure behavior for important workflows. Monitor successful task completion, queue delays, resource consumption, and dependency health, not only whether a server responds. Establish escalation and recovery responsibilities, and test fallback behavior under controlled conditions. Consider resource budgets at user, organization, and system levels so one workload does not crowd out all others. Communicate limits clearly and offer appropriate alternatives for large legitimate jobs. After an incident, review both technical causes and user impact, then verify that corrective changes improve the intended availability outcome.

Check your understanding

A service doubles its queue length but keeps the same processing capacity while sustained demand remains above capacity. Has it solved the overload problem?

Answer: No. It can postpone rejection, but the backlog and waiting time still grow unless demand, service cost, or capacity changes.

Related terms

Availability
Resilience
Incident response
distributed denial-of-service
resource exhaustion
rate limiting
concurrency limit
timeout
backpressure

Learn next

Identify the slowest dependency in a familiar AI workflow and define what users should experience if it stalls. In an approved test environment, check whether timeouts release resources and whether other users can continue working. Use those observations to refine limits and recovery procedures.

Sources

NIST CSRC, DoS glossary: https://csrc.nist.gov/glossary/term/DoS NIST Cybersecurity Framework 2.0: https://doi.org/10.6028/NIST.CSWP.29 NIST, Adversarial Machine Learning taxonomy, 2025 edition: https://csrc.nist.gov/pubs/ai/100/2/e2025/final

Previous: Dempster-Shafer theory Next: Denoising