Notifications
Clear all
Topic starter
06/09/2026 3:44 pm
TL;DR: SOCs cannot close the machine-speed gap by simply deploying more AI agents, because the real constraint is coordination, cost, and control rather than raw capability, according to Crogl. The practical shift is toward dynamic intelligence allocation, where deterministic automation handles known patterns and agents are reserved for ambiguous investigations.
NHIMG editorial — based on content published by Crogl: AI Agents Are Not Enough
Questions worth separating out
Q: How should security teams decide where to use AI first in the SOC?
A: Start with the layer that has the clearest operational pain and the cleanest success metric.
Q: Why do API-connected AI agents create new governance risks in SecOps?
A: Because the agent can move from analysis to action across multiple systems in one chain.
Q: What signals show that AI SOC automation is failing?
A: Common warning signs include inconsistent case notes, unexplained escalations, duplicated investigations, and automation outputs that analysts must repeatedly correct.
Practitioner guidance
- Define the intelligence-routing model Classify SOC use cases into low-uncertainty and high-uncertainty paths so deterministic automation handles repeatable events and agents handle novel investigations.
- Treat agent authority as NHI governance Assign explicit scope, logging, and revocation conditions to every AI agent that can access tools or data.
- Build a codification loop from investigations Require every agent-led investigation to produce a reusable control outcome, such as a rule, playbook update, or detection pattern.
What's in the full article
Crogl's full blog covers the operational detail this post intentionally leaves for the source:
- A deeper explanation of why deterministic playbooks collapse when attackers deviate from expected patterns.
- The article's own framing of how to balance human analysts, automation, and AI agents across different SOC tasks.
- Crogl's view of the meta-level system needed to allocate intelligence, control cost, and learn from investigations.
- The end-state operating model for a self-optimising SOC that improves as it encounters new threats.
👉 Read Crogl's analysis of why AI agents alone do not solve SOC scaling →
AI agents in the SOC: is orchestration the missing control layer?
Explore further
06/09/2026 3:45 pm
AI SOC operations are becoming an intelligence-allocation problem, not just an automation problem. The article is right to reject the idea that more agents automatically create better security. The real design challenge is deciding which workloads require deterministic control and which require reasoning under uncertainty. That aligns with broader automation governance principles in NIST-CSF and NIST-800-53, where control selection has to match operational risk. Practitioners should stop asking how many agents they can add and start asking where intelligence actually belongs.
A question worth separating out:
Q: How can organisations make AI agents useful without overspending?
A: Limit agents to cases where reasoning changes the outcome, then codify the discoveries back into rules and workflows. This reduces repeated compute spend on problems that no longer need an agent. The operating model should aim to shrink agent use over time for known patterns while reserving it for genuinely uncertain cases.
👉 Read our full editorial: AI agents in the SOC need orchestration, not just more automation
