How AI Changes Cybersecurity Work

Four dimensions of change

AI transforms security operations along four dimensions. Each changes a different aspect of how you work, and each carries a different risk profile.

Speed of analysis. A security analyst investigating an account compromise manually queries sign-in logs, checks MFA status, reviews recent email activity, examines file access patterns, and cross-references with threat intelligence. Each step requires navigating a portal, writing a query, waiting for results, and interpreting output. With AI assistance, the analyst describes the investigation context and AI generates the queries, structures the analysis, and highlights anomalies. The same investigation completes in a fraction of the time.

Consider the concrete difference. An AiTM alert fires for a user. Manually, you open five browser tabs, write four KQL queries from memory, wait for each to return, cross-reference the IP against two TI sources, check the user's group memberships for VIP status, and document your findings. That sequence takes 15 to 25 minutes for an experienced analyst. With AI, you paste the alert details into a structured prompt and receive the four KQL queries pre-written for your workspace, the TI enrichment summarized, and a draft investigation narrative. You verify the queries against your schema, run them, and compare AI's summary against the raw results. The same investigation takes 8 minutes, with 5 of those minutes spent on the verification that makes the output trustworthy.

But speed without verification is speed toward errors. The analyst's expertise remains essential for the judgment call: is this anomalous pattern actually malicious, or is there a benign explanation that AI cannot evaluate because it lacks environmental context?

Scale of coverage. A detection engineer maintaining 30 rules spends most of their time on maintenance: tuning false positives, updating for schema changes, documenting rules, testing after platform updates. AI assistance allows the same engineer to maintain those 30 rules and develop 10 new rules in the same time window. The AI drafts the rule from a threat advisory, generates the documentation, identifies likely false positive patterns, and produces the test cases. The engineer reviews, validates, and deploys. Coverage expands without headcount increase.

The risk is that expanded coverage without expanded verification produces rules that look correct in development and fail in production because the AI used a field name from a different table or a function that does not exist in your KQL environment. A rule that references DeviceExecutionEvents instead of DeviceProcessEvents passes visual inspection because the name is plausible. It fails silently in production because the table does not exist. The validation discipline catches this before deployment.

Quality of documentation. Incident response documentation is universally acknowledged as important and universally neglected under operational pressure. Writing a formal executive summary, a technical timeline, a regulatory notification assessment, and stakeholder communications takes hours that analysts do not have during active incidents. AI compresses this: the analyst provides investigation notes, and AI generates structured documentation in the appropriate format for each audience. A report that took 3 hours manually takes 30 minutes with AI assistance. The consistency improves because AI applies the template structure reliably.

The risk is that AI-generated documentation contains plausible-sounding claims that are not grounded in the investigation evidence. A regulatory assessment that cites the wrong GDPR article, a timeline that transposes two events, or an executive summary that overstates the scope of compromise. Each damages credibility if the analyst does not catch it during review.

Accessibility of specialized knowledge. Compliance frameworks, regulatory requirements, and governance standards are specialized domains. A security analyst who is expert in investigation may have limited knowledge of GDPR notification requirements, the NIST AI Risk Management Framework, or PCI DSS scope determination. AI bridges this gap: the analyst describes the situation, and AI applies the relevant framework. This does not replace compliance expertise. It makes specialized knowledge accessible to practitioners who would otherwise need to research from scratch or wait for a specialist who is not available at 2 AM during an active incident.

The five failure modes

AI output fails in predictable ways. Each failure mode has a specific validation check. Learning these five checks is the foundation of the validation discipline taught in C1 and applied in every subsequent module.

Hallucinated references. AI invents tool names, cmdlet parameters, API endpoints, and event IDs that do not exist. A KQL query that references DeviceProcessEvents is correct. A query that references DeviceExecutionEvents looks correct but targets a table that does not exist in any Microsoft Sentinel or Defender workspace. The hallucination is not random. It is plausible, which makes it dangerous. The table name follows the naming convention. A reviewer who checks syntax but not schema will pass it. The check: verify every table name, field name, and function against the actual schema in your workspace before running the query.

Outdated syntax. AI training data includes deprecated APIs, retired cmdlets, and superseded configurations. A PowerShell script that uses Get-MsolUser looks functional but references a module Microsoft deprecated in 2023 in favor of Get-MgUser in Microsoft Graph PowerShell. An AI generating Defender for Endpoint queries might use AlertInfo instead of the current AlertEvidence table if its training data predates the schema migration. The check: verify that the commands, modules, API versions, and table names are current as of your deployment date. Microsoft's deprecation timelines are documented, and outdated references in AI output are common because training data lags reality by months.

Confident-but-wrong analysis. AI produces investigation conclusions that sound authoritative but do not follow from the evidence. An AI that states "the attacker is likely affiliated with FIN7 based on the observed TTPs" when your investigation identified the technique but not the actor is generating fabrication, not analysis. The check: every factual claim in AI-generated analysis must trace to specific evidence from your investigation. If it does not, delete it.

Incorrect logic. AI generates queries and rules with filter conditions that do not match the intended detection. A rule designed to detect impossible travel that filters on ResultType == "0" (successful sign-ins) will miss the attack pattern if the attacker's sign-in was blocked by Conditional Access: the interesting signal is the attempt from an anomalous location, regardless of result. Similarly, a query intended to find all failed MFA challenges might filter on AuthenticationRequirement == "multiFactorAuthentication" but miss the cases where MFA was not even prompted because Conditional Access evaluated the sign-in as trusted. The check: read the query logic against the detection hypothesis. Does the filter include what it should and exclude what it should not? Walk through the logic with a specific attack scenario and verify the query would return the attacker's activity.

Context leakage. AI carries context from previous conversations or training data into the current task. A prompt that asks for a KQL rule to detect lateral movement might receive a rule that references a Splunk index because the AI's training data contains more Splunk examples than KQL for that technique. More subtly, AI might generate a query that uses field names from a different Microsoft product. DeviceEvents fields in a query targeting SigninLogs, for example, because the AI merged schema knowledge from two different contexts. The check: verify that the output matches your specific platform, environment, and tool stack. Start new conversations for new tasks to minimize cross-contamination from earlier prompts.

What AI does not change

AI does not replace professional judgment. An AI can identify that a sign-in from a hosting provider IP is anomalous. It cannot determine whether that anomaly matters in your context, whether the user is traveling, using a corporate VPN with a shared exit node, or genuinely compromised. That decision requires understanding of your environment, your users, and your threat model. AI provides analysis, pattern recognition, and structure. You provide professional judgment and environmental context that AI systems cannot access independently. The distinction matters most during active incidents where the pressure to act fast tempts practitioners to trust AI conclusions without verification.

AI does not eliminate the need for domain expertise. An analyst who does not understand investigation methodology will not produce better investigations with AI; they will produce faster, equally flawed investigations. AI amplifies existing competence. If you understand detection engineering, AI makes you a faster, more productive detection engineer. If you do not, AI gives you a tool you cannot effectively evaluate. This is why the course requires security operations experience as a prerequisite. The AI techniques taught here assume you already know how to investigate, how to write detection rules, and how to assess risk. The course teaches you to do those things faster and at greater scale.

AI does not reduce the need for operational discipline. When AI makes it possible to generate a detection rule in 5 minutes instead of 5 hours, the temptation is to skip testing, documentation, and peer review. The organizations that treat AI as a shortcut to bypass governance introduce more errors than they eliminate. Every module in this course includes the review and validation steps that maintain quality alongside speed.