It is past midnight, and I am sitting in the cockpit with the anchor light on and the laptop open, scrolling through what I have written. Eleven chapters, ten threat models, and somewhere around forty thousand words about what AI did to the assumptions our tools were built on. And the question I keep coming back to is the one I would ask if I were reading this instead of writing it: what do I actually do first?
Set aside what sounds good in a board presentation or what a vendor says you need. What do you do Monday morning with two analysts, a SIEM nobody has time to tune, and a budget that got cut 15% because the PE firm wants to see margin improvement this quarter?
This chapter is the answer. It is a prioritization framework built from the ten threat models in this series, organized around what gives you the most defensive coverage for the least effort and the smallest spend. It is also an honest accounting of what you cannot do, what you should not try to do all at once, and what happens when you get it wrong.
The Pattern Underneath the Threat Models
Every chapter in this series told the same story with different characters. A set of security tools that worked for twenty years stopped working because AI removed a specific constraint that those tools relied on to function. The constraint was always economic.
Your email gateway relied on the constraint that producing grammatically perfect, contextually appropriate, personalized phishing at scale was too expensive for most adversaries. Your EDR relied on the constraint that generating novel evasive payloads required enough time and specialized skill to keep the volume manageable. Your SIEM relied on the constraint that reconnaissance generated enough noise to cross detection thresholds. Your DLP relied on the constraint that exfiltration required moving recognizable data through recognizable channels. Your identity verification relied on the constraint that credentials and biometrics were hard to forge. Your incident response procedures relied on the constraint that attackers paused between phases long enough for your analysts to react.
AI collapsed every one of those economic constraints at roughly the same time. It did so by making existing techniques cheap enough to run at a scale and speed your defenses were never designed to handle.
The tools still work, but the cost model they were calibrated against no longer exists, and that tells you where to put your effort. You are recalibrating your security stack for an adversary whose operational costs dropped by an order of magnitude while your detection logic stayed priced for the old economy.
The Foundational Build: Behavioral Baselines from Existing Data
If you read all ten threat chapters and noticed one augmentation showing up again and again, you noticed the right thing. Behavioral baselining is the single highest-value capability you can build because it feeds into nearly every other defensive augmentation in this series.
Chapter 2 used communication baselines to detect social engineering that carries no malicious payload. Chapter 5 used behavioral baselines of AI service usage to find shadow AI and conversational exfiltration. Chapter 6 used baseline patterns to detect data integrity attacks where the changes look mechanically authorized. Chapter 8 made the full case for baselining from neglected log sources. Chapter 10 used authentication behavior baselines to detect credential attacks that present perfect forgeries. Chapter 11 used correlated behavioral signals to compress the defensive decision loop against attackers who no longer pause between kill chain phases.
Six of the ten threat chapters rely on the same foundational capability. Build it once, and you have infrastructure that serves more than half the defensive augmentations in this series.
The build itself is not complicated. Pull 90 days of log data from the sources your organization already collects: email metadata, authentication logs, DNS queries, proxy logs, endpoint telemetry. For each user and each system, compute rolling statistics that describe what normal looks like. Who talks to whom. When people log in and from where. What services get queried and how often. What processes run on which machines at which times. Feed incoming events against those baselines and flag deviations that cross a threshold you define.
The AI component earns its place in two specific ways. First, an LLM can take a cluster of deviations that individually mean nothing and assess whether the combination is meaningful. A single unusual login is noise. An unusual login from a new device at an odd hour, followed by access to a file share the user has never touched, followed by a DNS query to a domain registered last week, is a story. An analyst looking at each event in a queue would need to connect those dots manually across three different dashboards. An LLM reading all three in a single prompt can make the connection in seconds. Second, an LLM can generate the alert narrative that tells your analyst why this cluster matters, in plain language, so the analyst spends their time deciding what to do about it instead of figuring out what happened.
Start with your highest-risk users. Anyone who can authorize payments, approve access, or change vendor banking information. Build their baselines first. Expand from there as the system proves itself.
The cost is API calls and engineering time. The data already exists in your infrastructure. The output is a ranked list of behavioral anomalies, refreshed daily, with enough context for an analyst to triage each one in minutes instead of hours.
If you build nothing else from this series, build this.
The First Ninety Days
Prioritization means sequencing, and sequencing means accepting that some threats go unaddressed while you build the capability to address others. That is uncomfortable, and it is also the reality of running a security program with finite people and finite money.
This ordering balances coverage, feasibility, and the dependencies between augmentations.
Weeks one through four: Stand up the behavioral baseline engine. Pull your log data into a normalized store. Start with authentication logs, email metadata, and DNS queries. Compute rolling baselines for your highest-risk users and your most sensitive systems. Build the anomaly scoring pipeline. Run it in observation mode. Do not alert on anything yet. The first month is calibration. You are learning what your organization’s normal actually looks like, and you are finding out which of your data sources are clean enough to trust and which need work before they are useful.
During this same period, run the self-reconnaissance exercise from Chapter 3. Set up the script chain that replicates an adversary’s OSINT collection against your own organization: certificate transparency, subdomain enumeration, Shodan or Censys queries, job posting analysis, GitHub exposure checks, breach database lookups. Feed the output to an LLM and ask it to produce a prioritized attack plan from the adversary’s perspective. Compare that attack plan against what your EASM tool reports. The delta between those two outputs is your exposure gap, and closing it does not require AI. It requires patching, decommissioning, and configuration changes your team can execute immediately.
Weeks five through eight: Turn on alerting for the behavioral baseline and build the shadow AI inventory. After a month of calibration, you have enough data to know what your false positive rate looks like. Set your initial thresholds conservatively. You want your analysts to trust the system, and that means the first alerts they see need to be worth investigating. You can tighten the thresholds later. Better to miss some early signals than to train your team to ignore the output.
In parallel, build the AI service inventory from Chapter 5. Query your DNS logs and proxy logs for traffic to known AI service domains. Map which users are sending data to which services. Cross-reference against your approved tool list. The gap between those two lists is your shadow AI exposure, and knowing it exists is the first step toward governing it. Most organizations that run this exercise for the first time discover somewhere between three and ten AI services they did not know their employees were using with company data.
Weeks nine through twelve: Integrate the augmentations that build on the baseline. Once your behavioral baseline is generating useful output, you can layer on the more specific augmentations. Add the communication linguistic analysis from Chapter 2 to your email pipeline. Add the identity behavior scoring from Chapter 10 to your authentication monitoring. Add the cross-source correlation from Chapter 11 to your incident response workflow.
Each of these augmentations connects to the same baseline infrastructure. They are modules that plug into the engine you built in month one. Because you built the foundation first, every subsequent augmentation is cheaper and faster because the data plumbing already exists.
What You Do Not Build First
Two capabilities from this series are important but should not be in your first build cycle.
The AI-assisted code review and supply chain monitoring from Chapter 9 requires a level of engineering maturity and CI/CD pipeline instrumentation that most small and mid-sized companies need to develop before the AI layer adds value. If your organization does not already have a software composition analysis tool running against your builds, adding AI analysis on top of an unmonitored pipeline gives you sophisticated analysis of a process you are not watching. Build the monitoring first. Add the AI layer when the pipeline is instrumented.
The automated containment engine from Chapter 11 is the highest-value augmentation in the series for organizations that have the prerequisites. Those prerequisites are a complete service account inventory, a well-tuned EDR deployment, and a tested incident response process that your team has run through at least twice. Enabling automated endpoint isolation or credential revocation without those prerequisites will cause an outage that your management team will remember much longer than they remember the threat it was designed to prevent. The prototype path described in Chapter 11 is right: start read-only, tune for two weeks, enable the least disruptive action first, and expand from there. But start it in quarter two, not quarter one.
The Dependency Risk You Are Building
Chapter 7 exists for a reason. Every augmentation in this series creates a dependency your team did not have before.
Your behavioral baseline requires a data pipeline that collects, normalizes, and processes logs on a continuous cycle. If that pipeline breaks, your anomaly detection goes blind. Your LLM-powered analysis requires API access to a cloud service that charges per token. If the API goes down during an incident, your analysts lose the correlation capability at the worst possible moment. If an adversary figures out how to spike your API costs, your defensive capability has a price they can manipulate. If your analysts grow accustomed to LLM-generated alert narratives and stop reading raw logs, your team’s manual analytical skills atrophy. When the LLM is unavailable, they will be slower and less effective than they were before you deployed it.
None of that is a reason not to build these capabilities. All of it is a reason to build them with the failure modes explicitly planned for.
Every augmentation in this series includes a manual fallback. Those fallbacks are the load-bearing walls of the program. The AI layer accelerates what your team can do. The manual fallback ensures your team can still function when the acceleration is unavailable. If you skip the fallback planning, you have not built a capability. You have built a single point of failure with a monthly API bill.
Three practices make the dependency manageable. First, run a local model for your most critical analytical functions. Chapter 7 walked through the engineering for this. A quantized open-weight model running on a machine your team controls will not match a frontier API’s capability, but it will keep your core correlation and alerting functions alive when the API is unreachable. Second, schedule a monthly exercise where your team runs the analytical workflow manually, without the AI layer, on a real day’s worth of alert data. The exercise tests your team. If they cannot do the work without the tool, the tool owns your program. Third, set budget circuit breakers on your API spend. A hard cap that suspends non-critical API calls when spending exceeds a threshold you define. An adversary who can make your AI defense too expensive to run has found a novel denial of service against your security program.
What This Series Did Not Cover
Three areas fell outside the scope of this series and deserve acknowledgment.
This series did not address AI governance. It did not tell you how to write an acceptable use policy for generative AI, how to evaluate AI vendors, how to classify AI systems by risk tier, or how to comply with the EU AI Act. The NIST AI RMF, ISO 42001, and the EU AI Act address them. The reason this series did not cover governance is that the governance space is well-populated with competent guidance, and the operational space is not. The two are complementary, not competing.
This series did not address AI safety in the research sense. Alignment, interpretability, adversarial robustness of large language models, jailbreak resistance, and the frontier model safety debate are active research areas with important implications for security practitioners. They are also problems that a CISO at a 200-person company cannot solve and should not try to solve. What a CISO can do is understand the practical implications of those problems for the specific AI tools deployed in their environment, and this series addressed those implications where they intersected with each threat model.
This series did not address the organizational and political challenges of building an AI-augmented security program. Getting budget approval, justifying headcount, convincing a board that a Python script calling an LLM API is a legitimate security investment, managing the anxiety that AI-powered tools create among staff who worry about being replaced. Those challenges differ for every organization, and generalizing about them would have produced the kind of hand-waving this series tried to avoid.
The Honest Assessment
If you build everything described in this series, you will not be protected against a well-funded adversary who specifically targets your organization with a sustained, multi-phase campaign designed to defeat your defenses. No single company’s security program protects against that threat. That is what intelligence agencies and law enforcement exist for, and even they struggle.
What you will have is a security program that is materially harder to compromise at scale. The augmentations in this series are designed for the most common threat model: automated and semi-automated attacks that compress the kill chain against hundreds or thousands of targets simultaneously, where the adversary’s advantage is speed and volume, not bespoke capability directed at you specifically.
Most breaches of small and mid-sized companies are not the work of APT groups running custom toolchains. They are the work of criminal operators running fast, scalable playbooks against whichever targets present the lowest resistance. AI made those playbooks faster, cheaper, and more convincing. The augmentations in this series make your organization harder to breach with those playbooks than the organization next door. In the economics of opportunistic attack, that difference matters.
Only 11% of small and mid-sized businesses had adopted AI-powered defenses in CrowdStrike’s 2025 survey, even though 93% said they understood their cybersecurity risk. The gap between awareness and action is where breaches live. The organizations that close that gap in the next twelve months will be positioned fundamentally differently from those that wait for a vendor to package these capabilities into a product and sell it back to them at enterprise pricing.
You have the logs. You have API access to models that cost pennies per query. You have the series in front of you with specific build instructions for each augmentation. What you build with those materials in the next ninety days determines whether your security program is calibrated for the adversary you actually face or the adversary you faced five years ago.
Start Monday.
Works Cited
CrowdStrike. (2025, May 5). CrowdStrike unveils State of SMB Cybersecurity Report: High awareness, lagging protection [Press release]. https://www.crowdstrike.com/en-us/press-releases/crowdstrike-unveils-smb-cyber-report-highlighting-protection-gaps/
About the Author
