By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: torqPublished December 15, 2025

TL;DR: Alerting overload, tool sprawl, and identity-aware attack surfaces are pushing SOCs toward agentic AI, with Splunk cited in the source article as showing 47% of SOCs face alerting issues and most spend more time maintaining tools than defending threats. The governance challenge is no longer whether AI can help, but whether human oversight, auditability, and escalation boundaries are strong enough to trust it in production.


At a glance

What this is: This is a Torq-authored analysis of human-AI collaboration in the SOC, arguing that agentic AI should handle repetitive investigation work while humans retain judgment, approvals, and policy control.

Why it matters: It matters because SOC automation is now touching identity, SaaS, and cloud operations, so IAM, PAM, and governance teams need to understand where AI-assisted actions depend on access controls, approval flows, and audit trails.

By the numbers:

👉 Read Torq's analysis of human-AI collaboration in the SOC


Context

Security operations are being pulled in two directions at once: more alerts and more automation. The article frames that tension around the SOC, but the underlying governance problem is broader. As AI begins to enrich cases, recommend actions, and even execute workflows, the question becomes how to preserve control when machine speed enters identity, cloud, and SaaS response paths.

The primary issue is not whether automation exists, but whether the operating model makes the AI accountable, explainable, and constrained. That is where identity governance intersects with SOC design. Once agentic AI can interact with IAM, EDR, SIEM, and case-management systems, the quality of approvals, RBAC boundaries, and escalation rules becomes part of the security control plane.


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: When does SOC automation create more risk than it reduces?

A: SOC automation becomes risky when the system can act faster than governance can explain its actions. If prioritisation, suppression, or response happens without clear accountability, the team may gain speed but lose control over false positives, missed context, and unintended containment. The threshold is reached when execution is no longer visibly tied to a human decision path.

Q: What do security teams get wrong about GenAI in the SOC?

A: They often assume the model reduces the need for analyst judgment. In practice, GenAI reduces reading and writing time, but the analyst still owns interpretation, prioritisation, and escalation. If the team uses the model to replace verification, it will amplify mistakes instead of reducing workload.

Q: How do teams know if AI SOC learning is actually working?

A: Look for stable verdicts on repeated alert patterns, higher agreement with analyst corrections, and fewer unnecessary re-reviews after retraining. The key signal is not whether the model is active, but whether it produces consistent outcomes that match local policy across shifts and model updates.


Technical breakdown

What agentic AI changes in SOC workflow design

Agentic AI is not just a chatbot with better prompts. In the article’s model, it can perceive telemetry, plan a sequence of actions, reason through failures, act through APIs, and reflect on outcomes. That makes it a workflow participant rather than a passive assistant. In a SOC, this matters because enrichment, case building, and remediation can move from manual sequences to machine-executed decision chains. The technical risk is that the same system that accelerates triage can also execute the wrong action at scale if its boundaries are unclear.

Practical implication: define which SOC actions are machine-executable and which must remain human-approved.

Trust calibration depends on transparency, consistency, and escalation

The article’s trust model rests on four control ideas: transparency, consistency, guardrails, and escalation. Transparency means the AI must show evidence and rationale, not just a verdict. Consistency means it should behave deterministically across tenants and identities. Guardrails constrain what it can touch, especially for privileged or sensitive actions. Escalation ensures ambiguity is handed back to humans. In practice, this is closer to control design than model performance. If the workflow cannot be traced, audited, and interrupted, it is not ready for operational use.

Practical implication: require auditable reasoning, role-based approvals, and explicit human escalation paths before expanding autonomy.

Autonomy tiers are really access tiers in disguise

The four autonomy levels described in the article map directly to access governance. At lower tiers, AI suggests and humans act. At higher tiers, AI acts with supervision or autonomously for routine scenarios. That means every increase in autonomy is also an increase in effective privilege. If an AI system can block IPs, isolate hosts, or change group membership, it is exercising privileged operational access even if no person is logged in at that moment. This is why SOC autonomy must be treated as an identity and privilege design problem, not just an automation problem.

Practical implication: apply least privilege and approval controls to AI workflows exactly as you would to privileged operators.


NHI Mgmt Group analysis

Agentic AI in the SOC is becoming an identity governance problem. Once a machine can enrich cases, draft decisions, and trigger remediation, it is no longer just consuming security data. It is acting inside privileged workflows that normally belong to analysts and responders. That shifts the governance burden toward RBAC, approval design, auditability, and scoped delegation. The practitioner conclusion is simple: AI SOC programmes must be governed like privileged systems, not treated like passive tooling.

Trust calibration is the real control framework, not model confidence. The article correctly argues that trust is earned through transparency, consistency, guardrails, and escalation. That framing aligns with how security teams should think about operational AI: the issue is not whether a model can produce a plausible answer, but whether the system can justify, constrain, and hand off decisions safely. The practitioner conclusion is that explainability without enforceable controls is only surface comfort.

Autonomy tiers create a new class of standing privilege risk. When AI can take action without a human in the loop, the organisation has effectively delegated privilege to software. That creates a governance gap if access reviews, approvals, and logging still assume human operators. Standing privilege in machine form: persistent workflow authority can be as risky as an over-entitled administrator account if it is not bounded by task, context, and revocation logic. The practitioner conclusion is to govern AI execution rights as tightly as human admin rights.

Human-AI collaboration will expose weak boundaries between SOC tooling and IAM controls. The article’s examples, from group changes to just-in-time access approvals, show that SOC automation is already touching identity systems. That makes the identity bridge explicit: if the SOC can change access, then IAM and PAM must define what it may change, under what approval, and with what evidence. The practitioner conclusion is that identity teams need a formal say in AI workflow design.

Operational speed is only defensible when measurement proves control, not just volume reduction. Metrics such as override rates, workflow success, and MTTR are useful, but they must be interpreted as governance signals, not vanity numbers. A fast AI SOC that is frequently reversed by humans is a control failure, not an efficiency win. The practitioner conclusion is to use operational telemetry to decide where autonomy should shrink, expand, or stop.

What this signals

AI-assisted SOC programmes will increasingly be judged by control quality, not just response speed. As workflows begin to touch identity, access, and containment, security leaders should expect tighter scrutiny of audit trails, approval paths, and rollback capability. The operational question is whether the AI can be trusted to act without expanding the blast radius of a mistake.

Delegated security authority: once AI can trigger remediation, it inherits a form of operational privilege that must be scoped, monitored, and revoked like any other privileged capability. That means SOC leaders need to coordinate with IAM and PAM teams on who can publish workflows, who can approve them, and how exceptions are handled.

The most mature programmes will use metrics such as override rates, escalation frequency, and action success to decide where autonomy belongs. For identity-aware workflows, that telemetry should be reviewed alongside privilege scope and access reviews so that machine actions stay aligned with policy and business risk.


For practitioners

  • Define AI action boundaries for SOC workflows Document which actions an AI workflow may take automatically, which require approval, and which are prohibited, especially for identity changes, production access, and containment actions that affect business services.
  • Treat AI workflow access as privileged access Assign RBAC, approval, and logging controls to agentic SOC workflows the same way you would for privileged operators, including explicit ownership for every workflow that can modify IAM, SIEM, or case-management state.
  • Measure override rates as a governance signal Track how often analysts reverse AI recommendations, then segment the data by workflow type so you can see where transparency is insufficient, where escalation triggers are weak, and where the model is overstepping.
  • Insert human approval before sensitive identity actions Require human sign-off before account lockouts, group membership changes, production firewall changes, or just-in-time access approvals that could affect privileged users or critical services.

Key takeaways

  • The article’s core message is that AI in the SOC only works when human control is engineered into the workflow.
  • Once AI can modify identity or response actions, it must be governed as a privileged actor with audit and approval boundaries.
  • Teams should measure overrides, escalation, and action outcomes to decide where automation is safe and where human review must remain mandatory.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4SOC workflows touching access changes need least-privilege control and authorisation boundaries.
NIST SP 800-53 Rev 5AC-6Delegated SOC actions can expand effective privilege if least-privilege controls are weak.
NIST AI RMFGOVERNThe article is fundamentally about accountability, oversight, and governance for agentic AI.
ISO/IEC 27001:2022A.5.15Access control policy is central when AI workflows can influence identity and remediation systems.

Document which AI actions require approval under A.5.15 and review them like privileged access.


Key terms

  • 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.
  • Trust calibration: Trust calibration is the process of aligning confidence in an AI system with evidence of how it behaves in practice. In a SOC, it depends on transparency, consistent execution, escalation when uncertain, and measurement of whether humans repeatedly overturn the system’s decisions.
  • Human-in-the-Loop (HITL): A governance pattern requiring human approval before an AI agent takes high-impact, irreversible, or out-of-scope actions. HITL is a critical control for agentic AI identity governance.
  • Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full article

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

  • Specific examples of how Torq structures tiered autonomy across SOC workflows and where human approvals are inserted
  • Step-by-step details on workflow logging, case updates, and reporting metrics used to measure trust calibration
  • Examples of how AI Task operators are embedded into workflows to summarize telemetry and propose next steps
  • The vendor's own implementation examples for guardrails around just-in-time access, group changes, and privileged actions

👉 Torq's full article covers the tiered autonomy model, trust calibration framework, and SOC workflow examples in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the governance foundations needed to manage privileged automation and agentic systems.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org