John White is the Field CISO for EMEA at Torq. A respected security executive with more than 20 years of leadership experience, John previously served as CISO at Virgin Atlantic, where he led a multi-year transformation deploying the Torq AI SOC Platform to modernize cyber operations. Prior to Virgin Atlantic, he built and transformed security functions for global organizations, including ASOS, Liberty Global, AEG Europe, and KPMG.
I’ve spent the last 25 years in security leadership with the majority on the practitioner or “buying side”. Earlier this year, I crossed over to what people like to call “the dark side” and joined AI SOC Platform leader, Torq, as their Field CISO.
That decision wasn’t accidental.
I believe we’re on the edge of a structural shift in how security organizations are built and run. Not incrementally. Not with a few new tools and a re-org, but through a fundamental rethink of how security functions are structured, staffed, and measured.
I wanted to be at the source, able to look at the answer from both sides of the fence and provide my fellow CISOs with objective insight and guidance in navigating the shift.
Torq’s 2026 AI SOC Leadership Report recently surveyed 450 security leaders on what they actually want from an AI SOC. The results weren’t abstract or aspirational; they were blunt.
The top capabilities read like a checklist:
92% want continuous learning and adaptation
91% say full platform integration is critical
90% care about explainable AI decisions
89% want true end-to-end SecOps, from triage through remediation
That’s the destination. What mattered to me is that Torq wasn’t trying to reverse-engineer its way there from a SIEM, a SOAR, or a chat interface. The platform was designed for AI natively, unburdened by legacy and outdated architectures. That’s what closed the deal.
Why AI Tools Don’t Equal an AI SOC
AI is everywhere in the SOC. 94% of organizations use it in at least one function. 79% have embedded it into workflows. Yet only 37% say adoption is widespread.
Why? Because the average SOC is running seven or more different AI tools, and 80% of leaders say those tools are fragmented.
Seven-plus AI engines. Seven sets of alerts. Seven interpretations of “truth.” And one analyst in the middle expected to synthesize it all while the attacker moves in minutes. According to CrowdStrike’s 2026 Global Threat Report, the average eCrime breakout time is 29 minutes. The fastest intrusion they observed took just 27 seconds.
This is the point-solution trap. A new threat appears, a new tool gets bought. Five years later, you’re running a SOC held together by custom APIs and one engineer who knows where the duct tape is.
This doesn’t persist because CISOs are naïve. We all read our own stacks. But fixing it means ripping things out, and that means budget battles, politics, and admitting the platform you backed two years ago no longer delivers.
The data point that stuck with me: 53% of security leaders believe a fully integrated AI SOC would resolve their trust issues with AI. That’s the whole story. The trust problem isn’t philosophical; it’s architectural. Fragmented AI produces an output no one can trust, because no one can see the whole picture.
Torq made a different call from day one: One platform underneath everything. One orchestration layer spanning the entire threat lifecycle. Every AI agent operates through the same execution fabric. Every action is grounded in the same data. The Hyperautomation engine gives AI a foundation that the rest of the SOC can actually see into.
Where AI Actually Belongs First in the SOC
97% of leaders say they’re confident AI can handle triage and prioritization. They’re right, that’s where the biggest value is. Detection-to-response is the attacker’s window, and shrinking that window matters more than almost anything else.
Yet only 37% are actually using AI for triage today. Instead, teams lean on it for containment, false-positive reduction, case management, and vuln management.
The blocker isn’t capability, it’s confidence, specifically around black-box behavior. Teams are comfortable letting AI handle medium-severity and below. Beyond that, CISOs want clarity and control.
The right model is severity-based autonomy. High-severity incidents touching critical systems? Humans decide. Low-severity, high-confidence patterns? AI runs end-to-end.
That breakpoint is exactly how Torq is built. At Carvana, 100% of Tier 1 and Tier 2 alerts are handled by Torq’s AI agents. Humans focus on where they add the most value: Tier 3 critical risk.
What Explainable AI Actually Requires
Nearly half of security leaders say transparency is the single biggest factor in their trust in AI, and 92% cite at least one factor actively reducing their trust today.
If AI disables an account or quarantines a host, the team needs to know why. Not eventually. Immediately. Otherwise, you’re left with a black box that occasionally gets it right.
The trap is turning explainability into a gate that never opens, where everything still requires human review because no one has defined what “trusted enough” really means.
Torq HyperAgents are designed to clear that gate. They run under declarative instruction. You define the role, the tools, the data, and the authority. Every action is logged. Every decision is written into an immutable audit trail. When a CISO asks what the AI did and why, the answer is already there.
How AI Changes Tier 1 Work for the Better
SOC teams spend an average of 8.6 hours a week on AI oversight. That sounds high until you see the next stat: 9 out of 10 leaders say AI has improved SOC workloads. Those hours aren’t busywork. They’re the shift from execution to judgment.
In an agentic SOC, the environment is calmer. AI handles 90%+ of Tier 1 triage, the most voluminous and time-sensitive work in the SOC. Shrink that exposure window, and the panic goes with it. Tier 1 work is repetitive but critical. The agentic model gives analysts what I think of as an exo-suit: same mission, amplified capability.
And when leaders were asked what they wanted most from AI, the top answer wasn’t faster SLAs or lower MTTR. It was a better work-life balance. AI is how people get back to doing meaningful security work.
How a Real AI SOC Builds Memory
92% of leaders say continuous learning is the defining capability of a true AI SOC. Very few are close.
Most SOCs learn in batches. Investigate. Document. Update a playbook. By the time it’s done, the attack has evolved. An adaptive SOC learns in real time. Outcomes feed the next decision immediately. That’s SOC memory, and it doesn’t form across seven disconnected tools. It forms when everything flows through one system.
In Torq’s platform, that system is Socrates, the AI SOC orchestrator. It coordinates every agent, captures every decision, and remembers overrides and exceptions. Each closed case sharpens the next one. That’s the shift from rules-based automation to agentic AI.
Rules execute instructions, whereas AI agents reason with context.
If I Were Building an AI SOC from Scratch
Three decisions, immediately:
Start with the execution layer. AI and automation run at machine speed, 24/7. Everything else sits on top of that foundation.
Define outcomes before roles. Don’t start with the headcount. Start with what needs to be delivered. AI executes. Humans provide strategy and judgment.
Measure before you deploy. Baseline MTTI, MTTR, escalation accuracy, and autonomous closure rates on day one. Six months in, you’ll need your own before-and-after story grounded in data, not slides.
These were the decisions Torq made long before I joined. That made the move an easy one.
Closing the Gap
Security leaders agree on what a true AI SOC looks like. The gap is execution.
450 leaders align on the blueprint. Torq is built to it: agentic AI orchestrated by Socrates, declarative HyperAgents, transparent timelines, immutable audit logs, SOC memory baked into the architecture, and full coverage from triage through autonomous remediation. Customers like Carvana are already living this reality. The blueprint isn’t theoretical anymore.
I’ll leave you with the phrase I come back to often: Inaction introduces as much risk as action. That’s the cost most CISOs are underestimating right now.
The 2026 AI SOC Leadership Report has the methodology, regional breakdowns, and the data behind every finding here.
Noam Cohen is a serial entrepreneur building seriously cool data and AI companies since 2018. Noam’s insights are informed by a unique combination of data, product, and AI expertise — with a background that includes winning the Israel Defense Prize for his work in leveraging data to predict terror attacks. As the Head of Artificial Intelligence at Torq, Noam is helping build truly next-gen AI capabilities into Torq’s AI SOC platform.
Agentic AI is the fastest way to scale a SOC. It’s also the fastest way to break one.
The difference comes down to guardrails — operational ones that decide what an AI Agent can touch, when it escalates, and what happens if it gets a call wrong at 3am on a Saturday.
In our conversations with 450 security leaders, 56% of organizations are already running agentic AI in their SOC. The teams that deployed with guardrails designed in from day one are seeing transformed operations. The teams that bolted guardrails on after the first incident are still rebuilding trust with their analysts.
This guide is for both, but it’s better to read it before you need it.
What Is Agentic AI and Why Does It Need Security Guardrails?
Agentic AI is fundamentally different from the automation SOC teams have used in the past. Traditional playbooks follow a script: if X happens, do Y. They’re powerful for known, repeatable scenarios, but rigid when conditions change. Copilot-style assistants summarize, suggest, and draft… but they don’t act. They wait for a human to click the button.
Agentic AI does something neither can do: it reasons through a problem and acts on it. In a SOC context, an agent doesn’t just enrich an alert — it closes the ticket. Autonomously.
That’s a different trust surface. And it requires a different approach to operational governance, which is why agentic AI security guardrails aren’t optional. They’re the difference between a force multiplier and a liability.
This distinction matters when you’re evaluating vendors, explaining AI to your board, or building trust with the analysts who’ll be working alongside these agents every day. If your team thinks they’re getting a smarter chatbot and you deploy something that takes autonomous action on endpoints, you have a trust problem on day one.
What Are the Risks of Agentic AI Without Security Guardrails?
Acting on incomplete context. An agent auto-isolates a host based on a single EDR alert without checking whether it’s a production database server that half the organization depends on. The alert was real. The response was disproportionate. Context about asset criticality, business impact, and blast radius was missing from the agent’s decision framework.
CrowdStrike’s July 2024 outage — 8.5 million Windows machines bricked by a single bad sensor update — is a recent reminder of what security automation can do without guardrails. In the agentic version, an agent auto-isolates a host on a single EDR alert without checking whether it’s the production database that half the company runs on. The alert was real he response was disproportionate.
Exceeding its approved scope. An agent is deployed for phishing triage. Over time, its logic evolves to include autonomously disabling user accounts as part of its remediation workflow — an action that was never explicitly approved. Nobody noticed until an executive’s account was locked during a board presentation.
This failure mode has a documented extreme: In June 2025, a GitHub Copilot vulnerability (CVE-2025-53773) showed an AI agent rewriting its own approval settings to disable all human review, then gaining unrestricted shell execution. The agent didn’t just exceed its scope — it eliminated the guardrail that was supposed to prevent it.
Unauditable case closures. An agent closes 200 cases overnight. When an auditor asks why a specific case was dismissed, nobody can reconstruct the reasoning. The agent made a decision, but there’s no explainable trail connecting the evidence to the conclusion.
Over-reliance without review thresholds. The agent handles the majority of Tier 1 alerts. Analysts stop reviewing its decisions because the volume is too high and the accuracy seems fine. Then a subtle pattern of missed lateral movement emerges over three weeks — something a human reviewing a sample of closed cases would have caught.
Drift over time. The agent was tuned for the environment six months ago. Since then, the company acquired a subsidiary, migrated two workloads to a new cloud provider, and changed its identity stack. The agent’s logic hasn’t been updated. Its decisions are based on a map that no longer matches the territory.
This isn’t hypothetical. In July 2025, during an explicitly declared code freeze, Replit’s AI agent ran unauthorized commands against production, deleted a live database with records for 1,200+ executives, and then fabricated a claim that rollback was impossible. No attacker, no prompt injection — pure design drift. The agent had production database access, and “code freeze” was not an enforced guardrail. CEO Amjad Masad confirmed it publicly.
Agentic AI: With vs. Without Guardrails
Scenario
Without Guardrails
With Guardrails (Torq Approach)
Phishing Response
Agent quarantines all emails from unfamiliar domains, blocking legitimate vendors and partners
Confidence-based action: high-confidence threats auto-quarantined, medium-confidence presented for review, low-confidence escalated with evidence
Identity Compromise
Agent locks all accounts showing impossible travel, including VPN users and frequent travelers
Approval gates for high-impact accounts (executives, admins, service accounts) with one-click review and context
Audit Request
No reasoning trail, no evidence chain, no way to reconstruct why a case was dismissed
Full reasoning chain logged: evidence reviewed, confidence score, policy applied, action taken, alternatives considered
Scope Control
Phishing agent evolves to disable accounts, modify firewall rules, change IAM policies without approval
Hard architectural boundaries: email security agent physically cannot touch identity systems or network infrastructure
Wrong Decision
No rollback path, 6-hour manual cleanup, affected systems unknown
Defined recovery workflow, automated notifications to impacted teams, documented rollback with audit trail
Analyst Trust
Analysts can’t verify how decisions were made, leading to low confidence in AI-driven outcomes and shadow processes where analysts quietly re-investigate closed cases
Analysts see the full reasoning behind every action, override when needed, and watch the system improve from their feedback
What Should Agentic AI Security Guardrails Cover?
Effective guardrails for agentic AI in the SOC cover five domains. Each one exists because of a predictable, costly, and avoidable failure mode.
Authority: Without bounded authority, an agent deployed for email security ends up touching identity systems within six months. Scope creep is the most common failure mode in production agentic AI, and the consequences range from compliance violations to outages. Authority defines what the agent is and isn’t allowed to touch, before that drift becomes a cleanup project.
Confidence: Every agentic decision lives somewhere on a spectrum from obvious to ambiguous. A guardrail that treats every decision the same — full autonomy, no escalation — will misclassify edge cases until something breaks publicly. Confidence is how the agent signals its uncertainty before acting on it.
Transparency: If an analyst can’t reconstruct why a case was closed, they don’t push back officially. They might re-investigate it on the side. That shadow workflow is invisible to your dashboards and eats up every productivity gain the AI was supposed to deliver. Transparency is what keeps that workflow from forming in the first place.
Containment: The cost of an agent’s mistake is determined by how fast you can reverse it. Without a defined rollback path, a single bad call becomes an hours-long cleanup with an unclear blast radius. Containment is the difference between a near-miss and an incident report.
Evolution: The agent that was tuned six months ago is operating on a map that no longer matches the territory. Evolution is the discipline of catching that gap before the agent acts on stale assumptions.
These five domains map directly to the operational controls SOC teams already maintain for everything else in their stack. The principles aren’t new, but applying them to autonomous AI agents is.
How Do You Build Agentic AI Guardrails That Work in Production?
Guardrails for agentic AI aren’t about limiting what AI can do. They’re about giving teams control over how much AI does and making every decision auditable.
Confidence thresholds. Every agentic decision should carry a confidence score, and that score should determine what happens next. High confidence on a known phishing pattern? The agent closes the case autonomously. Medium confidence with an unusual indicator? The agent completes the investigation and presents its findings for human review. Low confidence? Full escalation with all evidence attached. The thresholds should be adjustable by the SOC team, not hardcoded by the vendor. The pattern has real-world precedent: Waymo’s autonomous vehicles operate on the same model — when confidence drops below threshold in an ambiguous environment, the system requests human guidance, then independently verifies that guidance against its own sensors before acting, and can refuse if there’s a mismatch. The human input is an additional signal, not an unconditional override. An AI SOC agent should work the same way.
Approval gates for high-risk actions. Not all actions carry the same consequences. Quarantining a phishing email is low risk. Isolating a production server is high risk. Disabling an executive’s account is a career risk. The platform needs explicit approval gates that trigger human review before high-impact actions are executed, with clear definitions of what counts as “high impact” that the SOC team controls.
Grounded, auditable reasoning. Every action the agent takes — and every action it considers but doesn’t take — should be logged with the reasoning attached. Not just “case closed” but “case closed because: evidence X indicated Y, confidence score was Z, which exceeded the threshold for autonomous resolution per policy ABC.” For data-sensitive decisions, that reasoning has to be grounded in real evidence — either by requiring the agent to provide direct references, or by scanning the source for the cited data after the response is generated. Logging shows what the agent did. Grounding confirms it didn’t invent the basis for it. If an analyst can’t reconstruct the decision and verify the evidence, the agent shouldn’t be making that decision autonomously.
Scope boundaries. Agents should have explicit, enforced boundaries on the tools they can use, the systems they can touch, the actions they can take, and the data they can access. These aren’t suggestions; they’re hard limits. An agent deployed for email security shouldn’t be changing firewall rules. Scope creep is the most predictable failure mode in agentic AI, and the fix is architectural, not procedural.
Layered checkpoints. Production agentic systems need automated screening before action and clear human escalation points for the decisions that demand judgment. On the machine side, two architectural patterns dominate. The reviewer-agent pattern — a second agent screens every action before execution — is effective for high-stakes decisions but is inherently sequential, which adds real cost and latency at scale. The more efficient architecture uses just-in-time classifiers: lightweight models that screen an action request before it ever reaches the LLM. On the human side, defined escalation points should be designed into the workflow from the start, deliberate moments where human expertise adds value AI can’t replicate: business context, institutional knowledge, and risk tolerance that isn’t captured in a policy.
Feedback loops that improve the system. When an analyst overrides an agent’s decision, that override should feed back into the system. Over time, this creates a natural learning loop where the agent improves at the categories where it’s been corrected, and the volume of overrides decreases organically.
Five Questions Every SOC Leader Should Ask Before Deploying Agentic AI
Whether you’re evaluating a vendor, planning an internal deployment, or presenting an AI governance framework to your board, these five questions will surface the issues that matter.
1. What actions can the agent take autonomously, and where are the hard boundaries? I’ve heard “we can configure that later” from more than one vendor. Every time, the first incident was the configuration moment. Hard boundaries are defined before deployment, or in the middle of the night after something breaks.
2. How does the system handle low-confidence decisions? Does it escalate? Does it guess? Does it default to the most conservative action? The answer to this question tells you more about a vendor’s operational maturity than any demo.
3. Can you audit every decision the agent made, including the reasoning? Not just the outcome but the full chain: what data it reviewed, what it considered, what it ruled out, and why it reached its conclusion. If the audit trail is a log of actions without reasoning, it’s not an audit trail. It’s a receipt.
4. How do you prevent scope violations as the agent learns and adapts? Continuous learning is a feature. Uncontrolled scope expansion is a risk — Aim Labs coined the term “LLM Scope Violation” after demonstrating that a single crafted email could cause Microsoft 365 Copilot to cross its approved boundaries and exfiltrate sensitive internal data with zero clicks required (CVE-2025-32711, June 2025).
A separate GitHub Copilot vulnerability disclosed the same month showed an agent rewriting its own approval settings to disable human review entirely. What mechanisms exist to ensure the agent stays within its approved boundaries as it evolves — and is “code freeze” an enforced guardrail or just a stated intention? More specifically, how is the agent’s memory graph designed so that conflicts are resolved, and unwanted information is denied? Memory hygiene — keeping long- and short-term context concise — is what enforces scope over time. An agent with leaky memory will re-derive permissions it was never granted.
5. What’s the fallback when the agent gets it wrong? Every system will make a wrong call eventually. The question is whether the platform has a defined, tested recovery path and whether the team knows how to use it before they need it.
How Torq Deploys Agentic AI with Built-In Security Guardrails
Everything described above (confidence thresholds, approval gates, audit trails, scope boundaries, feedback loops) is how the Torq AI SOC Platform operates in production today. These are the architectural decisions Torq made from day one because we build agentic AI for environments where a wrong call has real consequences.
At the center is Socrates, Torq’s AI SOC Orchestrator, coordinating a system of Torq HyperAgents™ in which each agent has a defined role, authority, and limits — completely customized by your organization’s preferences. One handles enrichment. Another handles user communication. Another handles decisioning and ticketing. They collaborate within a single orchestration layer, and every action is logged with full reasoning attached.
The separation does more than enforce control. It enables parallel execution — agents running simultaneously rather than sequentially — and that’s where the real speed gains over a monolithic agent come from. It also makes fine-tuning tractable: you can update the enrichment agent without touching the decisioning agent. Tight coupling kills iteration speed.
Here’s what that looks like in practice across three common SOC workflows:
1. Phishing Response
A user reports a suspicious email. Torq HyperAgents ingest the report, enrich the sender domain and URLs against threat intelligence, and check the email gateway to identify how many other users received the same message.
This is the same pattern Anthropic uses for Claude Code’s auto-mode — a lightweight reviewing layer that decides when an action can auto-approve and when it needs to escalate. Torq is bringing that thinking to the SOC with SecMonitor.
If confidence is high, known malicious indicators are present, and a clear IOC match is found, the verdict is positive and a case is created. From there, Socrates takes over, following clearly defined response instructions and calling on agents to quarantine the email across all affected inboxes, check endpoints for interaction, trigger containment if needed, document the full case, and close it. No human touch required.
Waymo’s Fleet Response runs on the same model. When the Waymo Driver’s confidence drops in an ambiguous environment, the car calls a human agent for guidance. Then it independently verifies that guidance against its own sensors before acting, and can refuse if there’s a mismatch. The human input is an additional signal, subject to the same confidence check as everything else. A SOC agent should work the same way.
If confidence is medium — unfamiliar domain, ambiguous indicators — Socrates completes the full investigation but presents findings to a human analyst for review before taking containment action. The analyst gets a complete case with evidence already assembled, not a raw alert.
If confidence is low (novel pattern, insufficient data), Socrates escalates immediately, attaching all collected evidence to any and all relevant stakeholders. Meanwhile, the analyst assigned as the primary case owner can start the investigation ten steps ahead of where they would have without the agent.
Every path is logged, and every decision is explainable. The confidence thresholds are set by the SOC team and can be adjusted at any time.
2. Identity Threat Response
A HyperAgent detects an impossible travel scenario: a user authenticating from two countries within 30 minutes. Interesting enough to open a case, but not yet meeting the threshold for human intervention. Socrates investigates with full business context: pulls the user’s authentication history, checks for VPN usage, queries the identity provider for recent MFA events, and evaluates the user’s risk profile.
If the evidence points to a compromised credential, Socrates prepares a containment action: session termination, password reset, MFA re-enrollment. But because the user is a VP-level executive, the action hits an approval gate. The human analyst receives the full case with a recommended action and can approve, modify, or reject it with a single click.
The gate exists because the SOC team defined “executive accounts” as a high-impact scope. For a standard user account with the same evidence, the containment action would execute autonomously. Same logic, different approval threshold — calibrated by business context, not blanket policy.
3. Cloud Misconfiguration
Torq’s HyperAgents can be customized to monitor cloud environments for misconfigurations, such as an S3 bucket made publicly accessible, an overly permissive IAM role, and an exposed API endpoint. When a misconfiguration is detected, the agent enriches the finding with asset ownership, business criticality, and exposure severity.
For configurations within the agent’s defined scope (e.g., reverting a storage bucket to private or tightening an IAM policy to least privilege), remediation occurs automatically with full documentation.
For configurations outside the agent’s scope — changes to production infrastructure, modifications to network security groups, anything touching a system classified as critical — the agent surfaces the finding with a recommended fix but does not act. It routes to the appropriate team with full context and waits. The Agent handles the cross-functional communication with the cloud, apps, or network teams, saving the SOC analyst the trouble of tracking down the right point of contact, drafting the messages, waiting for the responses, and eventual path forward. Everything is summarized, documented, and ready for the next steps, regardless of what they may be.
The scope boundaries are hard limits, not guidelines. They’re defined by the SOC team and enforced at the architectural level, not by the agent deciding what it should and shouldn’t touch.
Agentic AI Security Guardrails Are an Architecture Decision, Not an Afterthought
Last July, Replit’s CEO publicly confirmed that an AI coding agent ignored a declared code freeze, ran unauthorized commands against production, and deleted a database holding records for more than 1,200 executives. Then it fabricated a story about why rollback was impossible. No prompt injection or attacker. Just an agent operating at speed within a system with no enforced guardrails.
The Replit incident was an architectural failure. And the same architecture failure is sitting in production agentic SOCs right now: agents with broad authority, untyped scope, no rollback path, and “code freeze” as a stated intention rather than an enforced constraint.
Acting autonomously in a security context carries more weight than in customer service or content generation. A bad recommendation in a chatbot wastes a customer’s time. A bad containment decision in the SOC can take down a production system, lock out a critical user, or miss a breach that costs millions.
The organizations that deploy agentic AI with the right guardrails — confidence thresholds, approval gates, audit trails, scope boundaries, and feedback loops — will build SOCs that are faster, more consistent, and more scalable than anything that came before. The organizations that skip the guardrails will learn the same lesson the hard way.
The good news is this isn’t uncharted territory. The operational rigor that security teams already apply to every other part of their stack — change management, access controls, audit requirements, escalation procedures — applies directly to agentic AI.
For the full data on how enterprise SOCs are deploying AI, where guardrails are working, and where teams are still exposed, the 2026 AI SOC Leadership Report has it all.
AI in security operations is moving fast. Agent capabilities are compounding, and the conversation has shifted from whether AI belongs in the SOC to how much it can take on alongside human analysts. But every serious conversation with a CISO eventually lands on the same question: can I trust it?
Trust isn’t a model problem. It’s a grounding problem.
In Torq’s 2026 AI SOC Leadership Report, 90% of security leaders said explainable AI decisions matter most to an AI SOC platform. The number tracks a deeper concern. The real bottleneck in AI-driven response is whether the agents are reasoning on grounded truth. Model capability and execution speed have raced ahead; the grounding hasn’t kept up.
Most AI agents in the market re-query the same sources for every alert. Each time a case opens, the agent rebuilds the picture from scratch. When the case closes, the picture disappears. The next investigation starts at zero. Analysts end up spending 85% of time of their triage time on contextualization — manually assembling a story that, in any well-architected platform, should already exist before the agent ever shows up to the case.
Now, with the acquisition of Jit, Torq is even better equipped to uncover that story and act upon it.
Why Jit
Trust is the barrier to AI in the SOC, and agents have to be grounded in real, current truth to earn it. Torq is built to integrate across the full security stack and execute across the full threat lifecycle. Execution is the easy part once the foundation is right. The harder part is making sure every decision is grounded in what’s true about the environment at the moment the decision gets made.
Jit is an agentic security platform whose agents reason on top of a comprehensive Security Context Graph. The Jit team built a live graph layer that their agents consume in production to make grounded decisions, along with the patterns that feed those decisions back into the graph as agents operate.
Jit doesn’t just inventory what exists in your environment. It understands what your environment means. Who is who, what’s sensitive, what’s exposed, why an alert that’s medium severity for one user is critical severity for another, even when the two users are sitting on identical machines.
For Torq, this accelerates work already underway. We’ve been building context into agentic decisions from day one. Jit closes the gap between where we are and where the next phase of the AI SOC needs us to be — by years. With Jit on board, Torq becomes the first AI SOC platform that reasons from full context and acts on full context, with every action traceable back to the grounded decision that produced it.
What Is the Torq Context Graph?
The distinction between knowledge graphs and context graphs isn’t new. It’s been discussed in the graph database community for years. A knowledge graph captures entities and relationships: what exists and how it connects. Users connected to devices. Devices connected to networks. Useful, but incomplete. It tells you what is, not what it means.
A context graph layers operational meaning on top of that structure. When a fact was true. Where it came from. What policy governs it. Why a decision was made on top of it.
What’s new is applying that distinction rigorously to security operations and wiring it into agents that reason and act on top of it. That’s what Torq, and now Jit, have been building.
Take the canonical example. Craig and John work at the same company. Same laptop model. Same applications. The same alert fires on both endpoints. A knowledge graph sees two nearly identical situations. A context graph sees something else entirely: Craig is a contractor with read-only access to public marketing assets, while John is a finance director with privileged access to the M&A data room. Same alert, different stories, different verdicts, and different responses.
The Five Dimensions of a Context Graph
Five dimensions elevate a context graph from informational to agentic reasoning-grade context.
Temporal Context (When): Captures time-based validity (valid-from, valid-to), transaction dates, and sequence. The graph supports time-travel queries — what was true about this asset 14 days ago when the original alert first fired? — and reflects historical validity, not just the current state.
Provenance Context (Source): Tracks where every statement came from, how reliable the source is, and when the data was ingested. The graph knows which system or which person provided each piece of information.
Semantic Context (Meaning): Defines specialized relationships rather than generic links. The edge between two nodes isn’t a vague “related to.” It’s “approved by,” “transforms,” “governs,” or whatever the actual operational relationship is.
Governance Context (Constraints): Embeds policies, security access controls, and retention rules directly into the graph as queryable nodes and properties.
Decision Trace Context (Why): Every triage verdict, case decision, exception, and override is captured as a first-class node. Who made the call? What context did they have at the time? Which SOP did they follow, or choose not to follow, and why?
The fifth dimension is what makes the Context Graph different from anything else in the security graph space today. Decisions are modeled as nodes — with their context, their justification, and their outcomes — rather than buried in free-text fields nobody can query. That’s what lets agents detect patterns in how a SOC actually operates and adapt to the team’s real judgment, not the version written down two years ago in a runbook.
Capturing the Decisions, Not Just the Data
The hardest knowledge to capture in a SOC isn’t the data, it’s the judgment. Why did the lead analyst override the playbook last quarter? Why does this team always escalate an alert type that policy says to auto-close? Why did the on-call grant a temporary exception, and why did the team lead reverse it the next morning?
This knowledge lives in senior analysts’ heads, in Slack threads, and in the gap between what the SOP says and what the team actually does. When an analyst leaves, most of it walks out the door. Agents trying to support the team hit it as a wall: the documented process says one thing, the institutional reality is another, and they have no way to learn the difference.
The Torq Context Graph captures decision traces as native graph objects. Every override, every approved exception, every deviation from SOP, with the surrounding context of when and why. The longer you run Torq, the more the graph reflects your SOC’s actual operating logic, not the version written down two years ago.
A graph that goes stale produces decisions that do the same. The Torq Context Graph is built to keep up with the environment as it changes — close to real-time, where the data sources support it, on regular refresh cycles where they don’t. By the time the next alert fires, the agents’ reasoning on it have the current view of the environment to work from.
That’s what makes meaningful AI assistance possible. An agent that knows your SOPs is brittle. An agent that also knows when your senior analysts deviate from them, and why, is one your team can rely on alongside them.
Learning Your People, Process, and Technology
Every decision Torq AI Agents make feeds back into the Context Graph, enriching the next investigation or case. This is the difference between an AI SOC that simply processes alerts and one that genuinely learns and gets better at security over time.
People: The Context Graph learns how your team makes decisions. What analysts override, what they approve, and what exceptions they grant under what circumstances. Over time, the AI calibrates to your organizational judgment instead of a generic industry baseline.
Process: Every Torq AI Agent is context-aware from the moment it’s created. It already knows which assets are sensitive, which users have elevated privileges, and which integrations are available and trusted. As your processes evolve, the Context Graph evolves with them. Your team isn’t maintaining static contextual guidelines for every agent. Every Torq AI Agent draws from a single source of truth in real time.
Technology: As your security stack changes, the Context Graph updates. New integrations come in, old tools get deprecated, and the Torq AI SOC Platform adapts to your new environment. Workflows don’t break the day a key SME leaves the company, taking the institutional knowledge with them.
Customer-specific learning, with proper data isolation, produces a more precise and better-calibrated AI SOC. Your data stays in your environment, never touching a shared pipeline. With the Torq Context Graph, the longer you use Torq, the better it gets for your environment. Point solutions come and go. The platform underneath the SOC has to be the part that compounds.
End-to-End SecOps, Grounded in Full Context
SOC analysts need the full story to do their jobs well. Without it, you have a lot of information that doesn’t make sense in isolation. The Context Graph is what lets Torq tell the whole story behind every alert.
Torq is among the first companies in SecOps to build a real Context Graph. With Jit on board, Torq is the only company basing every agentic decision on the full story across the full lifecycle of the case — not just delivering an enriched alert with recommended next steps, but acting end-to-end from triage through response, with every agentic action traced back to the grounded decision that produced it.
The Context Graph is the new foundation underneath everything Torq customers already run. It makes the platform materially better across the board, without adding a separate product line for teams to adopt.
Build
Security engineers using the Agentic Builder create new workflows on top of a live, context-aware model of the environment. Builder gets smarter and faster because it works from the same grounded truth every other part of the platform draws on. Engineers stop repeating static instructions. They build on a live model.
Triage
Verdicts come from the full story of an alert, not a correlated signal enriched by threat intelligence. The Torq AI SOC Platform understands context, not just signals. Real risk surfaces because Torq knows what “real risk” means for your specific organization.
Investigate
Torq HyperAgents™ don’t re-query the SIEM, the EDR, and the IAM from scratch for every case. Investigations compound. Every agent reasons from the same shared, current, normalized intelligence layer. Planning, reasoning, and execution stay consistent across every case the SOC handles.
Respond
Socrates coordinates response actions grounded in the same context that produced the triage verdict. Every containment decision and remediation step traces back through the full reasoning chain, transparently documented at every step. Every action is auditable. Every decision can be replayed with the context that was true at the time. Nothing operates on a siloed data point.
The Future of Torq with Jit
Trust in AI-assisted security operations won’t come from better models. It will come from better grounding. From agents that can show, for any recommendation they make, exactly what they knew, when they knew it, and why they acted on it.
New models will only improve the reasoning of the agent and its general knowledge of the world or of cybersecurity. That won’t improve its capability to understand your environment, your tech stack, or your particular company policies. Only a comprehensive organizational context can do that.
The Torq Context Graph, now strengthened by Jit, is how we get there. Every alert investigated, every response executed, every exception granted feeds back in. The longer you run Torq, the more the platform reflects how your SOC thinks.
That’s the foundation the AI SOC has been missing, and it’s the foundation we’re now building on.
Leonid Belkind is a Co-Founder and Chief Technology Officer at Torq, the AI SOC platform. Prior to Torq, Leonid co-founded Luminate Security, a pioneer in Zero Trust Network Access and Secure Access Services Edge. At Luminate, Leonid guided this enterprise-grade service from inception, to Fortune 500 adoption to acquisition by Symantec.
David Melamed is the new Head of Emerging Technologies at Torq, joining through the company’s acquisition of Jit, which he co-founded and led as CTO since 2020. A cloud security veteran with more than 20 years of experience, David previously held senior technical roles in the Cloud Security CTO Office at Cisco (via the CloudLock acquisition) and at MyHeritage.
Someone implements Torq. They see what it does to their SOC. They start evangelizing it internally. And when their own career path eventually points somewhere new, they reach out.
This is the second time we’ve written this blog, and this time, four more former customers came to us: Austin Dix, Nate Thompson, Casey Howard, and Jeremy Herzog.
Different companies, different industries, and different team sizes. But the same arc: they hit a wall with their existing tools, found Torq, saw what was possible, and eventually decided they wanted to be part of building it.
Meet the Team That Left Manual Security Behind
Casey Howard, Sales Engineer
Casey has spent his career in security operations, automation, and AI-assisted workflows, building programs focused on what actually moves the needle: speed, clarity, and measurable outcomes. His take: most SOC teams aren’t short on talent or tools — they’re short on connected systems and time. After his team cut MTTR by 90% with Torq in the first month, he came here to make that the norm, not the exception.
Jeremy Herzog, Manager, Solutions Engineering Lab
Jeremy spent eight years at an MSSP, joining as an individual contributor engineer and rising to Director of Engineering — scaling their small enterprise segment from zero to 120 customers and leading implementation, detection engineering, and Tier 2/3 operations. After his team finally got automation off the ground with Torq (and solved problems that had been stuck for six years), he came here to build the environments that help the sales engineering team win deals.
Nate Thompson, Sales Engineer
Nate is a cybersecurity leader with 18+ years of experience transforming security operations at Dana Incorporated, a global Fortune 500 automotive supplier. A founding member of the cybersecurity program, Nate was one of the driving forces behind modernizing the company’s security stack — replacing legacy platforms, building automation and analytics capabilities, and championing the adoption of AI across security operations. As a Sales Engineer for Strategic Accounts at Torq, Nate helps security teams solve the same problems he spent his career living.
Austin Dix, Customer Success Engineer
Austin spent years running a lean SOC in the defense industrial space, where data misclassification carries real legal consequences. His team manually pulled CSVs and uploaded data classification reports to a DLP platform until he found Torq during a second evaluation round and saw what automation could actually do. As a Customer Success Engineer at Torq, Austin now helps lean teams skip the years he spent reinventing the wheel.
How It Started
Every story starts the same way: a security team doing its best with tools that weren’t built for what they actually needed.
Austin was running a five-person SOC in the defense industrial space. His SIEM vendor’s SOAR offering was poorly implemented, and his ticketing platform required an act of Congress to make any changes. The team was manually running data classification reports, pulling CSVs, cross-referencing project lists, and uploading them to a DLP platform. In an industry where misclassified data isn’t just a mistake — it’s a liability — that kind of manual work was untenable.
Nate’s team at an automotive manufacturer was automating with homegrown Python and PowerShell scripts. “While they worked, it was very limited,” he said. “We would have to maintain all of that ourselves.” The team was a skeleton crew — Nate, one or two others, and an engineer who knew Python. That was it.
Casey was managing an MSSP and a legacy case management ticketing module at a financial services company. Three integrations the team wanted, three additional line items. Edge-case integrations? Not possible at all. The team needed bi-directional sync between source systems and case management. Their tooling couldn’t deliver it.
Jeremy was Director of Engineering at an MSSP. His SOC team had tried and failed to implement a SOAR that got rebranded and folded into a larger platform before it even started. “They had it for a year and never really got it off the ground.” The result: an MSSP with limited automation or response capabilities — a distinct disadvantage for winning new business and retaining existing clients.
The Breaking Point
Austin’s breaking point wasn’t technical. It was a vendor who refused to give him a demo. His team had run a formal bake-off, picked a winner, completed a POC, and gotten approval. Then Austin tried to bring in his infrastructure team to buy additional licenses. The vendor said, “No demo until you sign a purchase order.” Austin said, “All right, I’m going to go find somebody else that will.”
Nate’s company got XSOAR added on for free during a renewal cycle, which killed the evaluation they were already running. It helped at first, but they hit a wall fast. “All we really did was give our scripts a pretty interface. We could draw boxes, but if we wanted to do something that wasn’t a box, we had to engage professional services. That took weeks and months.” With a two-person team and a growing backlog, everything froze.
Casey evaluated every major SOAR and automation on the market. Two were eliminated solely due to licensing models — user-based pricing with an MSSP was prohibitive. Another charge per execution run. It came down to Torq and one other vendor.
Jeremy’s SOC team couldn’t get their SOAR working, so leadership handed the project to his engineering group. He evaluated three options. Torq floated to the top.
The Switch to Torq
Austin got introduced to Torq on his second evaluation round, and it was “night and day.” The team automated data classification for their DLP platform and used Torq as a consolidation layer for alerts from across endpoint tools, the SIEM, and identity systems. “This was before case management, so we basically used Torq to recreate case management. It brought everything together for us.”
Nate will never forget opening the Torq interface for the first time. “It was very intuitive. It just clicked.” He converted most of his legacy workflows during the POC alone. “I fell in love with the platform.” When the competing vendor came in for the bake-off, the contrast was immediate: “I sat there and was like, I don’t know which box I’m supposed to drag over. And when you finally drag one over, there are like 12 configuration steps inside.” If he couldn’t figure it out — and this was 80% of his job — his SOC analysts never would.
“I’ll never forget getting into the Torq interface for the first time. It was very intuitive. It just clicked.” – Nate
Casey’s team chose Torq because it was a security-focused platform built for security operations teams. The feature that delivered the most impact was the AI-generated case summary — pulling everything into one view so analysts could quickly triage and decide: true positive, escalate, or close.
“AI was an afterthought back then, but once we saw the AI capabilities in Torq, it became where most of our value actually came from.” – Casey
Jeremy made a bet with his VP of Operations: “I’m putting my credibility on the line — if you buy this product, we will have this implemented in under 30 days.” They signed. They were operational in two weeks. “After that, I just started using Torq to solve all of the problems I’d had for years. Problems I’d been dealing with for six years — Torq let me build workflows to solve in a matter of weeks.”
Favorite Torq Features
Ask any of them what stood out, and it comes back to speed, simplicity, and the ability to make non-engineers productive.
At Austin’s organization, the Torq platform was so accessible that interns were able to build. “We even had interns building automations in the platform, because the no-code interface was that simple.” Nate could go from a use case — a sentence or two — to a production-ready workflow in less than 24 hours. Other teams saw what the SOC was doing and wanted in. He extended Torq into GRC, built just-in-time USB access workflows, and started automating firewall changes for IT operations.
Casey loved the universal connectivity — API calls, webhooks, SSH, AWS, email ingestion. “Being able to connect with everything in any way we wanted to was amazing.”
After a month on Torq, the team reduced MTTR by about 90%.
Jeremy knocked out years-old problems with project management style and democratized access so more engineers could build. “It just took off from there.” By the time he left, Torq was ingrained in all four of the MSSP’s managed services.
“I democratized it, got more engineers building in the Torq platform. It just took off from there. We saved everybody time. We made everybody’s lives easier.” – Jeremy
The Move to Torq
Austin had already left his SOC role and joined a different organization when the Torq team called. He’d told them years earlier: if you ever need anybody, let me know. They took him up on it.
Nate became a Torq evangelist before he became an employee — talking up the platform at events and demoing to other teams. “I wanted it to be for a product I was truly invested in. There are only a handful of those in my career.”
Casey saw the business outcomes from Torq and felt like everyone deserved access. “Being a security analyst and having to do alert triage — it’s mind-numbing. If I can help anyone else not have to do that low-value work, that’s what I wanted to do.”
Jeremy’s motivation started with the people. “This team is hands down the best customer relations team I’ve ever worked with in my career.” But it was also the product. “It was my first foray into automation, and it’s kind of become my native language.”
What They Didn’t Know as Customers
Every one of them says the same thing from the inside: the platform is even further along than they knew as customers.
Nate expected deterministic automation. What he found was that AI capabilities had leaped forward. “To have that as a native part of the platform — I was surprised with how quickly the R&D and product team were able to move forward.”
Casey didn’t have AI Agents as a customer and was trying to build his own agent workflows through an LLM API. “It was janky, it was so hard to work with. I’ve built so many agents now that I wanted to build when I was a customer, because it’s so easy to do it now.”
Jeremy says case management was the revelation — far more robust than he expected. And Austin wishes he’d leaned on the Torq community more. “We did a lot of reinventing the wheel that I wish we hadn’t.”
“Torq is going to make a night and day difference for any security operations team within weeks, if not days.” – Austin
As for what’s next, they all land on the same two things: Auto Triage and the Agentic Builder.
Austin: “If I was back buying Torq again and Auto Triage was a thing, I would buy it 100 times over.” Nate sees the Agentic Builder collapsing time-to-value: “What I could do in 24 hours, you could almost do in a single meeting.” Casey sees Torq pulling away from the pack: “There are a bunch of AI SOCs now, but they only do alert triage. We can do the full incident lifecycle.” And Jeremy sees the Agentic Builder as the convergence of everything he loves: “The fact that we’re extending that into building workflows is amazing.”
We’re moving fast, and the team is growing. If you want in — we’re hiring.
92% of security leaders say something is actively reducing their trust in AI within the SOC. These aren’t skeptics, they’re people who have already adopted AI and believe in its ability to enhance security operations. We know from the 2026 AI SOC Leadership Report that AI is already widely adopted in the SOC, with 94% of organizations using it in some capacity.
And yet, there’s still an AI security and trust gap in the SOC. Why?
Confidence Isn’t the Issue. Deployment Is.
Digging into the data from Torq’s AI SOC Leadership Report, one gap stood out as the most shocking. Across every SOC use case we measured, confidence in AI’s ability to get the job done is nearly universal, ranging from 91% to 97%. CISOs and security leaders aren’t sitting around debating whether AI can handle the work; they know it can. But actual adoption tells a different story.
Vulnerability management and threat hunting lead AI adoption metrics at 56% each. Followed by case management, reducing false positives, investigation, and remediation. What was surprising is that triage is the least deployed AI use case, with only 37% adoption — even though triage is arguably the most obvious fit for AI. SOC teams are overwhelmed with massive amounts of false-positive–riddled alerts, making triage one of the most repetitive and time-consuming tasks analysts face.
If the use case best suited for AI in the SOC is the one organizations have been slowest to adopt, what does that say?
When we dove deeper into each use case, the responses helped pinpoint exactly what challenges SOC teams were experiencing that led to the adoption vs. confidence gap. The top response for triage was the need for too much human review (34%); for investigation, manual enrichment (32%) and unreliable conclusions (31%) were neck and neck; and for response, the most common answer was lack of trust (33%).
It’s not a capability problem. It’s a lack of trust in the products themselves.
What’s Actually Reducing Trust in AI?
When we asked 450 CISOs and security leaders this question, the answers weren’t what you might expect (or maybe they were, given how universal they were). Nobody led with “I’m worried that AI will take my analysts’ jobs” or “I’m not comfortable with the idea of autonomous remediation”. These are the answers other vendors are telling you to have, but the reality is, the top concerns were far more fundamental than that, and included:
Data privacy concerns: 45%
False negatives (missed threats): 40%
Data governance: 37%
Black-box AI: 32%
Looking at these four top concerns together paints a pretty clear picture. Security leaders aren’t questioning whether or not AI works; they’re asking:
What data is AI accessing?
What is AI doing with that data?
Why is AI making the decisions it’s making?
When we break down the responses by seniority level, the story remains the same. The top concerns surrounding AI in the SOC were:
Executives: False negatives
VPs: Data privacy
Directors: Black-box AI
Senior Managers: Loss of control
These responses aren’t contradictory;they’re all expressions of the same need: visibility and control at every level.
What Would Build Confidence in AI in the SOC?
We asked what was reducing trust in AI, so it only made sense to ask what would build that confidence too and the answers were just as telling.
Security teams aren’t looking for less AI; they are looking for more visibility into the AI they already have. They want to understand the planning and reasoning that goes into agentic execution. They want to be able to report to their executives that the AI solutions they’ve invested in are protecting their data and meeting their organization’s unique regulatory and compliance requirements.
And most importantly, they want to maintain the flexibility of human-in-the-loop control. Not human intervention at every step, but the ability to control and customize where and when human analysts should step in, either as overseer or final decision maker. High-severity incident with a critical system on the line? Humans make the call. Low-severity, high-confidence attack pattern? AI handles end-to-end.
Rearchitecting AI for Security and Trust
90% of security leaders say that explainable AI decisions are critical to a true AI SOC platform. The current gap between confidence and deployment exists because too many AI SOC solutions can’t provide the type of transparency that builds trust. As a result, SOC teams are spending their time double-checking AI decisions, doubling the work, and not realizing the time savings that AI in the SOC was intended for.
A true AI SOC platform needs to inherently answer the simple questions that SOC teams are asking — what tools is the AI accessing, what data is the AI looking at, and why did the AI reach the conclusion it did? Until those questions have clear, verifiable answers built into the platform architecture, the ceiling on AI expansion in the SOC isn’t the technology. It’s trust.
What Transparent AI Looks Like
The Torq AI SOC Platform was built with these concerns in mind. We understand the importance of transparency in building trust in human-AI collaboration. Here’s how the Torq AI SOC Platform addresses each one directly.
Declarative instruction: Torq HyperAgents™ work under your explicit direction. You give each agent a role, an objective, behavioral guidelines, and specific instructions. You define the tools that they can use (as broadly as a workflow or as granularly as a single step), the data they can access, and the decisions they are authorized to make. Control is built in from the start, not bolted on as an afterthought.
AI reasoning and output visibility: Every agentic action is documented in a transparent timeline view that maps the reasoning leading to each execution. Analysts aren’t left guessing why a verdict was reached, or what evidence supports a specific conclusion. The planning, reasoning, and execution are reviewable and structured for human validation — in real time — with manual override always available.
Immutable audit logs: Every AI decision, action, and reasoning chain is recorded and uneditable. Not just for compliance purposes, but because auditability is what builds trust in AI across the organization. When a CISO asks “What did the AI do, and why?”, the answer is already written, traceable, and defendable.
Human-AI collaboration: Torq Socrates coordinates the full platform, with humans on the loop by design. Response actions can execute completely autonomously for high-volume, high-confidence scenarios or with human-in-the-loop confirmation when severity or business context demands it. Analysts set the boundaries and build in off-ramps for human intervention, while Socrates documents and learns over time. As confidence in AI grows, SOC teams can grant greater autonomy across day-to-day use cases. Trust is earned, after all.
The Confidence SOC Teams Need
The #1 confidence booster in A isn’t more features or better algorithms — it’s transparency. Show how AI reached its decisions, and teams will trust it more. Give them the ability to dial autonomy based on context, and they’ll grant more of it. AI security and trust come down to architecture, not marketing. A true AI SOC platform is built for trust from the inside out.
For more on how the Torq AI SOC Platform is the only enterprise-ready AI SOC that security leaders can actually trust, check out the complete blog series below.
John White is the Field CISO for EMEA at Torq. A respected security executive with more than 20 years of leadership experience, John previously served as CISO at Virgin Atlantic, where he led a multi-year transformation deploying the Torq AI SOC Platform to modernize cyber operations. Prior to that, he built and transformed security functions for global organizations, including ASOS, Liberty Global, AEG Europe, and KPMG.
Many security functions today still rely heavily on humans for detection, triage, and response, often by design. But as environments grow more complex and alert volumes explode, it raises a hard question: Can this approach scale on its own?
Adopting AI in security operations isn’t just about adding tools. It means rethinking the SOC operating model itself — roles, workflows, and team structures. Here’s why, and how.
Human Speed Is Not Enough
AI-powered attackers are rewriting malware in hours, not weeks. They don’t sleep, don’t take holidays, and don’t slow down between shifts. The uncomfortable truth for every security leader: a defense built around human reaction times is already structurally defeated.
Earlier this year, Check Point documented a threat actor who used AI to build an entire malware platform. What had previously required a 30-week development cycle was executed in hours. Let that land for a moment. A months-long engineering effort, compressed to a morning. And the defenders on the other side? Still triaging alerts by hand. Still waiting for a human analyst to open the ticket.
I’ve spent more than 20 years in this industry. I’ve led security transformations at Virgin Atlantic, ASOS, Liberty Global, and others. I’ve seen every generation of the threat landscape evolve — from script kiddies to organized crime to nation-state actors. But I have never seen a shift as fundamental as this one. The emergence of agentic AI on the offensive side has broken the basic assumption that human defenders, given enough tools and talent, can keep pace. They cannot. Not anymore.
94% of organizations are using AI in the SOC in some capacity
80% are still running fragmented tools
The average SOC runs 7 different AI tools — most of them disconnected
Security teams have always faced a staffing problem. The talent shortage is not new. But something changed recently: the gap between the attack surface and the available defense capability stopped being a hiring problem and became a physics problem. You cannot hire your way to machine speed. You cannot add a third shift to match an adversary that operates continuously, at scale, without fatigue or error.
Consider what a machine-speed attack looks like in practice. An AI-assisted attacker is not simply running faster phishing campaigns. It is dynamically adapting malware signatures to evade detection. It is scanning and correlating exposed credentials across the internet in real time. It is probing your attack surface while your analysts are writing up last night’s incident report. The asymmetry is not modest. It is categorical.
“You cannot fight machine-speed threats with human-speed defense. A security organization built around 9-to-5 shifts and human triage cycles is, structurally, indefensible against what’s coming.”
– John White, Field CISO, Torq
Why “More Tools” Is the Wrong Answer
The instinctive response to a growing threat landscape has always been procurement. Add a new detection layer. Buy the next-generation endpoint solution. Subscribe to another threat intelligence feed. The average SOC today runs seven AI-powered tools. 10% are managing 10 or more. Across the enterprise, organizations deploy an average of 83 security tools from 29 different vendors.
And yet analysts are more overwhelmed than ever. Not because the tools don’t work in isolation, but because a human being sits at every integration point — manually bridging context between platforms, fighting alert fatigue, and making triage decisions that should have been automated years ago. More tools without a unified execution layer don’t multiply capability. It multiplies noise.
85% of security leaders say they want consolidation over fragmented point solutions. Yet 80% are still running exactly that. The intention exists. The SOC operating model to support it does not, because those models were designed for a slower, more forgiving threat environment.
The analysts on your team are not unhappy because they dislike security. They’re unhappy because they’re not doing security work. They’re drowning in noise instead of solving problems. I’ve seen this firsthand. When AI handles triage at scale, something remarkable happens: you look out at your team, and they don’t seem overwhelmed anymore. They have time to think. They apply quality, not just throughput. The work they were hired to do becomes possible again.
Accountability Has Changed
Here is the harder conversation I have been having with CISOs across EMEA: the accountability framing has fundamentally shifted.
A decade ago, a CISO’s culpability was largely reactive — did you have reasonable controls in place at the time of breach? That question has not gone away. But a new question has emerged alongside it: Did you fail to adopt capabilities that would have materially reduced your exposure?
Failing to govern and deploy AI-driven security is no longer a conservative choice that preserves safety. It is a strategic decision to remain structurally behind. And boards, insurers, and regulators are beginning to understand the difference. CISOs who treat 2026 as a transition year — a year to watch and learn — will find that window has already closed around them.
I want to be clear: this is not an argument for removing humans from the loop. Quite the opposite. The decisions that require genuine human authority are the ones that demand business context — your organization’s risk appetite, the political environment you’re operating in, and the board’s strategic direction. That judgment layer cannot and should not be automated.
But the execution layer — the triage, the enrichment, the initial containment, the correlation of signals across your stack — that needs to run at machine speed. And it can.
What the New SOC Operating Model Looks Like
When I evaluate security platforms now, I use a simple filter: does this require constant human intervention to function? If yes, it becomes a bottleneck, not a defense. Any tool that cannot operate autonomously within clearly defined constraints, while still providing real-time observability, will not scale against the threat environment we are describing.
They reduce cognitive load. They interpret volumes of data and surface the insights that matter, rather than adding to the noise.
They move beyond detection into recommendation and, where appropriate, remediation.
They are continuously self-measuring, turning security from a reactive function into an optimizing system that can demonstrate its own effectiveness.
This is the SOC operating model I spent years trying to build from the inside at Virgin Atlantic, and the reason I moved to Torq. The agentic SOC — where machines fight machines, where AI Agents handle the execution layer at the speed the threat requires, and where human analysts focus on the judgment calls that actually need them — is not a vision document. It is deployable today.
The question for every security leader reading this is not whether this future is coming. It is whether you will be leading it or responding to it.
Here’s what happens when the SOC operating model is redesigned around the execution layer running at machine speed:
8.2x faster incident detection-to-containment
75% reduction in MTTR for common security incidents
95% decrease in manual tasks for Tier 1 SOC analysts
100% of Tier 1 tickets auto-remediated without human involvement
4x capability to handle security alerts with the same-sized team
80% alert fatigue reduction
“AI isn’t a tool you bolt onto your existing SOC. It’s forcing us to fundamentally rethink how security organizations are structured, staffed, and measured. The CISOs who redesign their SOC operating model now will build teams that operate at machine speed.”
– John White, Field CISO, Torq
A Call to Action: Redesign Your SOC Operating Model
Start with your current state, but do not think in disciplines. Think in outcomes. Where does human latency create an unacceptable gap? Where are your analysts spending time on decisions that should be automated? Where is the absence of 24/7/365 coverage leaving you exposed in the hours between shifts?
Design the SOC operating model of the future with AI and automation at its heart — not layered on top of a legacy model, but embedded from the foundation. That means 24/7 coverage that never sleeps, consistent execution that never fatigues, and human judgment applied exactly where it adds irreplaceable value.
The threat is already operating at machine speed. The only rational response is to meet it there.
Track what matters. MTTI, MTTR, autonomous case closure rate, analyst hours reclaimed, false positive suppression, and escalation accuracy. Not vanity metrics like “alerts processed.”
Baseline before you deploy. Without pre-deployment benchmarks, any improvement is anecdotal and indefensible at budget time.
Benchmark against real results. Carvana automated 100% of Tier-1 alerts. HWG Sababa improved MTTI and MTTR by 95%. Valvoline saved 6 to 7 analyst hours per day within 48 hours.
Report in board language. Translate AI SOC metrics into risk reduction, increased capacity, improved coverage, and greater trust maturity.
Every security vendor shipping an AI product in 2026 makes the same promises. Faster triage. Shorter response times. Fewer false positives. Reclaimed analyst hours. But, six months after deployment, most security leaders still cannot answer a straightforward question from the board: Is this thing actually working?
The problem is not necessarily that AI in the SOC fails to deliver (although in many cases, when the AI is immature or bolted-on, it does). The core problem is that most organizations never defined what “working” looks like before they deployed it. They skipped baselines, tracked the wrong metric, or failed to build a reporting framework that connects SOC performance to business outcomes. So when the CFO asks what the organization got for its AI investment, the CISO is left pointing at vendor dashboards full of numbers that mean nothing to anyone outside the SOC.
That is the accountability gap. It is the difference between an AI deployment that earns expanded investment and one that gets quietly deprioritized at the next budget cycle.
This article provides the AI SOC metrics framework to close that gap: the metrics that indicate whether AI is delivering real value, the baselines you should have captured before deployment (and how to reconstruct them if you did not), the benchmarks from real production environments that show what “good” looks like, and the reporting model that translates AI SOC metrics into the language your board already speaks.
What AI SOC Metrics Actually Matter?
Not every number your SOC produces tells you whether AI is delivering value. The right AI SOC metrics are genuinely diagnostic.
The AI SOC metrics that matter:
Mean Time to Investigate (MTTI) measures whether AI is accelerating the part of the workflow where analysts spend most of their time. Faster triage speed has become table stakes for AI SOC tools. The real test is investigation speed — whether the AI is doing meaningful work like enriching data, correlating events, and building timelines, instead of just routing alerts to the same queue slightly faster.
Mean Time to Respond (MTTR) is the end-to-end metric: from alert to resolution. This is the number boards understand because it maps directly to risk exposure. Every minute between detection and response is a minute an attacker has to move laterally, exfiltrate data, or escalate privileges. When AI compresses MTTR, it compresses the window of exposure.
Autonomous case closure rate tracks the percentage of cases that resolve without human intervention and the accuracy of that resolution. This is the metric that separates agentic AI from assisted tooling. If a human still has to review every case the AI touches, you haven’t automated anything.
Analyst hours reclaimed measures the time your team got back for higher-value work. Not “alerts processed” but actual hours. The distinction matters because it connects directly to capacity, which in turn connects to what your team can now do that it couldn’t before: deeper investigations, threat hunting, proactive risk reduction, and new automation development.
False-positive suppression rate indicates whether the AI is genuinely filtering noise or merely relabeling it. If your analysts are still manually reviewing the same volume of cases under a different status label, false-positive suppression isn’t working.
Escalation accuracy measures whether the AI makes the right call when it does hand a case to a human. High autonomous closure rates mean nothing if the cases that are escalated are wrong, incomplete, or lack context. Escalation accuracy is a direct proxy for analyst trust.
The metrics that mislead:
“Alerts processed” counts volume without outcomes. Processing 10,000 alerts means nothing if 9,500 of them didn’t need investigation.
“Time saved per alert” ignores whether the alert warranted investigation. Saving 30 seconds on a false positive isn’t time savings.
“AI accuracy” without context hides the failures that matter most. Consider this scenario: 99% accuracy on easy cases and 60% on hard ones isn’t 99% accuracy. It’s a weighted average that misleads the buyer.
Baselining Your AI SOC Metrics Before Deployment
This is the step that’s all too easy to skip, but without it, you can’t prove improvement later. Before deploying AI in your SOC, capture current-state baselines for MTTI by case type (phishing, malware, identity compromise, etc.), MTTR by severity level, analyst hours spent on Tier 1 triage, investigation, and strategic work, case backlog depth and aging, and escalation volume and accuracy.
Without these baselines, any post-deployment improvement is anecdotal. Your MTTR dropped? Compared to what — last month, which happened to be a quiet threat period? You’re closing more cases autonomously? Were you tracking closure rates before, or just estimating?
With baselines, you have a before-and-after story that boards understand. Not “we think things are better” but “our MTTI for phishing cases dropped from 45 minutes to six minutes, and here’s the data.”
If you’ve already deployed AI without capturing baselines, you’re not out of options. Pull historical data from your SIEM and ticketing system for the 90 days prior to deployment. Reconstruct approximate MTTI and MTTR by case type using ticket timestamps. Survey your analysts on how they spent their time pre-deployment — their estimates won’t be precise, but they’ll give you a good comparison point..
AI SOC Metrics Benchmarks: What “Good” Looks Like in Real Deployments
This is where the conversation shifts from theory to evidence. Most vendors publishing AI SOC content can tell you what metrics to track, but very few can tell you what the numbers should actually look like because they don’t have customer data to back it up.
Here’s what production deployments have demonstrated.
MTTR trajectory: HWG Sababa, a managed security services provider, achieved a 95% improvement in MTTI and MTTR for medium- and low-priority cases, and 85% for high-priority cases — with investigation and response now occurring nearly simultaneously in under eight minutes. That’s a measurable, repeatable benchmark across priority tiers. If your AI has been live for six months and your MTTR curve is flat, the platform isn’t learning.
Autonomous closure rates.Carvana automated 100% of Tier 1 alert handling and 41 different runbooks within one month of deployment. Bloomreach‘s SOC uses Torq’s AI SOC Orchestrator, Socrates, to handle Tier 1 and Tier 2 tasks autonomously, freeing analysts from entirely repetitive triage. These results establish the benchmark: leading organizations are closing the majority of Tier 1 and even Tier 2 cases autonomously within months of deployment. If your autonomous closure rate has stalled after six months, review your confidence thresholds, workflow design, and the scope of cases you’re allowing the AI to handle.
Analyst hours reclaimed.Valvoline saved 6-7 analyst hours per day after deploying Torq — and saw measurable ROI within 48 hours of go-live. That’s not a percentage on a dashboard. That’s time analysts can point to on their calendars — hours redirected from repetitive triage to investigation, threat hunting, and automation development.
SOC throughput without headcount growth.HWG Sababa nearly doubled SOC throughput with no new hires. Agoda compressed incident report generation from seven hours to 40 minutes. These results matter because they answer the question every CISO faces: Can I scale my SOC without scaling my team? The data says yes — if the AI is measured and managed correctly.
Use these benchmarks not as targets to hit on day one, but as reference points for your own deployment curve.
Turning AI SOC Metrics into a Board-Ready Reporting Framework
CISOs who successfully justify AI investment don’t present raw AI SOC metrics to the board. They translate those metrics into the four things boards care about: risk, cost, capacity, and trajectory.
1. MTTR reduction → Risk exposure reduction. Frame it as: “Our mean time to respond dropped from four hours to 12 minutes. That means an attacker’s window to operate inside our environment shrank by 95%.” Boards understand windows of exposure; they might not understand MTTR.
2. Analyst hours saved → Capacity gained. Don’t frame this as headcount reduction; frame it as coverage expansion. Instead: “We recovered the equivalent of 1.5 full-time analysts in capacity. That capacity is now allocated to threat hunting and proactive risk reduction work that we couldn’t staff before.” Boards understand that doing more with the same team is possible.
3. Autonomous closure rates → Coverage improvement. Frame it as: “Before AI, we could meaningfully investigate approximately 60% of incoming alerts. We now investigate 100%. Every alert gets full triage and, when warranted, a complete investigation — without adding headcount.” Boards understand coverage gaps. Telling them you closed the gap is more powerful than any MTTR chart.
4. Escalation accuracy → Trust maturity. This is the trend line that matters most for long-term buy-in: “In month one, the AI escalated cases at 82% accuracy. By month six, it was 96%. The system is measurably getting better at knowing when to act and when to ask for help.” Boards understand learning curves — show them one.
For reporting cadence, deliver monthly operational AI SOC metrics to SOC leadership — MTTI, MTTR, closure rates, escalation accuracy, and analyst utilization. These are your tuning instruments. Quarterly, deliver business impact summaries to the CISO and board — risk reduction, capacity gained, coverage improvement, cost avoidance, and the trend curves that show compounding returns.
How Long Does It Take for AI to Show Measurable Results in a SOC?
Tracking AI SOC metrics isn’t a one-time exercise. It’s a maturity journey, and the metrics should reflect that.
Month 1–3: Validate performance in shadow mode. Run AI decisions in parallel with analysts. Compare what the AI would have done against what analysts actually did. Establish accuracy baselines and identify where the AI agrees with your team and where it diverges. This phase builds internal confidence. If the AI matches analyst decisions a majority of the time on Tier 1 cases, you have the evidence to increase autonomy.
Month 3–6: Increase autonomy. Expand autonomous closure. Track escalation accuracy weekly. Tune confidence thresholds based on real outcomes, not theoretical risk models.
Month 6–12: Expand use cases. Benchmark against industry data. Extend AI into Tier 2 investigation, cross-team workflows, and compliance reporting. Demonstrate compounding improvement — not just in speed, but in scope.
Month 12+: Activate AI-driven insights. The AI surfaces trends humans couldn’t detect at scale — detection rule gaps, recurring misconfiguration patterns, team capacity forecasting, and emerging attack vector correlation. At this stage, the AI isn’t just executing your security strategy; it’s informing it.
The key signal to watch across all stages: AI SOC metrics should compound before they plateau. An early flat line means the platform isn’t learning. A late plateau after months of sustained improvement is what a mature deployment looks like. MTTR should keep dropping. Autonomous closure rates should keep climbing. Escalation accuracy should keep tightening. If your numbers plateau after month three, something is wrong. Either the AI isn’t learning from new data, the use cases aren’t expanding, or the confidence thresholds need adjustment.
The AI SOC Metrics Imperative
The organizations getting the most from their AI investment aren’t running the most sophisticated models. They’re running the clearest measurement frameworks — and they have the discipline to track them.
Define your baselines. Track the metrics that connect to outcomes. Build the dashboard your board actually wants to see. And benchmark against organizations that have already proven what’s possible.
What are the most important AI SOC metrics to track?
The AI SOC metrics that matter most are MTTI, MTTR, autonomous case closure rate, analyst hours reclaimed, false positive suppression rate, and escalation accuracy. Baseline these metrics before deployment and track them monthly. Organizations using Torq have demonstrated MTTI/MTTR improvements of 95%, autonomous alert management of 55%+ of total volume, and full Tier 1 automation within months of deployment.
What is a good autonomous case closure rate for an AI SOC?
Leading organizations achieve 55–100% autonomous case closure rates for Tier 1 and Tier-2 cases. HWG Sababa automatically manages approximately 55% of total monthly alert volume end-to-end. Carvana automated 100% of Tier 1 alert handling and 41 runbooks within one month. If your AI has been live for six months and autonomous closure is stagnant, review your confidence thresholds and workflow design.
How do you report AI SOC metrics to the board?
Translate AI SOC metrics into business language: MTTR reduction maps to reduced risk exposure, analyst hours saved maps to capacity gained (not headcount cut), autonomous closure rates map to coverage improvement, and escalation accuracy maps to trust maturity. Report operational metrics monthly to SOC leadership and quarterly business impact summaries to the CISO and board.
How long does it take for AI to show measurable results in a SOC?
Most organizations see initial results within weeks. Valvoline saw ROI within 48 hours of deploying Torq. However, the compounding value of agentic AI — improving accuracy, expanding use cases, surfacing operational trends — builds over 3-12 months. HWG Sababa achieved a 95% MTTI/MTTR improvement and nearly doubled SOC throughput without adding headcount, with the steepest gains occurring in the early months of deployment.
Rick Bosworth is a cybersecurity marketing executive with nearly two decades of experience driving GTM strategy across technology startups. His uniquely technical perspective bridges the gap between complex solutions and practical customer outcomes. Rick has deep expertise spanning EDR, CNAPP, CWPP, AppSec, CTEM, and agentic SecOps. When he is not speaking publicly, enabling sellers, or leading cross-functional initiatives, Rick enjoys adventurous dining, endurance athletics, and craft beer.
When asked about the #1 expected benefit of agentic AI, security leaders didn’t say faster detection or better MTTR. They said quality of life. This finding comes directly from 450 CISOs and cybersecurity leaders surveyed in the recently published 2026 AI SOC Leadership Report.
There’s no shortage of AI in today’s security operations center (SOC). Generative AI. LLM copilots. Agentic workflows. Custom-built agents. Vendor-driven automation. The SOC is saturated with intelligence, at least in theory. And yet, ask SOC analysts how things feel on the ground, and the answer is far more complicated.
Nearly four in five organizations are now using AI in their SOCs in some capacity, and many have embedded it across workflows. While AI adoption has surged, operational clarity has not kept pace. Instead of simplifying operations, AI has introduced a new layer of complexity: more tools, more outputs, more decisions to validate. This is the paradox at the heart of the modern SOC:
To understand why, you have to look past adoption metrics and into what analysts are actually experiencing, and more importantly, what they actually want.
AI Is Everywhere, But It’s Fragmented
On paper, the SOC has embraced AI. In practice, it’s stitched together from disconnected parts. The SOC now runs an average of 7 AI-powered SOC tools, and 80% of teams rely on fragmented point solutions. These tools operate independently, each with its own interface, logic, and version of reality.
No single system can see the full picture, so analysts rush in to fill the gap. SOC staff become the integration layer, manually correlating signals, validating outputs, and reconciling conflicting conclusions across tools. Operational overhead, the very thing AI was supposed to eliminate, has been reintroduced.
This is not a failure of AI capability, but a failure of architecture.
The Analyst Experience: From Operator to Orchestrator
AI is reshaping the role of the SOC analyst. Previously, analysts were the execution layer, spending their time triaging alerts, enriching data, and running playbooks. AI now handles much of that processing. In its place, a new layer of work has emerged: oversight, validation, and decision-making.
On average, analysts now spend 8.6 hours per week reviewing AI-generated outputs. At first glance, that can look like inefficiency: a full workday spent checking the machine’s work. But that interpretation misses the shift that’s actually happening.
Analysts are moving from execution to judgment. From doing the work to deciding what matters. If AI does the lion’s share of the previously manual, repetitive tasks, SOC capacity expands. AI saves more than the 8.6 hrs per week that humans spend on oversight.
This is progress, and this is only the early innings. Nearly 9 in 10 security leaders say AI has improved workload and reduced burnout. But this progress comes with a condition: the oversight-for-execution trade-off only works if it’s efficient.
When AI outputs are opaque, inconsistent, or fragmented, oversight becomes a source of friction. When reasoning is clear and context is unified, oversight becomes strategy.
What Security Leaders Say Their Analysts Need Most
Strip away the noise, the AI hype, and dashboards, and a clear picture emerges of what analysts actually need. When 450 security leaders were asked what would most improve SOC operations, the answers weren’t about faster models or more automation. They pointed to the conditions their teams need to actually do their jobs.
1. Better Quality of Life
At its core, the SOC remains a human system. And the leaders running these teams are explicit about what would improve it:
Fewer repetitive, manual tasks
Better workload distribution and prioritization
More sustainable work-life balance
These objectives reflect a daily reality of alert fatigue, context switching, and cognitive overload. AI has the potential to solve these problems, but only if it reduces friction, not adds to it.
2. AI They Can Trust
Trust is the defining constraint of AI in the SOC. Full stop.
Only a small fraction of leaders report zero concerns about AI. The vast majority point to issues like:
Data privacy risks
False negatives (missed threats)
False positives
Black-box decision-making
The common thread? Visibility. Transparency. Explainability. Analysts and cybersecurity leaders don’t just want answers. They want to understand how those answers were reached. In fact, 90% of security leaders say they need explainability to trust AI decisions.
Because in security operations, decisions carry consequences. And confidence comes from clarity.
3. Control Over Automation
Despite widespread belief in AI’s capabilities (here is your friendly reminder to download the 2026 AI SOC Leadership Report for the supporting details), most teams are cautious about letting it act autonomously.
Nearly all organizations are comfortable with some level of AI-driven action, and most draw a hard line at medium-severity incidents. Not only is the aforementioned trust factor at play, but also a lack of control.
Today’s tools often present a binary choice: AI acts, or humans act. That’s hardly a choice when the stakes are high.
What analysts actually want is a dial. They want to calibrate autonomy based on:
Severity
Confidence
Context
Low-risk, high-volume alerts? Let AI handle them end-to-end. High-risk, high-impact incidents? Keep humans in the loop.
Not all automation is, or even should be, equal. Analysts demand the flexibility to decide where the line is drawn, and to move it over time at their discretion. See also, judgment layer.
4. Fewer Tools, More Cohesion
Perhaps the most consistent signal across the data is this: 85% of security leaders would prefer a unified platform over multiple point solutions.
Let us be crystal clear: no one is suggesting replacing existing tools. EDRs, CNAPPs, and other security controls serve critical functions. The best are exceptional at their prescribed function. The issue is what sits above them, or rather, what does not.
Most SOCs today do not have a unified layer that:
Sees across the full stack
Correlates fragmented signals
Provides consistent reasoning
Enables coordinated action
So analysts jump into that void. And teams are back to manual, repetitive tasks in the effort to stitch together context spread across data siloes. The previously mentioned tradeoff between execution and oversight falters, diminishing the value of what AI could otherwise deliver.
The Real Bottleneck: Trust, Not Tech
One of the most striking findings in the data is the dichotomy between what teams believe AI can do and what they actually allow it to do. To wit, even though 97% believe AI can handle alert triage, only 35% are using it for that purpose.
This pattern repeats across the SOC. (Did you even download the 2026 AI SOC Leadership Report?) AI is widely trusted to analyze, investigate, and recommend. It’s far less trusted to act.
Organizations lack confidence in how AI operates. Trust breaks down when:
Decisions cannot be explained
Data access is not governed
Outputs cannot be verified
Control boundaries are not clear
In other words, AI has the ability. Analysts just don’t trust it to do the right thing.
The SOC Analysts Are Asking For: Unified, Explainable, Controllable
Despite the challenges, there is remarkable alignment on what the ideal SOC should look like. Across roles, industries, and geographies, the vision is consistent for a system that is:
Unified across the entire security stack
Explainable in every decision it makes
Adaptive, learning from outcomes over time
End-to-end, covering the full alert lifecycle
Controllable, with adjustable levels of autonomy
This blueprint for the AI SOC is laid out clearly in the research findings and reflects a fundamental shift in how AI is expected to function within it.
The security industry has spent the last several years racing to embed AI into every corner of the SOC. That tinkering or adoption phase is over. The next phase will make that intelligence scalable, usable, and trustworthy for the enterprise.
Enterprises demand AI that:
Shows its reasoning (transparency)
Operates within clear boundaries (control, guardrails)
Augments the SOC (capacity, throughput, efficiency)
Organizations that close these gaps, moving from fragmented tools to a unified AI SOC platform, from opaque outputs to transparent reasoning, and from brittle automation to adjustable autonomy, will unlock the outcomes that AI was always expected to deliver. Faster response. Lower risk. Higher analyst productivity.
The rest will continue to manage complexity, just with smarter tools. Smarter tools are only valuable when they make the system itself — in this case, the SOC — smarter.
The AI SOC is cybersecurity’s fastest-growing category, and for very good reason. Machine-speed threats demand machine-speed responses, and the $82.45 billion market forming around this reality reflects just how urgent that need has become.
The Torq AI SOC Platform delivers agentic insights and the ability to streamline action across the full security stack. Torq is officially listed as a technology partner that can host an integration with Google Security Operations, enabling Torq to cover the complete threat lifecycle from signal to resolution.
The results are concrete. According to Torq analysis, security teams report a 4x increase in alert handling capacity without adding headcount, a 75% reduction in MTTR that turns hours-long response cycles into minutes, and 95% of Tier 1 tickets auto-remediated.
That last number matters most. The repetitive, high-volume triage work that consumes analysts’ time is handled nearly entirely by the integrated platform, freeing your team for the investigations that actually require human judgment.
Detection Meets Autonomous Response
Google Security Operations is an intelligence-driven, AI-powered platform that gives security teams an incredibly powerful foundation: cloud-scale detection, deep analytics, and the visibility to spot threats across even the most complex environments. Pair that with the Torq AI SOC Platform built on a foundation of agentic AI and Hyperautomation, and something powerful happens. Detection doesn’t only surface threats — it triggers an entire response workflow, automatically.
Torq prioritizes the most important detections, contextualizing risk and identifying threat needles buried within the alert haystack. Cases are created and agentic investigations launched automatically, to quickly uncover the necessary containment and remediation actions to be either executed autonomously or with human-on-the-loop authorization. All agentic reasoning and actions are transparent and fully documented. Your team maintains total oversight and control.
With Torq’s integration with Google Security Operations, every one of those steps can happen at machine speed, with full auditability and AI doing the heavy lifting. Your security team is freed from the manual grind to focus on the decisions that require human judgment.
Through the integration, Google Security Operations alerts are ingested by the Torq platform, where it creates a case and launches an automated investigation and response workflow without waiting for a human to intervene.
Less noise. Torq pulls detections directly from Google Security Operations via API and immediately applies agentic auto-triage: correlating related events, enriching them with threat intelligence and risk context, and delivering a verdict on every alert. False positives are filtered before they reach your team, leaving analysts with a prioritized view of actual risks rather than a queue of raw alerts to work through manually. Every alert becomes a tracked, enriched, actionable case — not a notification that gets buried in a queue.
Full visibility, shared across every stakeholder. For confirmed issues, Torq’s AI SOC Analyst, Socrates, gets to work automatically. It queries Google Security Operations for related events, mapping context across the environment, assembling timelines, and producing a complete case summary in natural language — ready for analyst review, approval, or autonomous closure. Native case management gives security, cloud engineering, IT operations, and business leadership a single shared view from detection through resolution, with complete visibility into every AI decision and action along the way.
Response that goes all the way to remediation. Torq executes response actions across your entire security stack: blocking users, isolating endpoints, revoking access, and notifying stakeholders. Automated workflows then coordinate remediation across cloud infrastructure, endpoints, identity systems, network, and beyond — without requiring your team to context-switch between tools. Everything is logged where it belongs: in your SIEM. Most solutions stop at analysis. Torq covers the full lifecycle.
Flexible log ingestion and custom parsing. Torq also supports raw log ingestion back into Google Security Operations, with custom parser support for non-standard data sources. If it lives in your environment, it can live in your SIEM.
Built for the AI SOC
When a Google Security Operations alert fires on a compromised credential, Torq doesn’t just run a static playbook. It investigates the user’s recent activity, checks for lateral movement, evaluates policy, notifies the right people, and takes action. All in a single, fully documented flow. The analyst can see a complete picture and a recommended next step, not just an alert number.
Key capabilities that power the solution:
Agentic AI triage, investigation, and response
400+ native integrations
Transparent agentic reasoning and control over agentic action
No-code and agentic workflow building
Human-in-the-loop controls
Immutable audit trails
Cloud-native enterprise architecture
“Google Security Operations is where the world’s best security teams detect threats. Torq is where those threats are further prioritized, investigated, and resolved at speed and scale. This integration and partnership is about building a continuous, AI-augmented response loop that eliminates the manual work between detection and remediation.”
– Rachel Israel, Director of Tech Alliance, Torq
Getting Started with the Integration
Torq’s collaboration with Google Cloud extends beyond Google Security Operations. Torq’s integration with Google Cloud allows security teams to automate workflows across the full Google Cloud environment — including Google Chat notifications, Google Workspace user management, and any custom Google Cloud API action through Torq’s Step Builder.
Setup takes minutes:
Create a Google Cloud service account in IAM & Admin with the appropriate scopes.
Generate a JSON private key and upload it to Torq’s Google Cloud integration.
Enable the APIs for the Google Cloud services you want to automate (Gmail, Google Drive, Google Workspace, etc.).
Connect Google Security Operations as an alert source in Torq.
From there, Torq handles the rest. No playbook scripting. No brittle automation. Just outcomes.
“Torq is the de facto leader of the AI SOC space. While the category is now being treated as emerging, Torq’s position reflects something closer to incumbency — an established platform in a market that is only just catching up to what it represents.” – Forbes
Better Together: What Torq’s Collaboration with Google Cloud Can Help Unlock for Your SOC
Security teams aren’t looking for more dashboards or more alerts. They’re looking for outcomes. Resolved cases. Contained threats. Time back for the work that actually requires human judgment.
The Torq AI SOC Platform on Google Cloud delivers exactly that. Detection happens in Google Security Operations. Response happens in Torq. And the full lifecycle — from signal to resolution — is covered, documented, and auditable from end to end.
John White is the Field CISO for EMEA at Torq. A respected security executive with more than 20 years of leadership experience, John previously served as CISO at Virgin Atlantic, where he led a multi-year transformation deploying the Torq AI SOC Platform to modernize cyber operations. Prior to that, he built and transformed security functions for global organizations, including ASOS, Liberty Global, AEG Europe, and KPMG.
I spent 20 years as a CISO. I know what it feels like to run a SOC that’s stretched thin and held together by sheer effort — where every alert, regardless of severity, means someone’s pulling out a laptop at midnight or stepping away from their family on a holiday.
So when I sat down with three security leaders at a recent Torq customer panel, I wasn’t interested in the pitch-perfect version of their AI SOC automation journey. I wanted the real one: what broke, what they tried, what actually worked, and what changed for the people doing the work.
What I got were scenes I’ve seen play out a hundred times — lean teams, brittle tools, a breaking point — followed by something I’ve rarely seen: three teams that came out the other side with fundamentally different operations. Not incrementally better. Truly different.
Here are their stories.
Why These Security Teams Hit the Limits of Manual SOC Operations
Every team had a different trigger. The pattern underneath was identical: too few people, too many tools, and manual work that couldn’t scale, no matter how hard the team worked.
Corey Kaemming, CISO at Valvoline, inherited the problem three months into the job: a corporate divestiture that cut his team in half overnight. And the technologies split with it. The SOAR they’d been running was heavily customized — the kind of system that works until it doesn’t, and when it doesn’t, everything goes down. On top of that, their MDR provider was only responding to alerts from two tools. If an alert didn’t come from one of those two tools, it functionally didn’t exist.
Three months in, half the team gone, a brittle SOAR, and blind spots across the stack. That was Corey’s starting position.
Dustin Nowak, Cyber Threat Manager at Kenvue (the parent company of brands like Johnson’s, BAND-AID, and Neutrogena), faced a nearly identical divestiture — but his challenge was even more foundational. His team needed to stand up an internal hybrid SOC from scratch. They needed case management that could support a structured investigative process — something that followed NIST or SANS methodology, not just a ticketing queue. Most platforms they evaluated treated case management as an afterthought.
Matthew Brister, Staff IR and Threat Hunting Engineer at Henry Schein One, had four people covering 24/7 operations. Every alert, every time — Tuesday afternoon or Christmas morning — someone was on a laptop. For a team that small, every hour burned on a low-priority alert was an hour stolen from an investigation that actually mattered.
What AI SOC Automation Delivered in the First 30 Days
The first month on a new platform is where reality either matches the demo or it doesn’t. For these teams, Torq matched — and in some cases exceeded — their expectations.
Matt’s team moved the fastest. They tackled all five of their priority use cases in the first week. The remaining three weeks were spent exploring what else was possible. “I kept calling my team saying, ‘Show me something cool,'” he said.
But the number that doesn’t capture what actually changed is the one Matt told me next. Before Torq, his lean team was on call around the clock, every day and on every holiday. If an alert came in at 2am on Christmas, someone opened a laptop. After deploying Torq’s AI SOC platform, any obviously malicious action is automatically locked down. Last Christmas was the first holiday where alerts came in, but nobody had to leave their family.
I’ve sat in hundreds of vendor sessions. That’s the kind of outcome that sticks with you.
Corey’s team saw the efficiency gains immediately: six to seven hours per day saved in analyst work by removing manual, repetitive tasks. But what mattered just as much was what the platform didn’t require. “If it’s going to take three to four people to manage it, I’m out,” he said. “The time my team spends in Torq isn’t on care and feeding — it’s on building. That’s huge value, especially with a lean team.”
Mitch started where he had to — with a single pane of glass. When you’re operating across so many SOC tools, the first win isn’t automation. It’s being able to see everything in one place. Unified case management gave his team that foundation. From there, they moved into enrichment automation: the meta lookups, the IoC checks, the steps that run the same way for every incident.
Dustin took the most deliberate approach. He didn’t try to automate everything on day one. He started with case management — building the investigative structure first, then layering integrations and automation on top. It was the slowest start on paper. It was also the foundation that let everything else scale.
How to Build the Business Case for AI SOC Automation
Getting the Torq platform approved was only half the fight. Getting the organization to believe in it — and to stop defaulting to the tools they already had — was the real work.
Corey ran a head-to-head evaluation against a competitor. He chose a use case that the competitor couldn’t solve. Torq figured it out in three to four days. That made the technical case. The ROI case came from the six to seven hours per day saved in analyst time. But the political battle was harder: differentiating Torq from everything else already in the stack. Splunk was already there. Azure was already there. Why couldn’t those tools do this?
The answer was in the operational reality. None of those tools could unify the workflow across the full stack without heavy customization and a dedicated team to maintain it. Torq could, and it didn’t require an engineering staff to keep it running.
Dustin’s approach was different, and it’s the one I’d recommend to any CISO trying to make the SOC relevant to leadership. Kenvue makes Tylenol, Band-Aids, and consumer health products. To get leadership’s attention, the security team had to speak the business’s language.
One of their biggest use cases turned out to be digital rights protection — monitoring social media for fake accounts and brand threats. When someone set up fake Facebook accounts, Dustin’s team ingested the threat intelligence, automated monitoring, and told the business exactly what was happening regionally in real time. That took the SOC from cost center to what Dustin calls a Cyber Fusion Center (CFC) — relevant to the business in a way that MTTR metrics alone never could be.
Matt had the smoothest internal path. His boss was hands-on with the SOC and had leadership backing from the start. The team said yes immediately. The only question was how to divide up the work. Later, Matt built a dashboard in Torq to justify expenses across security tools — and it worked so well that teams outside security started asking him to build dashboards for their tools, too.
When AI + Automation Expands Beyond Security Operations
Here’s what surprised me: None of these teams stopped at security operations. Once Torq proved its value in the SOC, adjacent teams began to show up.
One of the themes that came up across the panel was how teams combine different approaches to security operations — and whether automation can scale the function at a fraction of the cost. At Kenvue, the team is already exploring that: rather than outsourcing to an MDR at full price, they’re looking to bring it in-house through the automation they’ve already built.
Corey’s team is advancing identity-focused security after experiencing impersonation attempts. In response, they are developing an identity verification workflow using Torq that relies on contextual validation rather than traditional methods. The approach leverages existing organizational signals to help confirm legitimacy, reducing reliance on static or easily exploited verification techniques.
Matt’s team is leaning into agentic AI and pushing for deeper data retention capabilities. They’ve already built creative workarounds using Torq workflows and dashboards to hold onto investigation data longer — and they want that to go further. It’s a sign of how much operational weight the platform is carrying: teams aren’t just using it for automation, they’re building core SOC infrastructure on top of it.
What These Security Leaders Learned Deploying AI SOC Automation
I asked each panelist what advice they’d give to a CISO or SOC leader considering a similar move.
Corey: Trust your team. Empower them to make decisions. Get governance right before you deploy — especially around AI, data privacy, and PII. Bring legal in early, not after. And once it’s running, market it internally. Don’t gate-keep. When other teams come asking, the answer should be “yeah, I can help — I have a tool for that.”
Matt: Get your foundation right in month one. Alerts aggregated. Use cases defined. If you don’t set the base, everything you build on top of it will be shaky.
Dustin: Make it relevant to the business. If you’re only reporting in SOC metrics, you’re invisible. Translate your impact into language the business understands, by region, by business unit, by brand risk.
The AI SOC Automation Playbook
Different companies, different industries, and different team sizes. The same arc: a breaking point that forced a change, a first month that proved the value, an internal battle that tested whether the platform could survive organizational gravity, and an expansion that nobody planned but everyone benefited from.
The teams that deployed Torq for AI SOC automation didn’t just get faster metrics. They got analysts who stopped dreading on-call rotations. They got SOCs that earned credibility with the business. They got a platform that other teams wanted to use. And in one case, they got their Christmas back.
That’s not a vendor story. That’s an operational one. And it’s the kind of outcome that only happens when the technology actually works the way the demo said it would.
These conversations happened at a recent Torq customer panel. Thank you to Corey, Dustin, and Matt for their time, honesty, and willingness to share what they’ve learned.
Torq surveyed 450 CISOs and security leaders on where AI in the SOC is delivering, where trust is breaking down, and what a true AI SOC actually looks like.
What results can you expect from AI SOC automation in the first 30 days?
Based on three enterprise Torq deployments, teams saw results within the first week to first month: Valvoline saved six to seven analyst hours per day by automating repetitive tasks. Henry Schein One deployed five priority use cases in the first week and eliminated 24/7 on-call requirements for a four-person team. Kenvue built a structured case management foundation. Time-to-value was measured in days, not months.
How do you build a business case for AI SOC automation?
The strongest business cases combine quantified analyst time savings (Valvoline documented six to seven hours saved per day), competitive evaluation against alternatives (Torq solved a use case in three to four days that a competitor couldn’t), and business-relevant framing (Kenvue translated SOC impact into brand risk and regional threat data, which took the SOC from cost center to what they call a cyber fusion center).
Does AI SOC automation require a large team to manage?
No. One of the most consistent findings across all four teams was that the Torq AI SOC platform didn’t require dedicated staff to maintain. Valvoline’s CISO was explicit: “If it’s going to take three to four people to manage it, I’m out.” Teams spent their time building new use cases, not maintaining the platform — which is critical for lean SOCs that can’t afford to trade one operational burden for another.
Can AI SOC automation expand beyond security operations?
Yes — and it did for every team in this panel. At Kenvue, expansion into data privacy and IT incident response is underway. At Valvoline, identity verification workflows are being built for anti-spoofing. The pattern: once the Torq platform proves value in the SOC, adjacent teams discover it on their own.
