Rate Limiting to Stop AI Model DoS Attacks
A company develops an AI model to diagnose patients. Hospitals access the model through an integrated application programming interface (API). The security team performs a denial-of-service (DoS) attack via brute force on the model. Which of the following controls would have prevented this issue?
Community Insight
The question tests API-level availability protections for AI systems, and the trap is choosing data- or content-focused controls (tokenization, guardrails, prompt firewalls) that do nothing to stop volumetric brute-force traffic.
This CompTIA CySA+ (CY0-001) question tests which security control prevents a brute-force denial-of-service attack against a healthcare AI model exposed through an API. The analysis establishes that rate limiting is the control that throttles request volume, preserving availability and blocking resource-exhaustion attempts.
The most common wrong picks are prompt firewall or model guardrails, because learners associate "AI security" with input filtering; those controls inspect content semantics, not request frequency, so they cannot prevent a flood of legitimate-format API calls from exhausting the model's resources.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Rate limiting (C) caps the number of API requests a client can make within a defined time window, so a brute-force or resource-exhaustion flood is throttled before the inference backend saturates. In an API-integrated deployment like this diagnostic model, request-frequency controls are the primary safeguard for the availability property that a DoS attack targets. Compounding controls such as API keys, quotas, and backoff challenges sit on the same layer, which is why rate limiting is the correct preventive control. Kristen8730's observation captures this precisely, noting that it "restricts how frequently the API/model can be called, directly mitigating brute-force/resource-exhaustion attacks."Why the Other Options Are Wrong
Tokenization (A) protects data at rest and in transit by substituting sensitive values with non-sensitive tokens; it is a data-security control and has no bearing on request volume or service availability. Model guardrails (B) enforce behavioral boundaries such as refusing harmful or out-of-scope outputs, which is relevant to model misuse but not to volumetric attacks. A prompt firewall (D) inspects and filters prompt content for injection or unsafe instructions, again a content-layer control that cannot stop a flood of syntactically valid requests. None of these three mitigate an attack whose mechanism is simply too many calls in too little time.Community Comment Notes
The single comment aligns with this verdict, with Kristen8730 selecting C and explaining that rate limiting "restricts how frequently the API/model can be called, directly mitigating brute-force/resource-exhaustion attacks." No dissenting comments were posted, so there is no competing rationale to reconcile; the reasoning stands on the technical fit between the attack vector and the control layer.Official Reference
Exam Strategy
When a question names a DoS or brute-force attack against an API-exposed service, look for the availability-layer control (rate limiting, throttling, or quotas) rather than data-protection or content-filtering options. Map each option to the security property it protects: tokenization and encryption address confidentiality, guardrails and firewalls address integrity/behavior, and rate limiting addresses availability.
Frequently Asked Questions
Why doesn't a prompt firewall stop a brute-force DoS attack on the model API?
A prompt firewall filters the content of prompts for injection or unsafe instructions. A DoS flood uses many valid requests, so content filtering does not reduce the load on the model.
Is rate limiting enough to protect an API-integrated AI model?
Rate limiting is the key preventive control for volumetric attacks, but it works best combined with API keys, per-client quotas, monitoring, and autoscaling for defense in depth.