A little while ago, I was navigating up the ICW between the markers. The channel is about 100 feet wide, and my boat is about 50 feet long and 15 feet wide. You’d think that’s plenty of room, but it isn’t. I was relying on the autopilot while I futzed with some lines, getting ready to dock at a nice little out-of-the-way marina. Traveling at about 6 knots, with zero wake and autopilot engaged, you’d think there’d be no problem. But a few degrees off translates into a lot of lateral movement. A small miscalibration- literally just the calibration level- and we’re sliding toward a rapid, muddy stop. I’m not drunk on sunshine like the guys on jet skis, and I get things under control. Dependency, though, is a big deal, and the autopilot, as sophisticated as it is, can still steer toward trouble.
The autopilot is a tool I own and operate. Every setting was put in there by me, and a push of wind, a wake from a trawler, and that outside impetus in critical places can be catastrophic. What’s at stake if I don’t use the autopilot? Exhaustion, what we call sea blindness, where you just get tired and zone out, seeing but not seeing. We see the same things with AI, and just like with too much reliance on the autopilot, we can have huge issues with AI becoming a dependency without a backup plan. I have three input strategies for my autopilot. I wear a remote around my neck, I have two dedicated AI remote pads, and the chart plotters all allow me to operate the autopilot. If something fails in the larger system, I can bring everything down to just the autopilot with no other instruments involved. The principle is resilience.
That’s the frame for this chapter, because it asks a question the rest of the series has been building toward: what happens when the AI you depend on for defense is the thing that fails?
Threat Model
Every chapter in this series has described an adversary whose economics changed because AI removed a constraint. This chapter turns that lens inward. The threat here is not a smarter attacker. The threat is the failure, degradation, or deliberate compromise of the AI systems your defense now depends on.
That failure takes several forms, and each one exploits a different assumption your security program makes about availability.
Provider outage or API disruption. Your cloud-hosted AI analysis, whether it is an LLM-based triage layer, an AI copilot in your SIEM, or a managed detection service running behavioral models in a vendor’s cloud, depends on someone else’s infrastructure staying up. Cloud providers have outages. In July 2024, a single faulty CrowdStrike content update took down 8.5 million Windows systems worldwide, grounding flights, shutting down hospitals, and disabling emergency call centers. That was not an AI failure per se, but it showed what happens when a security tool with deep system access goes wrong at scale. The Fortune 500 impact alone was estimated at $5.4 billion in direct losses. Now extend that to AI-dependent analysis layers that run entirely in a vendor’s cloud. When the API returns errors, your triage stops.
Cost-based exhaustion. Cloud AI services bill per API call, per token, or per compute cycle. An adversary who understands your architecture can trigger analysis loops that burn through your budget. This attack has a name: Economic Denial of Sustainability, or EDoS. The attacker doesn’t need to take your systems offline. They just need to make your AI layer too expensive to keep running. In the first half of 2025, Indusface measured a DDoS attack rate against each API host six times higher than against websites, and Cloudflare reported that 89% of network-layer and 75% of HTTP DDoS attacks in the first quarter of 2025 ended within 10 minutes, before manual response teams could even act. Apply that pattern to an AI analysis API with per-request billing, and the math gets ugly fast.
Attacker-initiated islanding. An adversary who has already achieved some foothold can cut your defensive AI off from the resources it needs. If your AI analysis layer requires cloud connectivity and the attacker controls DNS, routing, or firewall rules on a compromised segment, they can island your defenses before executing the payload. Your EDR agent phones home for behavioral analysis. The attacker blocks that communication. The agent falls back to local signatures. The attacker’s payload was designed to evade signatures and rely on behavioral detection never arriving.
Adversarial manipulation of detection models. Your AI-based detection is a model. Models can be attacked. Evasion attacks modify the input so a trained model reads a malicious file as benign. The attacker doesn’t touch the model itself. They modify what the model sees. Malware authors are already doing this against ML-based EDR products, making small changes to file signatures or execution patterns that slip past the classifier. Data poisoning is slower but deeper: if an attacker can influence training data, whether through open-source intelligence feeds your model consumes or through community-sourced threat intelligence, they can shift decision boundaries over time without anyone noticing. In early 2026, Antiy CERT confirmed at least 1,184 malicious skills in ClawHub, the OpenClaw agent skill marketplace, uploaded through typosquatting and mass upload campaigns, and Bitdefender’s separate count put roughly one in five skills in the expanded registry as malicious.
Skills atrophy. As AI handles more triage, more correlation, more investigation, the analysts who used to do that work lose the ability to do it manually. A 2026 comparative case study of resource-constrained SOCs in emerging markets reported that junior analysts in high-AI-maturity environments showed a mean 23% decline in manual log analysis proficiency. Senior analysts with proper human-in-the-loop governance held steady or improved slightly, but the junior population is the bench. They’re the ones who need to take over when the AI goes down. If they can’t read a raw log and tell you what happened, your AI outage becomes a skills crisis on top of a technology failure.
The adversary this chapter models is not necessarily external. The failure mode can be a provider going down, a budget getting blown, an attacker cutting network paths, an adversary gaming your detection models, or simply time eroding the skills your team used to have. What all five scenarios share is a single operational fact: your AI defense layer is unavailable, and you have no practiced plan for what comes next.
Traditional Tools
Before AI entered the security stack, organizations built resilience into their defense infrastructure through straightforward engineering principles. A competent CISO who built a security program five years ago would have addressed availability of security tools through several categories of planning.
Redundancy and failover for core security infrastructure. Firewalls deploy in high-availability pairs. SIEM platforms run on clustered infrastructure with failover nodes. EDR agents maintain local detection capabilities even when management consoles are unreachable, falling back to cached signature sets and local heuristics. Network monitoring tools store data locally and forward when connectivity resumes. The assumption driving all of this: the tool itself might go down, so we need a second copy of the tool.
Disaster recovery and business continuity planning. Most mature security programs include their security infrastructure in the organization’s DR plan. SIEM data replicates to a secondary site. Firewall configurations are backed up and restorable. There’s a documented process for what happens when the primary SOC location is unavailable. These plans get tested annually, or at least they’re supposed to get tested annually. The 2024 CrowdStrike incident showed how many organizations hadn’t actually tested what happens when endpoint protection goes from “running everywhere” to “running nowhere” with no warning.
Incident response procedures. IR plans document escalation paths, communication trees, and containment procedures. The good ones include procedures for operating in degraded mode, where some tools are unavailable and the team falls back to manual analysis. The less good ones assume all tools will be available during the incident, which is a comfortable assumption right up until it isn’t.
Change management and rollback. Mature environments test security tool updates in staging before pushing to production. They maintain rollback procedures. They have change advisory boards that review updates to security infrastructure the same way they review updates to business applications. CrowdStrike’s Channel File 291 incident was, among other things, a failure in exactly this process: a content update pushed to production without adequate validation testing.
Skills and training programs. Some organizations invest in keeping their analysts sharp through tabletop exercises, purple team engagements, capture-the-flag competitions, and formal training budgets. The SANS 2025 SOC Survey found that a lack of skilled staff remains the top challenge SOCs report, and that 42% of SOCs use AI/ML tools out of the box with no customization. The training keeps the team able to do the fundamental work of reading logs, tracing network traffic, and building a narrative from raw data when the automated tools aren’t doing it for them.
These are real and necessary capabilities, but they were all designed for a specific type of failure: the tool itself crashes, or the infrastructure hosting the tool becomes unavailable. They were not designed for a failure where the intelligence layer on top of the tools disappears.
The Gap
The traditional resilience model works when what fails is a component. A firewall goes down, and the standby takes over. A SIEM node crashes, and the cluster absorbs the load. An EDR console becomes unreachable, and the agents continue with cached rules. The assumption embedded in all of this planning is that the component’s role is well-defined, the backup performs the same role, and a human operator can manage the gap between failure and recovery because the human understands what the component was doing.
AI broke that assumption in a specific way: it introduced a layer that performs cognitive work, not just data processing.
When a traditional SIEM fires an alert, an analyst looks at it, pulls supporting data, correlates events across sources, builds a theory, and decides whether this is real. That cognitive chain lives in the analyst’s head. The tools supply the data, while the human supplies the judgment. When one tool goes down, the analyst pulls data from another source and does the same cognitive work.
When an AI analysis layer handles triage, correlation, and preliminary investigation, that cognitive work moves into the AI. The analyst receives a prioritized, contextualized output: “This alert cluster represents credential stuffing against your VPN concentrator, correlated with a spike in failed MFA attempts from IP ranges associated with bulletproof hosting.” The analyst reviews the AI’s conclusion rather than building their own. The difference between those two workflows determines what happens during a failure.
In the first workflow, losing a tool means losing a data source. The analyst’s judgment is still there. In the second, losing the AI means losing the judgment layer itself. The analyst gets raw alerts, thousands of them, with no pre-built correlation, no prioritization, and no investigation context. If the analyst hasn’t been doing that work manually on a regular basis, they’re starting from scratch at the worst possible moment.
The specific constraints that traditional resilience planning relied on, which AI has removed:
The constraint that failures would be component-level, not cognitive-level. DR plans cover “the SIEM is down” with procedures for operating without it. They don’t cover “the thing that told you which alerts mattered is gone, and you now have 4,484 raw alerts to read before lunch.” That’s a different kind of failure with a different recovery profile.
The constraint that human skill would always be available as backup. Traditional planning assumes the team can always fall back to manual analysis. When AI handles most Tier 1 triage, which in my experience is where many teams are heading, the team’s manual triage muscle atrophies. The backup that’s supposed to catch you when automation fails is the same backup that automation has been slowly deconditioning. You can’t schedule a failover to a capability you no longer maintain.
The constraint that security tool failures would be accidental, not adversarial. Firewall failover handles hardware failure and software bugs. It doesn’t handle an adversary who specifically targets your AI analysis layer because they know blinding it gives them a window to operate. An attacker who understands that your behavioral detection runs through a cloud API can target that API path. An attacker who knows your AI model’s training data sources can poison those sources. The traditional resilience model didn’t account for an adversary whose attack plan includes “disable the victim’s AI first.”
The constraint that tool dependencies would be visible and auditable. You know your firewall depends on power, network connectivity, and its high-availability peer. Those dependencies are documented and monitored. Your AI analysis layer depends on API availability, model integrity, training data quality, compute budget, and vendor business continuity. Those dependencies are harder to map, harder to monitor, and harder to test. You might not discover a degraded model until it starts missing things it used to catch, and you might not discover that gap until the adversary exploits it.
The gap is not that traditional resilience tools are bad. The gap is that they were engineered for a world where tools process data and humans provide judgment. In a world where AI provides significant portions of the judgment, resilience planning needs to cover the judgment layer with the same rigor it covers the data layer.
AI Augmentation
This section reverses the usual pattern in this series. In every other chapter, AI augmentation means adding an AI layer on top of existing tools to close a gap. Here, the augmentation is architectural: designing the AI defense layer itself so that its failure is survivable, its integrity is verifiable, and the human team retains the ability to operate without it.
Local model deployment for islanding resilience. The most direct way to survive a cloud AI outage is to not depend entirely on cloud AI. Run a smaller, quantized model on hardware you control that provides basic triage capability when the cloud is unreachable, without trying to match your vendor’s cloud-hosted analysis on quality.
What this looks like in practice: a quantized open-weight model (Llama, Mistral, or similar) running on a dedicated machine with 24 to 48 GB of VRAM, tuned to accept SIEM alert data in a structured format and return priority classifications. The model doesn’t need to be brilliant. It needs to separate “probably worth looking at” from “probably noise” well enough that your team can focus their manual effort during an outage. In my experience, a local model running in an air-gapped environment catches much of what the cloud-hosted model catches, though not all of it. The drop in quality is real, but degraded operations beat no operations.
The implementation is a script that monitors your cloud AI analysis layer’s response time and error rate. When the error rate crosses a threshold or responses stop arriving, the script switches alert routing to the local model. When the cloud layer recovers, it switches back. The local model’s hardware requirements are modest enough that a single workstation can handle it. Quarterly, test the switchover by deliberately cutting the cloud connection during a scheduled window and processing live alerts through the local model for an hour.
Dependency risk for this augmentation: the local model itself becomes a single point of failure. If the hardware dies and no one has tested the switchover process recently, you’re back to no AI at all. Manual fallback: the local model’s output format should match the cloud model’s output format closely enough that analysts can use the same review workflow for both. If the local model also fails, the fallback is the analyst working raw alerts with the SIEM’s native correlation rules, which should remain active and maintained regardless of AI status.
Validation loops for AI output integrity. If an adversary poisons your detection model or manipulates its inputs, you need a way to notice. Build a validation loop that compares your AI detection layer’s outputs against independent baselines.
The simplest version: maintain a set of known-malicious samples and known-benign samples. Run them through your AI detection layer on a weekly schedule. If the classification accuracy on your validation set drifts below an established baseline, something has changed. That something might be a legitimate model update, or it might be adversarial interference. Either way, you want to know about it before you discover it during an incident.
A more complete version: log every AI triage decision alongside the raw alert data that produced it. Build a second, independent analysis path using simple rule-based logic, not AI, that classifies the same alerts on basic pattern matching. Compare the two outputs. When they disagree, a human reviews the disagreement. Over time, the disagreement rate itself becomes a metric. A sudden spike in disagreements means something changed in the AI layer’s behavior.
The data sources feeding this are your existing alert stream and whatever ground truth you can establish from confirmed incidents. The engineer building this writes a comparison script, a weekly validation runner, and a dashboard that shows the AI layer’s accuracy trend and disagreement rate over time. This is a few hundred lines of Python and a scheduled job.
Dependency risk: the validation loop itself runs code. If an attacker compromises the validation infrastructure, they can mask the very drift you’re trying to detect. Run the validation from a separate system with separate credentials. The manual fallback for this is periodic manual review of AI-triaged alerts, where an analyst pulls a random sample of AI-dismissed alerts weekly and checks whether the AI’s dismissals were correct.
Degradation-aware workflows. Your incident response procedures need a section titled “AI Unavailable” that isn’t aspirational. It needs to be tested.
Build three operating modes into your SOC procedures. Full AI: the current state, where AI handles triage, correlation, and preliminary investigation. Degraded AI: the local model is active, providing basic prioritization, but without the contextual depth of the cloud layer. Analysts do their own correlation. Manual: no AI assistance. Analysts work SIEM queries, raw log review, and their own judgment.
For each mode, document what changes. In degraded mode, the alert review threshold shifts: analysts review alerts the local model rates as medium or above, rather than only those the cloud model rates as high. Response timelines extend. Certain automated containment actions that rely on AI confidence scores require manual approval instead. In manual mode, the team falls back to predefined SIEM correlation rules, and the alert review scope narrows to the most critical asset classes.
The test for this: run a tabletop exercise quarterly where you declare the AI layer unavailable at the start and work a realistic scenario entirely in degraded or manual mode. Time how long investigation takes. Note where analysts struggle. Use the results to update the procedures and inform training priorities. This costs one afternoon per quarter. If you discover that your team can’t function in manual mode, you’ve learned something important while it was still a drill.
Dependency risk: documented procedures that nobody practices become false comfort. The risk is that the “AI Unavailable” playbook sits in a wiki and gathers dust while the team builds muscle memory exclusively on the AI-assisted workflow. The manual fallback is the exercise itself: if you run the exercise and it goes badly, that’s the signal to increase training frequency, not to abandon the exercise.
Training regimens that preserve manual analytical skills. This is the least technical augmentation in this chapter and maybe the most important. Early 2026 case study evidence suggests that junior analysts in AI-heavy SOCs lose manual proficiency measurably. The fix is deliberate practice, not just awareness.
Build a monthly “manual analysis hour” into the SOC schedule. During this hour, the AI layer is hidden from view for participating analysts. They work a set of pre-selected real alerts, not simulated ones, using SIEM queries, log analysis, and manual correlation. Their results are compared against what the AI produced for the same alerts. The comparison works as a calibration exercise that keeps the analyst’s manual skills sharp and also reveals cases where the AI got it wrong and the analyst caught it.
For new analysts, the first 90 days should include a period of manual-only analysis before they gain access to AI-assisted workflows. Let them build the foundational skills before they learn the shortcut. This mirrors how the aviation industry trains pilots: you learn to fly the airplane before you learn to manage the autopilot.
Dependency risk: training programs get cut when budgets tighten. Manual analysis hours get canceled when alert volume spikes. Protect this time the way you protect patching windows: as a scheduled, non-negotiable maintenance activity for your human infrastructure.
Budget monitoring and cost circuit breakers. If your AI defense layer runs on cloud APIs with usage-based billing, build an automated cost monitor that alerts and throttles when spend exceeds expected bounds. Set a daily and weekly budget ceiling. When the ceiling is hit, the system switches to the local model rather than continuing to burn cloud API credits.
This directly addresses the EDoS threat. An attacker who triggers analysis loops against your AI layer runs into a cost ceiling rather than an open checkbook. The throttle buys you time to investigate the spend anomaly while your local model maintains basic triage capability.
The build takes three pieces: your cloud provider’s billing API or the AI vendor’s usage API, a script that checks consumption against a threshold, and an alert that fires when consumption hits 80% of the daily ceiling. At 100%, the script triggers the same switchover mechanism described for outage resilience. You’re already building the switchover for outage handling. The cost monitor just gives it a second trigger.
Dependency risk: if the cost monitor’s threshold is set too low, legitimate high-alert-volume days hit the ceiling and degrade your detection during a real incident. Tune the thresholds using 30 days of baseline data and set them at two to three standard deviations above normal, not at a flat dollar figure divorced from actual usage patterns. The manual fallback: if the cost monitor itself fails, the billing alert from your cloud provider (which you should also have configured) serves as the backup notification.
Each of these augmentations follows the same principle from the vignette at the top of this chapter. The autopilot is a tool I own and operate, and I have three independent ways to control it, plus the knowledge and muscle memory to steer manually if every one of those three fails. I call that seamanship. The AI layer in your security stack deserves the same engineering discipline.
Works Cited
Antiy CERT. (2026). ClawHavoc: Analysis of large-scale poisoning campaign targeting the OpenClaw skill market for AI agents. https://www.antiy.net/p/clawhavoc-analysis-of-large-scale-poisoning-campaign-targeting-the-openclaw-skill-market-for-ai-agents/
Boamah, K. G. (2026). AI-driven threat intelligence adoption in security operations centers: Human skill erosion or analyst augmentation? International Journal of Science and Research Archive, 19(3), 25–33. https://doi.org/10.30574/ijsra.2026.19.3.1226
Cloudflare. (2025). DDoS threat report for 2025 Q1. https://radar.cloudflare.com/reports/ddos-2025-q1
Crowley, C. (2025). SANS SOC survey 2025. SANS Institute. https://www.elastic.co/pdf/sans-soc-survey-2025.pdf
Indusface. (2025). State of application security, H1 2025. https://webinars.indusface.com/web-api-threat-trends-2025-h1/registration
SANS Institute. (2025, September 9). SANS 2025 SOC survey exposes critical gaps and what top teams are doing right [Press release]. https://meatechwatch.com/2025/09/09/sans-2025-soc-survey-exposes-critical-gaps-and-what-top-teams-are-doing-right/
SecurityWeek. (2024, July). 97% of devices disrupted by CrowdStrike restored as insurer estimates billions in losses [Reporting Parametrix estimate]. https://www.securityweek.com/97-of-devices-disrupted-by-crowdstrike-restored-as-insurer-estimates-billions-in-losses/
Vectra AI. (2023). 2023 state of threat detection. https://vectra.ai/resources/2023-state-of-threat-detection
About the Author
