Notifications
Clear all
Topic starter
21/08/2026 4:43 pm
TL;DR: Security operations work best when autonomous AI handles repetitive alert triage while copilot tools such as Claude accelerate judgment-heavy investigation, reporting, and tuning, rather than forcing one model to do both, according to Intezer. The practical lesson is that SOC AI succeeds as an operating model, not a chatbot bolted onto detection tools.
NHIMG editorial — based on content published by Intezer: CISO Playbook: Putting Claude to work in security operations
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing access credentials.
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
Questions worth separating out
Q: How should security teams split autonomous AI and copilot use in the SOC?
A: Use autonomous AI for repetitive, high-volume triage where the decision can be validated from telemetry, and reserve copilots for analyst judgment, context gathering, and report drafting.
Q: Why do SOC copilots create identity governance issues?
A: SOC copilots often need access to case history, chat, email, ticketing, and other operational systems to do useful work.
Q: How can teams tell whether AI threat detection is improving SOC performance?
A: Look at mean time to verdict, analyst rework, and the percentage of alerts resolved with documented reasoning.
Practitioner guidance
- Define the autonomous and copilot split Map which SOC tasks should be closed by machine triage and which require human judgment, then write that split into your operating model before procurement.
- Put identity controls around copilots Restrict copilot access to email, chat, ticketing, and case data with least privilege, SSO, and audit logs so the assistant cannot become an uncontrolled data pathway.
- Standardise the context layer Use a governed integration pattern, such as MCP-style connectors, so analysts and copilots work from the same normalized cases and evidence.
What's in the full article
Intezer's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step SOC task split used to decide which work should stay autonomous and which belongs with a copilot.
- Example prompts and handoff patterns for escalation, reporting, and detection engineering workflows.
- The rollout sequence the article says can deliver value in roughly three months.
- The metrics framework for defending AI spend to executives and the board.
👉 Read Intezer's CISO playbook on putting Claude to work in security operations →
AI in the SOC: what changes when triage and judgment are separated?
Explore further
21/08/2026 5:04 pm
AI in the SOC is an operating model problem before it is a model selection problem. The article is strongest when it treats AI as a layered system: autonomous triage for volume and copilots for judgment. That framing matters because many failed deployments come from forcing one interface to do both jobs. Practitioners should evaluate whether their SOC is buying a copilot, an autonomous investigation layer, or both, then govern each accordingly.
A question worth separating out:
Q: What should organisations do before connecting copilots to security data?
A: Define the data boundary first, then connect the copilot only to the systems it truly needs. Put SSO, logging, session oversight, and scope limits around every connector, including any service accounts or API tokens. If the assistant can see everything, it will also inherit every unnecessary risk.
👉 Read our full editorial: AI in the SOC works when autonomous triage and copilots are split
