AI SOC: What Automation Changes in Security Operations

TL;DR: An artificial intelligence (AI) security operations center (SOC) changes who does the first pass on alerts: AI agents triage, enrich and investigate, and people decide what happens next. Autonomy is set by confidence, so high-confidence cases can proceed automatically while novel ones go to an analyst. Accountability does not move. Baseline mean time to detect and mean time to contain before rollout, plan for a 30- to 90-day tuning window, and grant response authority one action at a time.

What is an AI SOC?

An AI security operations center (SOC) is a SOC in which artificial intelligence (AI) agents take the first pass on alerts. They triage, enrich and investigate, and people decide what happens next. SentinelOne describes AI working "across triage, investigation, enrichment, response recommendation, and remediation workflows," while "Your analysts set boundaries and review high-impact decisions."

Much of the meaning sits in the word agentic. In SentinelOne's account, agentic systems direct their own tool use, loop until they reach a goal, and recommend or execute actions within approved boundaries. A rule-based playbook works differently: it runs only the steps someone wrote in advance.

Vendors also separate an AI SOC from AI added to an existing SOC. UnderDefense calls an AI SOC "an architecture where intelligence is the operating layer." In our reading, a buyer should care less about the label and more about which decisions the system may take on its own.

Key facts for a skim

• Autonomy is set by confidence. ReliaQuest describes thresholds under which high-confidence decisions proceed automatically. Low-confidence or novel cases go to an analyst for review.
• Containment can run without a human. Stellar Cyber says automated playbooks can isolate endpoints, disable user accounts or block malicious IP addresses without waiting for approval. Whether they do depends on the organization's risk tolerance and configuration.
• Attacker speed is the stated reason. ReliaQuest reports data exfiltration in as little as 6 minutes from initial access.
• Alert volume is the other reason. UnderDefense puts the load at 4,484 alerts per day and says 67% go uninvestigated. We think vendor figures like these are worth testing against your own queue.
• Tuning takes time. Stellar Cyber advises planning for a 30- to 90-day tuning window, during which analysts give feedback to cut false positives.
• Measure before you switch it on. ReliaQuest advises baselining mean time to detect (MTTD) and mean time to contain (MTTC) before deploying AI.

The practical question for a security leader is where the line between agent and analyst sits, and who signs off on moving it. Our guide to AI governance for CISOs covers that oversight. Terms used here are defined in the glossary.

What AI triage and investigation do with a single alert

Take one alert: a suspicious sign-in to a finance user's account at an unusual hour. A research framework called AgentSOC describes a single operational loop for this work. The loop normalizes alerts, enriches context, generates hypotheses, validates structural feasibility and executes policy-compliant responses. Each stage below follows that order.

1. Intake and normalization. The alert arrives from the security information and event management (SIEM) system in its native format. It is converted into a common shape so later steps can line it up against identity, endpoint and network events.
2. Enrichment. Google Cloud's reference architecture for a multi-agent security operations center (SOC) system can look up asset misconfigurations from a third-party cloud security posture management (CSPM) tool. For a sign-in alert, Dropzone describes an agent that checks user authentication patterns for anomalies and tests whether the activity matches normal behavior for that user.
3. Hypothesis. AgentSOC's counterfactual engine generates multiple attack hypotheses using large language model (LLM) reasoning grounded in MITRE ATT&CK tactics, techniques and procedures. For our sign-in, that could mean several competing explanations: stolen credentials, a traveling employee, or a first step toward lateral movement.
4. Feasibility check. A simulation engine tests those hypotheses against enterprise topology, identity privilege graphs and policy constraints and filters out attack paths that cannot happen.
5. Verdict and response. A scoring module ranks defensive actions by containment effectiveness, business impact and execution cost. The analyst receives a documented verdict, which Dropzone describes as true or false positive with evidence. The Google design includes human-in-the-loop approval before action.

The feasibility check is the step to look at hardest. The AgentSOC authors note that LLM copilots may recommend responses that are unsafe or infeasible within existing identity and network structures. In our reading, a tool that skips this step will propose actions such as disabling an account the attacker never had access to.

Correlation can also change the size of the case. Dropzone gives the example of a suspicious login in identity logs alongside lateral movement in endpoint telemetry, which the agent surfaces as one multi-stage attack.

Treat speed claims with care. The AgentSOC proof of concept on authentication data processed in 506 ms, but the framework was evaluated using a conceptual enterprise scenario. We think that shows the design can work, not how it performs on a production queue.

For governance questions about who signs off on agent actions, see AI governance for CISOs.

Where analysts stay in the loop

The split that matters is not human versus machine. It is which decisions carry enough consequence that a person signs for them. Dropzone puts the human share in one line: Tier 2 escalations, incident response decisions, proactive threat hunting, and detection-program improvements.

Vendors draw that line in different places. ReliaQuest describes a model that automates time-intensive Tier 1 and Tier 2 tasks, so a buyer should ask each supplier where Tier 2 sits in its design.

The four kinds of work that stay human

Escalations stay human because the hard cases rarely announce themselves. Dropzone notes that multi-step campaigns are not always obvious, especially when activity generates no alert or unfolds slowly. The agent can line up the evidence, but judging intent against the organization's threat model is analyst work.

On response, the vendor's own guidance is blunt: the agent recommends, but the final decision is always yours.

Hunting is shifting rather than disappearing. ReliaQuest describes AI that generates hypotheses, and pre-builds investigation timelines for analyst validation. The machine widens the search. A person still decides which leads are worth chasing.

Detection engineering follows the same pattern. AI converts detection logic written in natural language into the native syntax of your security tools, which removes translation toil. The choice of what to detect, and why, stays with the team.

Augmented versus autonomous

An augmented model has the AI investigate and recommend while people approve consequential actions. An autonomous model lets the system act on its own conclusions, inside limits set in advance.

In our reading, few teams pick one or the other outright. Stellar Cyber recommends a hybrid: autonomous handling of high-confidence, well-understood threats paired with human-in-the-loop workflows for novel or ambiguous incidents.

In our reading, the practical difference is who owns a bad outcome. Under augmentation, a wrong containment call is an analyst decision that can be reviewed. Under autonomy, it is a policy decision made earlier by whoever set the boundary. That puts the CISO's name on the threshold itself.

• Which actions run without approval today, and who signed off on that list.
• How analyst corrections reach the model, and how often.
• Whether hunting and detection work has protected time, or gets absorbed back into the queue.

How an AI SOC differs from SOAR and a traditional SOC

The three models differ less in what they detect than in who does the work after an alert fires. The table is our summary. The evidence for each row follows it.

Triage and investigation

SentinelOne describes the traditional model plainly. Security information and event management (SIEM) alerts are the primary data input, investigation quality varies with each analyst's experience, and response runs on rigid playbooks. Stellar Cyber adds that legacy SOCs were built around SIEM platforms that needed constant rule tuning and human-driven investigation.

Security Orchestration, Automation, and Response (SOAR), as UnderDefense defines it, is rule-based playbook execution. It speeds up steps someone has already written down. UnderDefense's own before-and-after table puts manual Tier 2 work at log correlation across 5 or more consoles and 2 to 4 hours per investigation. That is a vendor figure, not an industry measure.

The agentic model changes who chooses the steps. SentinelOne says agentic systems direct their own tool usage and loop until they achieve a goal, collecting evidence and correlating activity within approved boundaries.

Response authority

UnderDefense lays out a spectrum. At one end, the analyst approves every action (Level 1). At the other, AI decides and acts without approval (Level 3). Stellar Cyber notes that automated playbooks can isolate endpoints, disable accounts or block IP addresses without human approval, depending on the organization's risk tolerance and configuration.

In our reading, this makes response authority a setting the security leader owns, not a property of the product.

Maintenance load

This is where the complaints about SOAR concentrate. UnderDefense writes that rigid if/then logic requires constant maintenance and breaks on novel attack patterns, producing playbook sprawl. Its author describes teams that maintain 200+ playbooks where half are outdated. Torq frames the agentic alternative: AI reasons through novel situations and acts within defined guardrails.

The maintenance does not disappear. It moves to the tuning period and analyst feedback covered earlier, and to keeping agent boundaries current as systems change.

Which metrics show whether an AI SOC works

Set the baseline before the pilot starts. Without numbers from your own queue, taken in the month before rollout, every later figure is a vendor's figure.

Vendors usually frame the problem as a coverage gap. UnderDefense, which sells an AI SOC service, writes that analysts face 4,484 alerts per day and that 67% go uninvestigated. Your own share will differ, and that share is the first thing to measure.

Five measures to track

For hours per alert, a manual starting point gives the comparison its scale. UnderDefense's before-and-after table puts manual Tier 1 work at 45 minutes per alert with 60 to 80% false positives. Its after column claims the AI auto-triages 90%+ in under two minutes and only escalates confirmed threats. Treat both columns as one provider's description, then build your own.

Vendor savings are claims to test

Published savings figures vary widely. Dropzone cites a customer, Zapier, whose security team cut its manual alert investigation work by 85%. Stellar Cyber writes that autonomous triage can cut analyst workload by 80% or more. It also says organizations typically target a 60 to 90% reduction in mean time to respond. Note the word target: that figure is a goal, not a measured result.

In our reading, the useful step is to ask each vendor which of the five measures its figure maps to, how it was counted and over what period. Then run the same calculation on your pilot data.

Verdict accuracy needs repeat checks. Dropzone says its agent refines its accuracy through feedback from analysts, which means accuracy should move over time. Re-sample each month rather than once at go-live.

Report the five measures together. If one improves while another worsens, for example faster response alongside more analyst disagreement on samples, we think that is a signal to slow the expansion of autonomous actions. For how these numbers reach directors, see board cybersecurity oversight.

How to test vendor claims before you buy

In our reading, vendor demos tend to look alike. ReliaQuest, itself a vendor, published a buyer's framework that sorts the questions into four categories: utility and autonomy, implementation and learning, architecture and intelligence, and validation and trust.

In our reading, these categories are most useful when you put the same questions to every vendor, in writing, and score the answers yourself. The aim is a like-for-like comparison, not a shortlist handed to you.

The two vendors' guides carry their own positions, and a buyer can treat those as claims to check. ReliaQuest argues that training on customer data creates compliance and privacy risks. Your privacy and legal teams can read the contract terms against that view.

ReliaQuest also lists what it counts as a validation lifecycle: golden dataset testing, continuous customer feedback, secondary AI evaluation, and human expert oversight. Ask each vendor which of these it runs, how often, and whether you can see the results.

Prophet argues that an agent should cover autonomous alert investigation, proactive threat hunting, and detection engineering support. It also says agents that investigate every alert can produce per-rule disposition data showing which detections consistently produce true positives, which generate noise, and where coverage gaps exist. That gives you a concrete request: ask for a sample report from your trial data.

The strongest test is your own alerts. We think a proof of concept should replay a set of past alerts that your team has already closed, so you can compare the agent's verdicts with known outcomes. Include a few slow, quiet cases of the kind the earlier section on multi-step campaigns described.

Who answers for an action the AI takes

Automation moves the hand on the keyboard. It does not move the accountability. Writing about earlier automation platforms, the AgentSOC paper notes that analysts remain "ultimately accountable for contextual decision-making and executing final response actions." An AI security operations center (SOC) changes who executes. In our reading, the CISO still answers for the outcome, so the setup work below belongs before the first autonomous containment.

Set autonomy for each action type

Earlier sections described the autonomy levels. The practical step is to assign a level for each action type, not one level for the whole product. SentinelOne describes a model in which analysts set boundaries and review high-impact decisions.

Write the policy limits down

The AgentSOC authors argue that autonomy "must be explainable, risk-aware, and aligned with policy controls to avoid accidental disruption." Their risk module ranks defensive actions by weighing containment effectiveness, business impact and execution cost.

A written policy for each containment action can cover four things: the allowed scope, the assets that are off limits, a ceiling on how many times the action can fire before a human is paged, and who can override it.

Make the audit trail readable

ReliaQuest says buyers should be able to see what actions the AI takes, why it takes them and the data behind those choices. Each autonomous action record should hold the triggering alert, the evidence, the policy rule that permitted the action, the model version, the approver or the fact that none was needed, and the rollback step.

Reviews a CISO can set up

• A weekly sample of AI-closed alerts, reread by a senior analyst.
• A monthly review of every containment action, with reversals flagged.
• A rerun of known past cases after each vendor model update.
• A tabletop exercise each quarter in which the AI's trail feeds the incident write-up.

Where disclosure fits

Incident disclosure rules turn on human judgments about severity and timing. The AI can supply the timeline. It does not make the call. Our Form 8-K Item 1.05 entry and materiality decision guide describe what the rule says. A reader can check that the AI's records map cleanly onto the incident record the legal and disclosure team already keeps. For the wider ownership question, see CISO accountability and AI governance for CISOs.

How to roll out an AI SOC in phases

In our reading, most published playbooks give the same order: start where the volume is, prove the gain, then hand over more. Dropzone puts it in one line: automate alert triage first, then expand to log analysis and correlation. ReliaQuest advises against a full-scale transformation on day one. It names threat intelligence research, detection engineering and alert investigation as entry points.

Before phase one: set the baseline

ReliaQuest recommends baselining mean time to detect (MTTD) and mean time to contain (MTTC) before deploying AI. Pull the current figures from your case management system and freeze them. Every later decision to widen scope should point back to that baseline.

Phase 1: triage and research

• Turn on AI investigation for one or two high-volume alert types, such as suspicious logins. Treat every verdict as a recommendation.
• Give the agent threat intelligence research: reading feeds, extracting indicators, drafting reports. Nothing changes in production, so the risk is low.
• Have analysts review each verdict and log every disagreement. That review log is your evidence for phase two.

Phase 2: log analysis and correlation

Here the agent moves from single alerts to the wider picture. Dropzone describes an agent that pulls SIEM data, traces process trees and builds one attack timeline from identity, endpoint and network telemetry. Its example is a suspicious login in identity logs linked to lateral movement in endpoint telemetry.

A practical test: replay three or four incidents your team has already closed. Check whether the agent rebuilds the same timeline, and note where it misses a step.

Phase 3: widen response authority

ReliaQuest describes confidence thresholds, with high-confidence decisions proceeding automatically and novel cases going to an analyst. Its containment examples are host isolation, account disablement and IP blocking. Google Cloud's reference architecture builds human-in-the-loop approval into the agent system itself.

Our advice is to grant authority one action at a time. Start with reversible actions on non-critical assets. Keep approval on everything else, and write each boundary into the accountability model covered earlier in this guide.

How roles and hiring shift: our view

Dropzone lists the work that stays with people: Tier 2 escalations, incident response decisions, proactive threat hunting and detection-program improvements. In our reading, the Tier 1 seat changes from working a queue to auditing verdicts. That is a different skill.

We think hiring should tilt toward people who can write detections, challenge an investigation's evidence and explain business context. Keep a junior pipeline anyway. Reviewing agent verdicts can train new analysts, but only if they also handle raw data often enough to spot when the agent is wrong. For current openings and role titles, see /jobs.

What this guide does not cover

The vendor figures this guide cites are claims to test, not verified results. Readers should take disclosure and contract questions to their own legal and privacy teams. For the rules and the record behind it, see AI Governance for CISOs: NIST's Framework, the 12 GenAI Risks and the New Agentic AI Rules.