Denial of Service and Resource Abuse Against AI
5 minutes
5 Questions
Denial of Service (DoS) and Resource Abuse against AI systems refer to attacks that degrade, exhaust, or monopolize the computational, financial, or operational resources of AI models and their supporting infrastructure, rendering them unavailable or prohibitively expensive to operate. Unlike traditional DoS attacks that flood networks with traffic, AI-specific variants exploit the unique cost asymmetry of machine learning: a small, cheap input can trigger disproportionately heavy processing on the server side. Common techniques include sponge attacks, where adversaries craft inputs that maximize inference latency and energy consumption; prompt-based resource exhaustion, where attackers submit extremely long contexts, recursive or looping instructions, or requests that force maximum-length generations in large language models; and model-chaining abuse, where agentic systems are manipulated into invoking tools, APIs, or sub-models excessively. Financial resource abuse, sometimes called Denial of Wallet, targets pay-per-use cloud AI deployments, inflating costs until the service becomes economically unsustainable. Additional vectors involve training pipeline poisoning that bloats datasets, adversarial inputs that trigger expensive fallback or human-review paths, and automated account creation to bypass rate limits. From an AI Security Management perspective, these threats are listed in frameworks such as OWASP Top 10 for LLM Applications (Unbounded Consumption) and MITRE ATLAS. Risk management responses include strict input validation and token limits, per-user and per-tenant rate limiting, quota enforcement and cost alerting, request complexity scoring, timeouts on inference and tool calls, caching of frequent queries, autoscaling with hard ceilings, anomaly detection on usage patterns, and circuit breakers for agentic loops. Governance should treat availability and cost exposure as explicit risk categories, conduct load and adversarial stress testing, define incident response playbooks, and align controls with business continuity objectives. Ultimately, protecting AI availability requires recognizing that model compute itself is an attack surface requiring layered, continuously monitored defenses.
Denial of Service and Resource Abuse Against AI: A Complete Study Guide for ISACA AAISM
Why This Topic Matters
Artificial intelligence systems, and large language models (LLMs) in particular, consume far more compute, memory and energy per request than conventional web applications. A single poorly bounded prompt can tie up a GPU for seconds or minutes, and a burst of such prompts can degrade or completely halt a service that an organization depends upon. Because many AI services are billed by token, by inference call or by GPU-hour, attackers do not even need to take a system offline to cause damage: they can simply run up the bill. This is why the ISACA Advanced in AI Security Management (AAISM) body of knowledge treats Denial of Service (DoS) and resource abuse against AI as a core risk within the AI Risk Management for Security domain.
For the AI security manager, this topic sits at the intersection of three concerns: availability (one of the three pillars of the CIA triad), financial exposure (uncontrolled cloud and API spend) and business continuity (AI increasingly underpins customer service, fraud detection, decision support and operational workflows). Understanding how these attacks work, and how to govern the controls that prevent them, is essential both for the exam and for real-world practice.
What It Is
Denial of Service against AI is any deliberate action that renders an AI model, pipeline or supporting infrastructure unavailable, unresponsive or unacceptably slow for legitimate users. Resource abuse is the broader category: the attacker's aim may not be to bring the service down but to consume computing resources, exhaust quotas, inflate costs or divert capacity for the attacker's own purposes. The two concepts overlap heavily, and exam questions often treat them together.
Key frameworks you should be able to reference:
• OWASP Top 10 for LLM Applications: the 2023 edition listed LLM04: Model Denial of Service; the 2025 edition broadened this into LLM10: Unbounded Consumption, which explicitly covers excessive inference, denial of wallet and model extraction through unrestricted querying.
• MITRE ATLAS: includes impact techniques such as Denial of ML Service and Cost Harvesting, along with Spamming ML System with Chaff Data.
• NIST AI Risk Management Framework (AI RMF): the Secure and Resilient trustworthiness characteristic directly addresses the system's ability to withstand adverse events and return to normal function.
• ISO/IEC 42001 and ISO/IEC 23894: AI management system and AI risk management guidance that require organizations to identify, assess and treat availability and resource risks.
Common Forms of DoS and Resource Abuse Against AI
1. Volumetric request flooding. The classic approach: overwhelming an inference API with a high volume of requests from botnets or distributed sources, exhausting connection pools, queue capacity or GPU scheduling.
2. Resource-intensive or adversarial inputs (sponge attacks). Inputs crafted to maximize energy consumption and latency. For LLMs this includes extremely long prompts that fill the context window, prompts that provoke maximum-length outputs, requests that trigger repeated tool calls or recursive agent loops, and unusual tokens or character sequences that are expensive to process. In vision models, specially perturbed images can force maximal activation across the network. These attacks achieve high impact with low request volume, making them hard to detect with simple rate limits.
3. Context window and memory exhaustion. Repeatedly expanding a conversation so that the model must reprocess an ever-growing history, or exploiting retrieval-augmented generation (RAG) pipelines by triggering retrieval of huge document sets.
4. Recursive and agentic amplification. In agent-based systems, a single user instruction can spawn many downstream model calls, plug-in invocations or API requests. An attacker who can induce a loop (for example, through indirect prompt injection in a retrieved document) can create a multiplier effect that drains resources without obvious external traffic.
5. Denial of wallet (economic DoS). Because inference is metered, attackers deliberately generate expensive requests to inflate the victim's cloud or vendor bill. Autoscaling infrastructure without spending caps makes this especially dangerous: the system stays up but the finance department suffers.
6. Quota and rate-limit exhaustion. Consuming an organization's allocation with a third-party model provider so legitimate internal users are refused service.
7. Training and data pipeline attacks. Flooding data ingestion endpoints with chaff data, poisoning feedback loops to force expensive retraining, or triggering continuous fine-tuning jobs.
8. Model extraction as resource abuse. High-volume systematic querying to replicate a model consumes resources and also threatens intellectual property; the 2025 OWASP category deliberately groups this with unbounded consumption.
9. Infrastructure hijacking. Compromise of GPU clusters or MLOps platforms to run cryptomining or the attacker's own workloads, starving legitimate AI jobs.
How These Attacks Work: Attack Chain View
Understanding the sequence helps you answer scenario questions:
• Reconnaissance: the attacker probes the API to learn limits, context size, pricing tiers, timeout behavior and whether authentication is enforced.
• Weaponization: crafting inputs that maximize cost per request (long prompts, requests for exhaustive outputs, instructions that trigger tools or loops) or assembling a distributed set of sources.
• Delivery: through public endpoints, embedded chatbots, free-tier accounts, stolen API keys, or indirect injection via content the AI will later process.
• Exploitation: the system allocates resources without adequate bounds; queues grow, latency climbs, autoscaling spins up expensive capacity or quotas are exhausted.
• Impact: service degradation or outage, SLA breaches, financial loss, cascading failures in dependent business processes, and reduced capacity for security functions that themselves rely on AI (such as anomaly detection).
Risk Assessment Considerations for the AI Security Manager
The AAISM perspective is managerial. You are expected to think in terms of likelihood, impact, risk appetite and control selection rather than packet-level detail.
• Business impact analysis: identify which AI services are mission-critical and define recovery time objectives (RTO) and acceptable degradation levels.
• Exposure analysis: public-facing, unauthenticated or free-tier endpoints carry higher likelihood. Agentic systems and RAG pipelines carry higher amplification impact.
• Financial risk: quantify maximum plausible spend under attack; treat uncapped autoscaling as a control weakness.
• Third-party dependency: assess provider SLAs, shared-tenancy risk, quota policies and the provider's own DoS protections.
• Dependency mapping: recognize downstream processes that fail when the AI service fails, including security tooling.
Controls: Preventive, Detective and Corrective
Preventive controls
• Strong authentication and authorization for all model endpoints; no anonymous access to expensive capabilities.
• Rate limiting and throttling per user, per API key, per IP and per tenant, with tiered limits based on trust level.
• Hard caps on input size, output tokens, context length, number of tool calls per request and recursion depth in agents.
• Request complexity scoring and cost-aware admission control that rejects or deprioritizes expensive requests when load is high.
• Input validation and sanitization to detect anomalous token patterns, repeated characters and known sponge signatures.
• Timeouts, circuit breakers and bulkheads so one abusive workload cannot consume all capacity.
• Resource quotas at the infrastructure level (Kubernetes limits, GPU scheduling policies, cloud budget caps and spending alerts).
• Caching of common responses and use of smaller, cheaper models for triage before invoking expensive ones.
• Secure API key management to prevent stolen-credential abuse.
• Network-level protections: WAF, DDoS mitigation services, geo-fencing where appropriate.
Detective controls
• Monitoring of latency, queue depth, token consumption, cost per user and GPU utilization with anomaly detection.
• Logging of requests with sufficient detail to attribute abuse while respecting privacy requirements.
• Financial telemetry integrated with security monitoring so denial of wallet is detected as a security event.
• Behavioral analytics to spot model-extraction query patterns.
Corrective and resilience controls
• Graceful degradation: fall back to cached answers, smaller models or static responses rather than total failure.
• Incident response playbooks specific to AI availability events, including authority to block tenants and freeze spending.
• Capacity planning, redundancy and multi-region or multi-provider failover where justified by criticality.
• Post-incident review feeding back into risk register updates and control tuning.
Governance Dimension
Expect the exam to test whether you connect technical controls to governance artifacts: documented risk appetite for AI availability and spend, policies requiring rate limits and token caps as a baseline, contractual SLAs and shared-responsibility clauses with AI vendors, inclusion of AI DoS scenarios in business continuity and disaster recovery testing, and regular reporting of availability and cost anomalies to risk committees. The manager's job is to ensure controls are proportionate, measurable and owned.
Exam Tips: Answering Questions on Denial of Service and Resource Abuse Against AI
1. Remember that AI DoS is not just about volume. If a question describes a small number of requests causing severe slowdown or cost, think sponge attack, resource-intensive input or agentic recursion, not a traditional volumetric flood. The best control is usually a bound on input/output size, context length or tool-call depth, rather than only IP-based rate limiting.
2. Spot denial of wallet. When the scenario mentions unexpected cloud invoices, autoscaling or token-based billing, the correct answer typically involves spending caps, budget alerts, cost-aware throttling and treating cost anomalies as security events. Autoscaling without limits is a weakness, not a mitigation.
3. Choose the management-level answer. AAISM is a management certification. Between a highly technical fix and an answer that establishes policy, risk assessment, ownership or governance oversight, the governance answer is usually preferred when the question asks what the AI security manager should do first or what is most important. However, when the question asks for the most effective technical control for a specific attack, pick the control that directly bounds the exploited resource.
4. Map to the CIA triad. DoS and resource abuse are primarily availability risks, but model extraction through unrestricted querying also implicates confidentiality and intellectual property. If a question pairs heavy querying with model replication, consider both.
5. Know the framework names. Be ready to associate OWASP LLM Top 10 (Model Denial of Service / Unbounded Consumption), MITRE ATLAS (Denial of ML Service, Cost Harvesting), and NIST AI RMF (Secure and Resilient). Questions may ask which framework category a scenario belongs to.
6. Watch for amplification clues. Words such as agent, plug-in, tool use, retrieval or chained calls signal that a single request can multiply into many. The right mitigation includes limits on recursion depth, per-request call budgets and isolation of the agent's execution environment.
7. Prefer layered defense. If an option offers a single control and another offers a combination of authentication, rate limiting, size caps, monitoring and graceful degradation, the layered option is normally correct. Eliminate answers that rely solely on perimeter DDoS protection, since that does not address resource-intensive inputs from authenticated users.
8. Distinguish preventive, detective and corrective. Questions may ask which type of control a measure represents. Rate limits and token caps are preventive; cost and latency anomaly monitoring is detective; failover, graceful degradation and incident playbooks are corrective.
9. Third-party scenarios. When the organization uses an external model provider, focus on contractual SLAs, quota management, API key protection, understanding the shared-responsibility model and having fallback options. You cannot patch a vendor's infrastructure, but you can govern your consumption of it.
10. Do not confuse DoS with prompt injection or data poisoning. Although injected prompts can trigger resource abuse, the exam will usually be clear about the objective. If the impact described is unavailability or runaway cost, categorize it as DoS/resource abuse even if the vector was injection.
11. Resilience over perfection. Answers emphasizing graceful degradation, redundancy and tested recovery reflect the NIST AI RMF resilience concept and are favored over answers implying all attacks can be blocked.
12. Read for the question's verb. Identify the risk, select the control, prioritize the response and report to stakeholders each call for a different kind of answer. Match the answer to the verb and to the stakeholder's level.
Quick Review Summary
• AI systems are disproportionately expensive per request, making availability and cost attacks attractive.
• Attack types: volumetric floods, sponge/resource-intensive inputs, context exhaustion, agentic recursion, denial of wallet, quota exhaustion, pipeline flooding, extraction via unbounded querying, infrastructure hijacking.
• Frameworks: OWASP LLM Top 10 (Model DoS / Unbounded Consumption), MITRE ATLAS (Denial of ML Service, Cost Harvesting), NIST AI RMF (Secure and Resilient), ISO/IEC 42001 and 23894.
• Controls: authentication, rate limits, input/output/context caps, tool-call and recursion limits, timeouts, circuit breakers, spending caps, monitoring of cost and latency, graceful degradation, incident playbooks, vendor SLA governance.
• Exam mindset: think risk-based, layered, governance-aware; recognize low-volume high-cost attacks; treat uncontrolled spend as a security issue; prefer bounded resource allocation over unlimited autoscaling.
Artificial intelligence systems, and large language models (LLMs) in particular, consume far more compute, memory and energy per request than conventional web applications. A single poorly bounded prompt can tie up a GPU for seconds or minutes, and a burst of such prompts can degrade or completely halt a service that an organization depends upon. Because many AI services are billed by token, by inference call or by GPU-hour, attackers do not even need to take a system offline to cause damage: they can simply run up the bill. This is why the ISACA Advanced in AI Security Management (AAISM) body of knowledge treats Denial of Service (DoS) and resource abuse against AI as a core risk within the AI Risk Management for Security domain.
For the AI security manager, this topic sits at the intersection of three concerns: availability (one of the three pillars of the CIA triad), financial exposure (uncontrolled cloud and API spend) and business continuity (AI increasingly underpins customer service, fraud detection, decision support and operational workflows). Understanding how these attacks work, and how to govern the controls that prevent them, is essential both for the exam and for real-world practice.
What It Is
Denial of Service against AI is any deliberate action that renders an AI model, pipeline or supporting infrastructure unavailable, unresponsive or unacceptably slow for legitimate users. Resource abuse is the broader category: the attacker's aim may not be to bring the service down but to consume computing resources, exhaust quotas, inflate costs or divert capacity for the attacker's own purposes. The two concepts overlap heavily, and exam questions often treat them together.
Key frameworks you should be able to reference:
• OWASP Top 10 for LLM Applications: the 2023 edition listed LLM04: Model Denial of Service; the 2025 edition broadened this into LLM10: Unbounded Consumption, which explicitly covers excessive inference, denial of wallet and model extraction through unrestricted querying.
• MITRE ATLAS: includes impact techniques such as Denial of ML Service and Cost Harvesting, along with Spamming ML System with Chaff Data.
• NIST AI Risk Management Framework (AI RMF): the Secure and Resilient trustworthiness characteristic directly addresses the system's ability to withstand adverse events and return to normal function.
• ISO/IEC 42001 and ISO/IEC 23894: AI management system and AI risk management guidance that require organizations to identify, assess and treat availability and resource risks.
Common Forms of DoS and Resource Abuse Against AI
1. Volumetric request flooding. The classic approach: overwhelming an inference API with a high volume of requests from botnets or distributed sources, exhausting connection pools, queue capacity or GPU scheduling.
2. Resource-intensive or adversarial inputs (sponge attacks). Inputs crafted to maximize energy consumption and latency. For LLMs this includes extremely long prompts that fill the context window, prompts that provoke maximum-length outputs, requests that trigger repeated tool calls or recursive agent loops, and unusual tokens or character sequences that are expensive to process. In vision models, specially perturbed images can force maximal activation across the network. These attacks achieve high impact with low request volume, making them hard to detect with simple rate limits.
3. Context window and memory exhaustion. Repeatedly expanding a conversation so that the model must reprocess an ever-growing history, or exploiting retrieval-augmented generation (RAG) pipelines by triggering retrieval of huge document sets.
4. Recursive and agentic amplification. In agent-based systems, a single user instruction can spawn many downstream model calls, plug-in invocations or API requests. An attacker who can induce a loop (for example, through indirect prompt injection in a retrieved document) can create a multiplier effect that drains resources without obvious external traffic.
5. Denial of wallet (economic DoS). Because inference is metered, attackers deliberately generate expensive requests to inflate the victim's cloud or vendor bill. Autoscaling infrastructure without spending caps makes this especially dangerous: the system stays up but the finance department suffers.
6. Quota and rate-limit exhaustion. Consuming an organization's allocation with a third-party model provider so legitimate internal users are refused service.
7. Training and data pipeline attacks. Flooding data ingestion endpoints with chaff data, poisoning feedback loops to force expensive retraining, or triggering continuous fine-tuning jobs.
8. Model extraction as resource abuse. High-volume systematic querying to replicate a model consumes resources and also threatens intellectual property; the 2025 OWASP category deliberately groups this with unbounded consumption.
9. Infrastructure hijacking. Compromise of GPU clusters or MLOps platforms to run cryptomining or the attacker's own workloads, starving legitimate AI jobs.
How These Attacks Work: Attack Chain View
Understanding the sequence helps you answer scenario questions:
• Reconnaissance: the attacker probes the API to learn limits, context size, pricing tiers, timeout behavior and whether authentication is enforced.
• Weaponization: crafting inputs that maximize cost per request (long prompts, requests for exhaustive outputs, instructions that trigger tools or loops) or assembling a distributed set of sources.
• Delivery: through public endpoints, embedded chatbots, free-tier accounts, stolen API keys, or indirect injection via content the AI will later process.
• Exploitation: the system allocates resources without adequate bounds; queues grow, latency climbs, autoscaling spins up expensive capacity or quotas are exhausted.
• Impact: service degradation or outage, SLA breaches, financial loss, cascading failures in dependent business processes, and reduced capacity for security functions that themselves rely on AI (such as anomaly detection).
Risk Assessment Considerations for the AI Security Manager
The AAISM perspective is managerial. You are expected to think in terms of likelihood, impact, risk appetite and control selection rather than packet-level detail.
• Business impact analysis: identify which AI services are mission-critical and define recovery time objectives (RTO) and acceptable degradation levels.
• Exposure analysis: public-facing, unauthenticated or free-tier endpoints carry higher likelihood. Agentic systems and RAG pipelines carry higher amplification impact.
• Financial risk: quantify maximum plausible spend under attack; treat uncapped autoscaling as a control weakness.
• Third-party dependency: assess provider SLAs, shared-tenancy risk, quota policies and the provider's own DoS protections.
• Dependency mapping: recognize downstream processes that fail when the AI service fails, including security tooling.
Controls: Preventive, Detective and Corrective
Preventive controls
• Strong authentication and authorization for all model endpoints; no anonymous access to expensive capabilities.
• Rate limiting and throttling per user, per API key, per IP and per tenant, with tiered limits based on trust level.
• Hard caps on input size, output tokens, context length, number of tool calls per request and recursion depth in agents.
• Request complexity scoring and cost-aware admission control that rejects or deprioritizes expensive requests when load is high.
• Input validation and sanitization to detect anomalous token patterns, repeated characters and known sponge signatures.
• Timeouts, circuit breakers and bulkheads so one abusive workload cannot consume all capacity.
• Resource quotas at the infrastructure level (Kubernetes limits, GPU scheduling policies, cloud budget caps and spending alerts).
• Caching of common responses and use of smaller, cheaper models for triage before invoking expensive ones.
• Secure API key management to prevent stolen-credential abuse.
• Network-level protections: WAF, DDoS mitigation services, geo-fencing where appropriate.
Detective controls
• Monitoring of latency, queue depth, token consumption, cost per user and GPU utilization with anomaly detection.
• Logging of requests with sufficient detail to attribute abuse while respecting privacy requirements.
• Financial telemetry integrated with security monitoring so denial of wallet is detected as a security event.
• Behavioral analytics to spot model-extraction query patterns.
Corrective and resilience controls
• Graceful degradation: fall back to cached answers, smaller models or static responses rather than total failure.
• Incident response playbooks specific to AI availability events, including authority to block tenants and freeze spending.
• Capacity planning, redundancy and multi-region or multi-provider failover where justified by criticality.
• Post-incident review feeding back into risk register updates and control tuning.
Governance Dimension
Expect the exam to test whether you connect technical controls to governance artifacts: documented risk appetite for AI availability and spend, policies requiring rate limits and token caps as a baseline, contractual SLAs and shared-responsibility clauses with AI vendors, inclusion of AI DoS scenarios in business continuity and disaster recovery testing, and regular reporting of availability and cost anomalies to risk committees. The manager's job is to ensure controls are proportionate, measurable and owned.
Exam Tips: Answering Questions on Denial of Service and Resource Abuse Against AI
1. Remember that AI DoS is not just about volume. If a question describes a small number of requests causing severe slowdown or cost, think sponge attack, resource-intensive input or agentic recursion, not a traditional volumetric flood. The best control is usually a bound on input/output size, context length or tool-call depth, rather than only IP-based rate limiting.
2. Spot denial of wallet. When the scenario mentions unexpected cloud invoices, autoscaling or token-based billing, the correct answer typically involves spending caps, budget alerts, cost-aware throttling and treating cost anomalies as security events. Autoscaling without limits is a weakness, not a mitigation.
3. Choose the management-level answer. AAISM is a management certification. Between a highly technical fix and an answer that establishes policy, risk assessment, ownership or governance oversight, the governance answer is usually preferred when the question asks what the AI security manager should do first or what is most important. However, when the question asks for the most effective technical control for a specific attack, pick the control that directly bounds the exploited resource.
4. Map to the CIA triad. DoS and resource abuse are primarily availability risks, but model extraction through unrestricted querying also implicates confidentiality and intellectual property. If a question pairs heavy querying with model replication, consider both.
5. Know the framework names. Be ready to associate OWASP LLM Top 10 (Model Denial of Service / Unbounded Consumption), MITRE ATLAS (Denial of ML Service, Cost Harvesting), and NIST AI RMF (Secure and Resilient). Questions may ask which framework category a scenario belongs to.
6. Watch for amplification clues. Words such as agent, plug-in, tool use, retrieval or chained calls signal that a single request can multiply into many. The right mitigation includes limits on recursion depth, per-request call budgets and isolation of the agent's execution environment.
7. Prefer layered defense. If an option offers a single control and another offers a combination of authentication, rate limiting, size caps, monitoring and graceful degradation, the layered option is normally correct. Eliminate answers that rely solely on perimeter DDoS protection, since that does not address resource-intensive inputs from authenticated users.
8. Distinguish preventive, detective and corrective. Questions may ask which type of control a measure represents. Rate limits and token caps are preventive; cost and latency anomaly monitoring is detective; failover, graceful degradation and incident playbooks are corrective.
9. Third-party scenarios. When the organization uses an external model provider, focus on contractual SLAs, quota management, API key protection, understanding the shared-responsibility model and having fallback options. You cannot patch a vendor's infrastructure, but you can govern your consumption of it.
10. Do not confuse DoS with prompt injection or data poisoning. Although injected prompts can trigger resource abuse, the exam will usually be clear about the objective. If the impact described is unavailability or runaway cost, categorize it as DoS/resource abuse even if the vector was injection.
11. Resilience over perfection. Answers emphasizing graceful degradation, redundancy and tested recovery reflect the NIST AI RMF resilience concept and are favored over answers implying all attacks can be blocked.
12. Read for the question's verb. Identify the risk, select the control, prioritize the response and report to stakeholders each call for a different kind of answer. Match the answer to the verb and to the stakeholder's level.
Quick Review Summary
• AI systems are disproportionately expensive per request, making availability and cost attacks attractive.
• Attack types: volumetric floods, sponge/resource-intensive inputs, context exhaustion, agentic recursion, denial of wallet, quota exhaustion, pipeline flooding, extraction via unbounded querying, infrastructure hijacking.
• Frameworks: OWASP LLM Top 10 (Model DoS / Unbounded Consumption), MITRE ATLAS (Denial of ML Service, Cost Harvesting), NIST AI RMF (Secure and Resilient), ISO/IEC 42001 and 23894.
• Controls: authentication, rate limits, input/output/context caps, tool-call and recursion limits, timeouts, circuit breakers, spending caps, monitoring of cost and latency, graceful degradation, incident playbooks, vendor SLA governance.
• Exam mindset: think risk-based, layered, governance-aware; recognize low-volume high-cost attacks; treat uncontrolled spend as a security issue; prefer bounded resource allocation over unlimited autoscaling.
Test mode:
AAISM - Denial of Service and Resource Abuse Against AI Example Questions
Test your knowledge of Denial of Service and Resource Abuse Against AI
Question 1
An enterprise offers a large language model (LLM) assistant through a public API. Monitoring shows that a few client accounts repeatedly send very long prompts that ask for maximum-length responses. Inference costs are rising, and other users see slower service. The content of the requests appears benign. Which control should the information security manager implement to BEST address this risk?
Question 2
An enterprise's agentic AI assistant keeps every user within per-user request rate limits. Monitoring still shows compute costs and response latency spiking. Log review finds a small number of crafted requests. Each one causes the agent to re-plan and call its tools repeatedly, consuming very large token volumes per request. Which control gap does this analysis MOST indicate?
Question 3
In adversarial machine learning, what are sponge examples designed to do when submitted to a deployed AI model?
Unlock Premium Access
Advanced in AI Security Management
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 3073 Superior-grade Advanced in AI Security Management practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- AAISM: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Denial of Service and Resource Abuse Against AI questions
21 questions (total)
Other AI Risk Management concepts
Accountability for Vendor AI Outcomes and IncidentsAdversarial Examples and Evasion AttacksAI Bill of Materials and Component TransparencyAI-Enabled Attacks: Phishing, Deepfakes and MalwareAI Impact Assessments and Regulatory ConformityAI Red Teaming and Adversarial TestingAI Risk Management Life Cycle and Enterprise RiskAI Risk Register and Risk ReportingAI Risk Treatment: Mitigate, Accept, Avoid, TransferAI Vendor Due Diligence and Security AssessmentBias, Fairness and Discrimination RiskContinuous Monitoring of the AI Threat LandscapeData Poisoning and Training Data ManipulationData Usage, Training Rights and Confidentiality ClausesEmbedded AI Features in SaaS and Vendor ProductsExit Strategy and Lock-In for AI ServicesFoundation Model and API Provider DependenciesFourth-Party and Concentration Risk in AI ServicesHallucination and Output Reliability RiskIdentifying AI Risk ScenariosInherent and Residual Risk of AI SystemsInsecure Output Handling and Excessive AgencyLegal, Reputational and Compliance Risk From AILikelihood and Impact Analysis for AI RiskModel Drift and Performance Degradation RiskModel Extraction, Inversion and Membership InferenceMonitoring Triggers for AI Risk ReassessmentOngoing Vendor Monitoring and Right to AuditOpen-Source Models, Datasets and Component RiskPrompt Injection and Jailbreak AttacksRisk Appetite, Tolerance and Thresholds for AIRisk of Agentic AI and Autonomous Decision SystemsRisk of Generative AI and Large Language ModelsRisk Ownership and Acceptance for AI SystemsSecurity Requirements in AI Contracts and SLAsSensitive Information Disclosure From AI SystemsShadow AI Procurement and Unsanctioned ToolsSupply Chain Attacks on Models and ComponentsThe AI Threat Landscape and Threat ActorsThreat Intelligence for AI SystemsThreat Modeling for AI SystemsVendor Model Updates and Change NotificationVerifying Vendor AI Security Claims and AttestationsVulnerability Management and Patching for AI ComponentsVulnerability Scanning and Penetration Testing of AI