Anwer Gertani

The Cyber Desk

The Policy-Driven Security Operation: What It Looks Like When You've Arrived

April 5, 2026 · Anwer Gertani

AI / MLSecurity OperationsLeadership

The operations centre becomes a policy centre. Analysts become policy authors. The CISO becomes a policy architect. AI runs the operation. Humans make it better.

This is Post 7 of 7 in the series “Building Security Operations That AI Can Run.” Read from Post 1 to follow the full argument.

A security operation that has completed the journey described in this series looks different from the outside and feels different from the inside. From the outside: faster detection times, lower breach costs, higher analyst retention, and a programme that improves continuously rather than degrading between technology refresh cycles. From the inside: analysts spending their time on genuinely complex problems rather than mechanical triage, IR leads focused on adversary behaviour rather than coordination overhead, Threat Intel producing actionable outputs rather than unread reports. The metrics that show up in IBM’s Cost of Data Breach Report — organisations with AI and automation detecting and containing breaches 98 days faster, saving $1.9 million per incident — describe the outcome of this journey, not a specific technology purchase.

The daily operational rhythm organises into a continuous improvement cycle. Each time a novel case escalates from Layer 1 to Layer 2, gets decided by a human, and flows through Threat Intel back into updated policy, Layer 1’s authority boundary expands. The next similar case is handled automatically. That compounding is the flywheel.

The policy flywheel — every full rotation expands Layer 1's authority boundary
EACH CYCLELayer 1 handlesmore casesautomaticallyauto-contained(most cases exit here)AlertArrivesLayer 1Auto-executes · ~85%Novel case?Escalates if outside policyLayer 2Human + LLM decideThreat IntelCaptures the findingPolicy UpdatedBoundary expands →

In an operation that has integrated large language models and agentic AI, each stage of the flywheel runs faster. Agentic AI in Layer 1 handles investigation chains — from alert receipt through enrichment, threat intel correlation, and analyst-ready briefing generation — in seconds. Layer 2 decisions are supported by LLM reasoning that surfaces structured evidence rather than raw data. The Threat Intel stage, with LLM-assisted synthesis, compresses the analysis-to-briefing time from days to hours. Policy updates that previously took weeks can be completed in a single review session. The flywheel spins faster, and the Layer 1 boundary expands faster.

The hardest design question is what happens when AI makes a wrong call within its authority boundary. For ML-based automation, a wrong call is a policy gap — update the conditions, verify the fix, return to production. For LLM and agentic AI, wrong calls have additional failure modes. A hallucination — confident but incorrect reasoning — is addressed by monitoring for high-confidence low-evidence outputs. A prompt injection — adversary-crafted input manipulating the agent’s reasoning — is addressed by hardening input sanitisation and red-teaming the attack surface regularly. The policy governance stage of the flywheel must include both, not just the rule-update cycle that suffices for classical automation.

The CISO in this model has a different job than in a traditional security operation. They spend less time on incident management and more time on flywheel governance: defining authority boundaries, reviewing trust records and adversarial test results, approving policy expansions, and representing the programme to the board. The board conversation changes too — from reporting on incidents survived to a conversation about flywheel velocity, policy coverage, AI trust record performance, and prompt injection resilience. That is a more defensible, more strategic, and more honest conversation than the one most CISOs are currently having.