AI in the SOC works when autonomous triage and copilots are split

At a glance

What this is: This is a security operations playbook arguing that AI in the SOC should be split between autonomous triage and human-led copilot work.

Why it matters: It matters because SOC teams must decide where AI can safely reduce alert volume and where human judgment still needs to stay in the loop, including identity-linked investigations and reporting.

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.

👉 Read Intezer's CISO playbook on putting Claude to work in security operations

Context

Security teams are not short of AI experiments. They are short of an operating model that separates high-volume machine work from human judgment, especially when AI starts interacting with identity data, alert trails, and access context inside the SOC.

In practice, the problem is not whether AI belongs in security operations. It is whether teams can govern the boundary between autonomous investigation, human copilot assistance, and the identity controls that protect the tools, accounts, and data those systems touch. That starting position is now common, not atypical.

Key questions

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. The test is not whether AI can talk through an alert. It is whether the workflow keeps evidence, ownership, and accountability clear at every handoff.

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. That turns them into identity-governed workloads that must be limited by least privilege, audited, and tied to approved human access. Without those controls, the productivity layer can become a broad data-access path.

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. If alert volume drops but analysts still have to reconstruct context manually, the platform has not changed the operating model enough to matter.

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.

Technical breakdown

Why the two-layer SOC model matters

The playbook uses a two-layer model because different security tasks have different decision requirements. Autonomous systems are suited to repetitive, high-volume alert triage where the facts can be tested against telemetry and rules. Copilots such as Claude are better for judgment work, including investigation write-ups, business-context checks, and analyst assistance across tools. The key architectural point is that the copilot should not be the first responder. It should sit above a normalized investigation layer, inherit evidence, and help humans decide faster without taking ownership of the case.

Practical implication: keep autonomous triage and human judgment in separate workflow layers so you do not collapse coverage into a chat interface.

Model Context Protocol and the SOC knowledge layer

The article’s technical core is that useful copilot work depends on context, not just model capability. The Model Context Protocol, or MCP, is the connection layer that lets an AI workspace query normalized cases, detection history, and live SIEM or EDR data without reassembling raw feeds manually. That matters because the SOC’s knowledge lives in detection logic, prior cases, and integrations, not in the model itself. A copilot without that context becomes a generic assistant. A copilot with it becomes a supervised investigation layer.

Practical implication: connect copilot workflows to governed case and telemetry sources through controlled interfaces, not ad hoc prompts.

Why identity data changes AI SOC risk

SOC copilots often need access to email, Slack, calendars, ticketing systems, and case history to resolve escalations. That makes identity and access governance part of the design, not an afterthought. The assistant must inherit only the analyst’s permitted scope, while the underlying agent or integration account should have narrow, auditable access. In identity terms, this is a workload and human access problem as much as an AI problem. If access is over-broad, the copilot can become a data exposure path rather than a productivity layer.

Practical implication: apply least privilege, SSO, and audit logging to the copilot stack before expanding what it can query.

NHI Mgmt Group analysis

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.

The identity boundary around SOC copilots is now a control point, not a convenience issue. Once a copilot can reach email, chat, tickets, and case history, the real question becomes which identities are allowed to query what. That is an IAM and PAM concern as much as a productivity concern, especially where analyst context overlaps with privileged incident data. Teams should treat access scope, logging, and session oversight as part of the SOC design.

MCP makes context portable, but it also makes context governable. The article’s reference to MCP is important because it turns scattered detection and case data into something a copilot can consume consistently. That creates an opportunity to standardise what the AI can see, which is preferable to letting every analyst wire their own brittle integrations. Practitioners should see the protocol layer as a policy boundary, not just a convenience feature.

Coverage is the real security metric, not how fluent the copilot sounds. The article repeatedly argues that low- and medium-severity alerts cannot be excluded if the autonomous layer is meant to close the blind spot problem. That is a useful corrective to AI hype in SOC tooling. The practitioner test is simple: does the combined stack investigate everything, or does it merely make the loudest alerts easier to write about?

What this signals

MCP-style integration will become a governance issue as much as an architecture choice. The more AI systems depend on shared case context, the more important it becomes to control which identities can query that context and under what conditions. That is why analyst-grade copilots should be treated like governed workloads, not just productivity tools.

The next maturity step for SOC teams is to link operational AI adoption with identity lifecycle discipline. Service accounts, API tokens, and delegated access used by AI-assisted workflows need the same review attention as any other privileged system account, especially when those workflows span email, chat, and case data.

Coverage will separate serious deployments from theatre. Teams that can show alert coverage, escalation quality, and decision consistency will have a defensible AI operating model, while teams that only measure speed risk automating the same blind spots they already had.

For practitioners

• 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.
• Measure coverage, not just output quality Track alert coverage, MTTR, analyst hours reclaimed, and escalation quality to confirm the stack is really closing blind spots rather than just drafting better summaries.
• Use NHI governance for machine-facing SOC access Treat API keys, service accounts, and delegated tokens used by SOC tooling as non-human identities and review them for scope, rotation, and offboarding.

Key takeaways

• The article’s core lesson is that AI succeeds in the SOC when teams separate machine triage from human judgment.
• Identity governance matters because copilots and their connectors can touch sensitive operational data, so access scope and auditability are not optional.
• The most useful measure of success is coverage, because better summaries do not matter if low-severity signals still fall through the cracks.

Key terms

• Autonomous Triage: Autonomous triage is the use of software to collect context, correlate signals, and execute routine investigation steps before an analyst reviews the case. In practice, it reduces repetitive work, but it still requires governance, escalation rules, and human oversight for high-risk events.
• Copilot Workflow: A human-led operating pattern where AI assists with investigation, drafting, enrichment, or analysis while the analyst keeps decision authority. The value comes from accelerating judgment work, not replacing it, and from preserving a clear audit trail for the actions the AI helped produce.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

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.

👉 The full Intezer article covers the SOC workflow examples, rollout model, and board metrics in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for teams building secure identity controls around machine-facing systems. It is a fit for security practitioners who need to govern the accounts, tokens, and access paths behind modern automation.