Emerging AI SOC is replacing SOAR as security automation shifts

At a glance

What this is: KuppingerCole’s April 2026 evaluation says security automation has moved beyond SOAR into an Emerging AI SOC category built around reasoning, contextual enrichment, and adaptive decision support.

Why it matters: That shift matters to IAM and SOC teams because AI-driven investigation and response increasingly touch identities, privileges, and delegated actions that need governance, not just orchestration.

By the numbers:

• Torq’s 2026 survey of 450 security leaders found that 97% are confident AI can handle triage, but only 35% have deployed it there.
• Torq reports that 94% are already using AI in the SOC.
• The vendor says 92% of security leaders cited at least one factor that reduces their trust in AI.

👉 Read torq's analysis of the Emerging AI SOC and KuppingerCole evaluation

Context

Security automation is shifting from deterministic playbooks toward AI-assisted investigation and response, and that changes the control problem as much as the workflow. For IAM, PAM, and NHI teams, the key question is no longer whether automation exists, but whether the system can make trustworthy decisions when alerts, identities, and privileged actions intersect.

KuppingerCole’s reclassification of the market reflects a broader operational reality: SOC teams are dealing with more signals, more tool handoffs, and more identity-linked response actions than legacy SOAR designs were built to manage. The article is fundamentally about that governance gap, with Torq presented as one example of how AI SOC platforms are being positioned in response.

Key questions

Q: How should security teams govern AI-assisted actions in the SOC?

A: Security teams should treat AI-assisted SOC actions as policy-governed machine behavior, not informal automation. Define which tools the system may access, which actions require approval, and what must be logged for later review. The goal is to keep investigation speed while preserving human accountability and least privilege across prompts, queries, and remediation steps.

Q: Why do AI SOC platforms raise IAM and PAM concerns?

A: Because the moment a SOC platform can change access, terminate sessions, or trigger containment across systems, it is exercising identity authority. That makes permissions, approval boundaries, and auditability central. If those controls are weak, automation can become an unreviewed privilege path rather than a resilience control.

Q: What do security teams get wrong about SOAR versus AI SOC?

A: Teams often assume AI SOC is just faster SOAR. The difference is that SOAR follows prebuilt workflows, while AI SOC uses organisational context to adapt decisions as evidence changes. That makes governance, traceability, and knowledge quality much more important than rule count.

Q: How do organisations know if AI triage is actually working?

A: Measure whether the AI improves high-fidelity detection, shortens time to verified response, and preserves reviewer trust in its decisions. A system that merely closes more alerts is not enough. The right signal is whether the SOC can validate its conclusions quickly and use them in real investigations without rework.

Technical breakdown

Why rule-based SOAR reaches a ceiling in modern SOCs

Traditional SOAR depends on preconfigured playbooks, fixed triggers, and stable operational assumptions. That model works when the environment is predictable, but SOC work rarely is. Alert volume changes, signal quality varies, and adversaries adapt faster than static workflows. Once teams need continuous contextual enrichment, multi-step reasoning, and exception handling, the playbook becomes a constraint rather than a control. The real technical issue is not automation itself, but whether the system can interpret context and choose actions without requiring engineering work for every new condition.

Practical implication: map which response paths still depend on rigid playbooks and identify where AI-assisted decisioning could reduce manual triage overhead.

How AI SOC platforms use reasoning, RAG, and MCP

The emerging AI SOC stack combines retrieval-augmented generation, which brings external context into a model at inference time, with Model Context Protocol, which standardises how agents connect to tools and data sources. In operational terms, that allows an analyst or agent to request enrichment, investigation, and response in natural language while the platform assembles the workflow behind the scenes. The architectural question is whether AI is only advising the workflow or actively orchestrating parts of it. That distinction matters because tool connectivity, context quality, and decision traceability determine whether the platform is governable.

Practical implication: require traceable tool invocation, context logging, and clear approval boundaries before allowing AI to execute response actions.

Why identity and privilege governance are now part of SOC automation

As AI SOC platforms move from triage into response, they start touching IAM, PAM, and NHI controls directly. Disabling a user, isolating an endpoint, or revoking a token is not just a workflow step. It is an identity action with blast-radius implications. That means role-based, attribute-based, and policy-based access controls inside the platform matter as much as the detection logic. In mixed human and machine environments, governance must cover who can author automations, who can approve high-risk actions, and how those actions are audited after execution.

Practical implication: treat AI SOC permissions as an identity governance problem and review them alongside PAM and NHI access models.

Threat narrative

Attacker objective: The objective is to exploit response latency and decision fatigue so threats move farther before containment.

1. Entry occurs when analysts or operators rely on static workflows that cannot absorb new alert patterns or tool combinations fast enough.
2. Escalation happens when the automation layer lacks contextual reasoning and begins handing high-volume decisions back to humans, creating delay and inconsistency.
3. Impact follows when response is either too slow to contain threats or too brittle to scale, leaving identity-linked actions and privileged workflows under-governed.

NHI Mgmt Group analysis

Emerging AI SOC is now a governance category, not just a tooling label. The retirement of SOAR as a category signals that security automation is being judged on reasoning, adaptability, and operational trust rather than playbook count. That matters because AI-driven response now touches identity, privilege, and human oversight at the same time. For practitioners, the buying decision is increasingly about whether the platform can be governed under real-world conditions, not whether it can trigger actions.

AI SOC expands the identity surface inside SecOps. Once a platform can disable users, enrich alerts with identity context, or trigger containment across cloud and endpoint tools, it becomes part of the identity governance plane. That creates a named concept we should track: response authority sprawl, where machine-driven response capabilities spread faster than approval and audit models. The practical conclusion is that SOC automation policy now needs the same scrutiny as privileged access policy.

Explainability is the control that separates usable AI from opaque automation. The market is moving past simple orchestration because buyers now expect to know why a decision was made, what data informed it, and where human override remains possible. That expectation aligns with broader AI governance principles and with identity governance norms around accountability. Practitioners should treat decision traceability as a prerequisite for any expansion of autonomous response.

Platform consolidation pressure is likely to increase around AI SOC workflows. Once a market category is formally named, buyers begin comparing architecture, not just features. That tends to favour platforms that can connect identity, detection, and response data with lower operational overhead. The likely result is more scrutiny of how SOC automation, IAM, and NHI governance fit together, because isolated tooling will be harder to justify.

The most important question is no longer whether AI belongs in the SOC, but where it can act safely. Some decisions can be accelerated, but identity-impacting actions still need policy boundaries, auditability, and scope limits. That is the line practitioners need to define before they expand AI autonomy.

What this signals

AI SOC adoption is now moving from experimentation to governance design, which means security teams need to model how automated decisions intersect with access control, audit, and incident command. The near-term signal is not that humans disappear from the loop, but that the loop itself becomes more identity-sensitive as response platforms gain authority over credentials, sessions, and user actions.

Response authority sprawl: when multiple automations can trigger identity-impacting actions without a single governance model, the SOC can outpace its own controls. That problem will show up first in approvals, then in audit gaps, then in uncertainty about who owns a failed or harmful automation. Teams should align AI SOC controls with privileged workflow governance before scaling autonomy.

For identity programmes, the practical signal is that SOC tooling now belongs in the same conversation as PAM and NHI lifecycle management. If a platform can act on identities, it should be governed like a privileged system. The broader implication is that AI SOC success will be measured less by volume handled and more by whether the organisation can prove control over machine-triggered actions.

For practitioners

• Define AI response boundaries Classify which containment and remediation steps AI may execute automatically, which require human approval, and which remain manual. Give special scrutiny to actions that change user access, revoke tokens, or alter privileged sessions.
• Review identity-linked automations Inventory SOC automations that touch IAM, PAM, NHI, endpoint isolation, or cloud access. For each one, document the permission source, approval path, rollback option, and audit record needed for post-incident review.
• Test explainability under incident pressure Validate whether analysts can understand why the platform chose a particular action when signals are noisy or conflicting. Focus on decision traceability, not just whether the action succeeded.
• Align AI SOC permissions with least privilege Separate workflow authorship, execution rights, and override authority so a single operator or agent cannot both create and run high-impact response paths without review.

Key takeaways

• The report marks a clear shift from rule-based SOAR to an AI SOC model built around reasoning, context, and adaptive response.
• The main governance challenge is not whether automation exists, but whether identity-impacting actions can be executed with traceability and control.
• Security teams should evaluate AI SOC tools through the lens of privileged workflow governance, explainability, and blast-radius management.

Key terms

• Emerging AI SOC: An Emerging AI SOC is a security operations model that uses AI for triage, investigation, prioritisation, and response instead of relying mainly on fixed playbooks. The defining feature is adaptive decision support with governance, traceability, and controlled execution across tools.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Response authority sprawl: Response authority sprawl is the spread of identity-impacting action rights across multiple automations, agents, and operators without a single governance model. It creates audit gaps, approval confusion, and unclear ownership when systems can disable users, revoke access, or isolate assets.
• 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.

What's in the full article

Torq's full article covers the operational detail this post intentionally leaves for the source:

• How the KuppingerCole evaluation broke down product, innovation, market, and overall leadership criteria.
• The vendor's own explanation of its AI SOC architecture, including RAG, MCP, and agent-to-agent collaboration.
• Specific customer examples and stated automation outcomes from production SOC deployments.
• The full list of strengths KuppingerCole identified across integrations, explainability, and governance.

👉 Torq's full post covers the KuppingerCole scoring, architecture details, and customer examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to the broader security operations and automation landscape.