Notifications
Clear all
Topic starter
02/08/2026 11:39 am
TL;DR: 94% of organisations already use AI in some SOC capacity, yet only 37% deploy it for triage and 92% of security leaders say trust is being reduced by current AI use in the SOC, according to torq’s AI SOC Leadership Report. The gap points to visibility, control, and explainability as the real blockers to scale, not model capability.
NHIMG editorial — based on content published by torq: AI SOC Leadership Report findings on trust, adoption, and transparency
By the numbers:
- 94% of organizations use AI in some capacity in the SOC.
- 92% of security leaders say something is actively reducing their trust in AI within the SOC.
- Triage is the least deployed AI use case, with only 37% adoption.
Questions worth separating out
Q: What breaks when AI SOC agents are deployed without clear guardrails?
A: Without guardrails, agents can overstep their intended scope, take incorrect response actions, or produce decisions that analysts cannot explain to auditors and leadership.
Q: Why do SOC teams still hesitate to deploy AI for triage even when confidence is high?
A: Teams hesitate because triage is where false positives, incomplete context, and speed pressure intersect.
Q: How can analysts tell whether AI-driven SOC automation is actually working?
A: Look beyond alert volume and measure whether the platform produces accurate incidents, preserves tenant context, and shortens time to closure without creating rework.
Practitioner guidance
- Define AI decision boundaries in the SOC Document which alert classes, response actions, and data sources an AI system may access, and assign explicit approval thresholds for anything that affects containment, escalation, or customer impact.
- Require auditable reasoning trails Ensure each AI-assisted decision records the evidence used, the logic applied, and the resulting action so analysts can review it during investigations, post-incident analysis, and compliance checks.
- Separate triage automation from response authority Allow AI to summarise, prioritise, and enrich cases before it is allowed to execute response steps, especially where false positives or business-critical systems are involved.
What's in the full report
Torq's full blog series covers the operational detail this post intentionally leaves for the source:
- How the AI SOC platform structures declarative instructions, tool access, and decision permissions for agents.
- Examples of transparent timeline views that document reasoning, execution, and human override points.
- The immutable audit log design used to support compliance and post-incident review.
- The human-in-the-loop operating model for high-severity versus low-severity response paths.
👉 Read Torq's blog series on AI trust, transparency, and SOC automation →
AI SOC trust gap: what security teams actually need to fix?
Explore further
02/08/2026 12:51 pm
AI SOC trust is an identity and privilege problem as much as an analytics problem. Once an AI system can inspect alerts, enrich cases, and trigger response, it becomes a governed actor with access rights, decision boundaries, and audit expectations. The trust gap in SOCs reflects the same control logic seen in privileged access programs: capability alone does not justify authority. Practitioners should treat AI in the SOC as a delegated control plane, not a productivity add-on.
A question worth separating out:
Q: Who is accountable when an AI SOC platform takes the wrong action?
A: The organisation remains accountable, because delegation does not transfer responsibility. Security, risk, and control owners need clear approval rules, logging, and override authority so each action can be traced back to a human governance decision. Without that, the control environment is not defensible.
👉 Read our full editorial: AI SOC trust gaps persist because deployment lags confidence
