AI in Security Operations: The Landscape

0.1 What the AI security landscape is

Module 0 demonstrated AI-assisted investigation through a real AiTM case study and established the five-check validation discipline. You saw Claude generate queries, watched four succeed and one fail, and identified the scope gap that AI missed. That demonstration proved the value. This module explains the mechanics behind the value and the failure — what the technology actually does, where it fits across your security operations functions, what the standards bodies say about governing it, and how to evaluate the growing market of AI tools competing for your budget and your data.

The distinction between marketing and capability is the central problem. Every security vendor now claims AI-powered products. Most are pattern-matching classifiers with a marketing label. Genuine LLM capabilities — the ones that compress investigation timelines and generate detection rules from advisories — are transformative when deployed with validation discipline and dangerous when deployed without it. The five failure modes you learned in C0.2 are not implementation bugs. They are architectural properties of how language models generate output. Understanding the architecture explains why the failures are predictable and why the five-check validation catches them.

This module produces five artifacts: a capabilities matrix mapping AI to your SOC functions, an annotated framework reading list, a vendor evaluation template, a data classification matrix, and your operational AI foundation with methodology and measurement. Each artifact is operational — you deploy them, not file them.

0.2 What you will learn

Six sections building the intellectual and operational foundation for every module that follows.

Section 1.1 — What AI Actually Does (and Does Not Do). Three categories of "AI" in security products — rule-based systems, traditional ML, and large language models. How LLMs work at the level a security practitioner needs: token prediction, context windows, training data cutoffs, temperature and non-determinism. Why hallucinations are architectural, not bugs. The five hallucination patterns in security contexts with the specific verification method for each.

Section 1.2 — The AI Capabilities Matrix for Security Operations. AI mapped to six core SOC functions: alert triage, investigation, detection engineering, incident response documentation, compliance, and automation. Each function scored on AI effectiveness, verification overhead, and risk profile. The investigation feedback loop methodology — the core operational pattern for C2 through C10.

Section 1.3 — The AI Security Literature — What the Standards Bodies Say. Five frameworks that define the governance landscape: NIST AI RMF 1.0 (with GenAI Profile and the April 2026 Critical Infrastructure concept note), OWASP LLM Top 10 v2.0 (2025 edition with agentic AI risks), MITRE ATLAS v5.1.0 (16 tactics, 84 techniques for adversarial AI), SANS Secure AI Blueprint, and the EU AI Act. Each framework mapped to the specific operational question it answers.

Section 1.4 — Evaluating AI Tools for Security Operations. Structured evaluation across five dimensions: capability fit, data handling, integration, cost, and governance readiness. Applied to the current tool landscape including Claude, ChatGPT, Copilot for Security, Gemini, and embedded vendor AI. The vendor evaluation template you use for every tool assessment going forward.

Section 1.5 — Data Handling, Privacy, and Operational Security. What happens to your data by platform and plan tier. The data classification matrix — what security data can be processed by which tools on which plans. Shadow AI detection: the KQL query that finds unauthorized AI usage in your environment. Regulatory considerations for AI data processing under GDPR, CCPA, and sector-specific requirements.

Section 1.6 — Building Your AI Operations Foundation. The investigation feedback loop as a repeatable methodology. Prompt library architecture. Measurement framework — how to quantify whether AI is making your team faster or just busier. The operational readiness checklist for C2 through C10.

0.3 Why Claude is the right platform for AI security operations

Claude handles the mechanical parts of security work — query drafts, cross-table correlation, report structure, script scaffolding — because these tasks share a common pattern: they are verifiable against an external reference. A KQL query either references real tables and fields or it does not. A detection rule either matches the intended technique or it does not. A report either traces every claim to investigation evidence or it does not. The verification step is what makes AI assistance safe, and the verification step is fast.

Claude Projects give you persistent context that carries across every conversation. Your SIEM platform, EDR product, query language, output formatting requirements, and organizational conventions — specified once, inherited by every conversation in the Project. Without a Project, you re-explain your environment in every session. With a Project, every conversation starts with that context already loaded, eliminating the 2-minute context tax that compounds into hours over a working week.

The 200,000-token context window accommodates the large datasets security investigations demand. An analyst investigating an AiTM compromise pastes sign-in records, audit logs, inbox rule configurations, and email metadata into a single conversation. Claude correlates across all four datasets without the analyst segmenting the work across multiple sessions. For investigations that span 5 to 8 Sentinel tables and thousands of rows, context window size is not a theoretical advantage — it determines whether the analysis happens in one coherent pass or fragments across disconnected conversations.

Claude Code reads your project's CLAUDE.md file and generates every script following your coding standards from the first draft. For automation workflows, evidence collection scripts, and scheduled hunting queries, this means the first output matches your team's conventions rather than requiring reformatting. Claude Security scans repositories and generates patches. Connectors extend Claude's reach into Gmail, Google Drive, GitHub, and Slack. Each surface handles a different part of the security workflow, and the course teaches you which surface to use for which task.

0.4 How to get the best from this module

Sections 1.1 and 1.2 are the conceptual core. If you understand the LLM mechanics (why hallucinations happen, why context windows matter, why training cutoffs create blind spots) and the capabilities matrix (where AI adds value, where it requires heavy verification, where it should not be used), every subsequent module makes sense architecturally.

Section 1.3 is reference material. Read it once, annotate it, and return to specific frameworks when you need them. Module 7 (governance) references the frameworks extensively.

Sections 1.4 through 1.6 are operational setup. Complete the exercises — the vendor evaluation template and data classification matrix are artifacts you will use repeatedly.

Estimated time: 3 to 4 hours. Two sessions of 90 minutes each is typical.

0.5 Module structure

• Section 1.1 — What AI Actually Does (and Does Not Do)
• Section 1.2 — The AI Capabilities Matrix for Security Operations
• Section 1.3 — The AI Security Literature — What the Standards Bodies Say
• Section 1.4 — Evaluating AI Tools for Security Operations
• Section 1.5 — Data Handling, Privacy, and Operational Security
• Section 1.6 — Building Your AI Operations Foundation

Prerequisite: Module 0 (Course Introduction). The five-check validation discipline from C0.2 is applied throughout this module.

Go to Section 1.1 — What AI Actually Does (and Does Not Do) to begin.