TL;DR: Based on 450 CISOs and security leaders across four countries, 94% of teams use AI in the SOC, 80% say it adds complexity, and only 35% let AI handle triage, according to torq. The governance problem is no longer adoption, but deciding where automation can operate safely without weakening control.
At a glance
What this is: Torq’s AI SOC Leadership Report says AI is widely deployed in security operations, but most teams still experience added complexity and limited automation in triage.
Why it matters: This matters because SOC teams are moving faster into AI-assisted operations than their governance, transparency, and control boundaries are adapting, which raises operational risk for both human-led and agentic workflows.
By the numbers:
- 94% of teams use AI in the SOC.
- 80% say AI is adding complexity, not reducing it.
- 35% actually let AI handle triage.
Context
AI in the SOC now means more than alert summarisation or recommendation support. The real governance issue is how far automation is allowed to move from analysis into action, especially when a security operation must still explain, approve, and contain decisions under pressure.
That tension is sharper when AI is embedded into triage, investigation, and response workflows. As SOC teams add agentic behaviour, they also inherit a new control problem: how to preserve transparency, accountability, and escalation discipline when a system can act faster than a human review cycle.
Key questions
Q: When does AI in the SOC become a governance risk rather than an efficiency gain?
A: It becomes a governance risk when it changes decision timing, action sequencing, or approval boundaries without clear policy. If the system can influence response before a human review, then the organisation has moved from assistance to delegated execution. At that point, auditability, rollback, and ownership become mandatory controls.
Q: Why do AI-assisted SOC workflows often increase complexity?
A: They increase complexity when organisations add separate tools for triage, investigation, and response without a single operating model. Each added layer creates new handoffs, policy dependencies, and logging requirements, so the programme spends more effort coordinating automation than using it.
Q: What are the signs that an AI-assisted triage workflow is failing to reduce analyst workload?
A: The clearest signs are persistent manual research on familiar alerts, inconsistent dispositions for repeat patterns, and little movement in queue volume or decision time. If analysts still have to dig through closed tickets to understand obvious lookalikes, the workflow is not delivering enough context. A useful system should quickly identify close matches and separate repeat noise from alerts that need escalation.
A: Start by separating investigation from response authority. Let agents enrich alerts, gather evidence, and recommend actions, but require human approval for containment, account disablement, or other high-impact steps. This preserves accountability while still removing manual enrichment work. Test those boundaries against your incident severity model and revisit them as confidence in the system improves.
Technical breakdown
Why AI SOC workflows become harder to govern
AI in security operations often starts as assistance and quickly becomes orchestration. Once models or agents ingest alerts, enrich data, prioritise cases, and trigger response steps, the workflow stops being a single tool feature and becomes a control plane for decisions. That introduces dependency on prompt quality, rule boundaries, data fidelity, and logging completeness. In SOC terms, the issue is not whether AI can reduce analyst effort, but whether each delegated step remains reviewable, reversible, and bounded. If the workflow cannot explain why one alert was escalated and another ignored, the organisation has automated motion without governance.
Practical implication: Treat AI-enabled SOC workflows as governed decision paths, not just productivity features.
What agentic response changes in the security stack
Agentic response differs from conventional automation because the system can choose actions based on context rather than execute only a fixed playbook. That makes the trust boundary much wider. The agent may query multiple tools, correlate external intelligence, and then carry out containment or remediation with limited human intervention. This is useful when response speed matters, but it also shifts risk into data quality, authorization scope, and action validation. The architecture must therefore distinguish between suggestion, preparation, and execution. Without that separation, a fast system can also become a fast mistake multiplier.
Practical implication: Separate analysis, recommendation, and execution permissions so agentic response cannot outrun control.
Agent transparency is now a security requirement
The article’s emphasis on transparent reasoning logs reflects a broader reality: SOC AI cannot be governed as a black box if it is expected to make operational decisions. Security teams need artefacts that show what data was used, what reasoning path was followed, what thresholds were crossed, and what action was taken. That is especially important when the AI touches alert triage or incident containment. Transparent logging is not just for audit after the fact. It is also how teams validate whether the system is behaving within policy before an automated action changes production conditions.
Practical implication: Require reasoning logs and action traces before allowing AI to influence containment or remediation.
NHI Mgmt Group analysis
AI in the SOC is now a governance problem, not an adoption problem. When 94% of teams are already using AI while 80% still say it adds complexity, the issue is no longer whether AI belongs in security operations. The issue is whether the organisation can define decision boundaries that survive real-time incident pressure. The practitioner conclusion is straightforward: AI SOC programmes need explicit control ownership before they need more features.
Agentic SOC tools create a new trust boundary inside operations. Once a system can investigate, correlate, and respond, the old assumption that automation only executes fixed playbooks no longer holds. That creates a distinct control gap around authorisation scope, action reversibility, and evidence capture. The practitioner conclusion is to treat agentic response as a privileged operational actor, not a normal workflow extension.
Transparency is becoming the defining control for AI-enabled security operations. If a team cannot reconstruct why an AI agent triaged one case, escalated another, or initiated a response action, it cannot claim adequate governance. That makes reasoning logs, decision traces, and policy boundaries part of the control stack rather than optional observability. The practitioner conclusion is to require explainable action trails before expanding autonomy.
AI SOC adoption is exposing automation debt across the security function. Many teams have accumulated disconnected detection, triage, and response helpers without a unifying operating model. Torq’s report suggests the field is now paying for that fragmentation through complexity and uneven trust. The practitioner conclusion is to unify AI use cases around one governance model rather than adding isolated agents.
What this signals
AI SOC programmes are moving faster than their control models. The practical lesson for security leaders is that automation success should not be measured by how many tasks AI can touch, but by how well the programme preserves accountability when those tasks become operational decisions. The teams that will struggle most are the ones treating AI as a point capability instead of a governed operating layer.
Agentic workflows force SOC teams to re-evaluate where the human sits in the loop. If an AI system can enrich a case, prioritise it, and trigger a containment step, then the human role is no longer just analyst review. It becomes policy design, exception handling, and outcome validation. That shift will matter most for teams running high-volume triage with limited oversight capacity.
For practitioners
- Define AI decision boundaries in the SOC Map which steps AI may only recommend, which it may prepare, and which it may execute. Tie those boundaries to approval paths, evidence retention, and rollback expectations so automation cannot quietly expand beyond the intended control model.
- Separate triage from response authority Do not let the same AI workflow both prioritise alerts and trigger containment unless execution permissions are explicitly constrained. Build a clear handoff between analysis and action, especially where remediation affects production systems or user access.
- Require reasoning logs for every automated decision Capture the data inputs, correlation steps, thresholds, and response outcomes for any AI-supported SOC action. Those logs should be searchable by case ID and usable for post-incident review, policy validation, and model tuning.
- Measure where AI reduces friction versus adds overhead Track whether AI shortens triage time, improves alert precision, or simply shifts effort into exception handling and review. If analyst workload moves rather than shrinks, the programme is amplifying complexity instead of reducing it.
Key takeaways
- AI is widespread in the SOC, but broad adoption has not solved the control problem created by faster and more autonomous workflows.
- The report’s numbers point to a gap between trust and execution, which is where governance and transparency now matter most.
- Security leaders should focus less on adding more AI touchpoints and more on defining what AI is allowed to decide, do, and explain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI SOC actions depend on tightly bounded permissions and delegated authority. |
| DE.CM-01 — Networks and systems are monitored to detect anomalous events | The report focuses on AI-assisted monitoring, triage, and response in SOC workflows. | |
| Recommendation — Apply PR.AA-05 to constrain which AI workflows may observe, recommend, or execute security actions. Use DE.CM-01 to validate that AI-assisted monitoring still produces usable security signal. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | AI-enabled SOC response can alter how analysts investigate discovery and containment paths. |
| Recommendation — Map AI-supported investigation and containment steps to ATT&CK so response remains aligned with adversary behaviour. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is primarily about governing AI use inside security operations. |
| Recommendation — Establish GOVERN controls for ownership, oversight, and accountability before expanding AI autonomy in SOC workflows. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Reasoning logs and decision traces are central to the transparency problem discussed here. |
| Recommendation — Use AU-6 to ensure AI-driven SOC actions are reviewable through complete audit trails. | ||
Key terms
- AI SOC Tool: An AI SOC tool is software that helps a security operations center detect, investigate, and respond to threats using artificial intelligence. It typically analyzes alerts, logs, and telemetry to prioritize incidents, summarize evidence, and suggest actions. In practice, it augments analyst workflows across triage, correlation, enrichment, and response.
- Agentic Response: Agentic response is the use of an AI agent to investigate incidents and carry out bounded containment or remediation actions. In security operations, it shifts automation from alert handling to controlled execution, which makes authority, logging, and rollback part of the control design.
- Reasoning Log: A reasoning log is an audit trail that shows how an automated security agent progressed through a test, including the steps it took, the tools it called, and the outcomes it observed. It supports reviewability, debugging, and trust by making the agent’s path visible after the fact.
- Automation Debt: Automation debt is the hidden cost of speeding up a broken process before it is properly designed. In practice, it appears when organisations automate unclear handoffs, inconsistent approvals, or manual exceptions, then inherit the same problems at higher speed and with less visibility.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security practitioners build the control discipline needed to manage autonomous workflows across modern environments.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org