What is an agentic SOC?
An agent, in the sense vendors and researchers now use, is software that takes an objective, breaks it into steps, calls tools (a query, a lookup, an isolation action), reads what comes back and decides what to do next. It keeps going until the objective is met or it hits a boundary it has been told to respect.
In a SOC this looks like an agent receiving an alert and, without a script, pulling the process tree, the user's recent sign-ins, the network connections the process made and the same indicator across other hosts, then drafting a verdict with the evidence attached. A second agent might take a hunting hypothesis and turn it into queries across a year of retained data. A third might notice a detection rule has stopped firing and draft a fix for an engineer to review.
The research literature has started to organise this. A 2025 survey in the Journal of Cybersecurity and Privacy, AI-Augmented SOC: A Survey of LLMs and Agents for Security Automation, maps language models and agents across SOC functions from log summarisation and alert triage to incident response, proposes a capability-maturity model for how far each function is integrated, and names the open problems plainly: interpretability, adversarial robustness, integration with legacy systems, hallucination and data leakage.
The most useful framing for buyers comes from work on human-AI teaming. Chhetri, Tariq and colleagues, writing in ACM Transactions on Internet Technology, propose the A2C framework: automation for routine alerts, augmentation to speed up expert decisions, and collaboration for novel threats, with the SOC moving between the three modes case by case. An agentic SOC done well is that framework in production. The agent works alone where the case is routine, supports the analyst where judgement is needed, and hands over cleanly where it is out of its depth.
How does an agentic SOC differ from SOAR, a copilot and an autonomous SOC?
| SOAR | Security copilot | Agentic SOC | Autonomous SOC |
|---|
| What it is given | A playbook written in advance | A question from an analyst | A goal and a scope | A goal and no human boundary |
| Who plans the steps | The playbook author | The analyst | The agent, at runtime | The agent, at runtime |
| Where it stops | At the end of the script | After answering | At the human decision declared for that job | When it decides the case is closed |
| Typical failure | Breaks when the environment drifts | Adds a chat window without moving work | Wrong verdict with evidence you can check | Wrong closure nobody sees |
The agentic SOC and the autonomous SOC use the same technology. The difference is governance. In an agentic SOC each job has a declared point where a person decides. An autonomous SOC removes that point. For high-confidence, low-consequence cases that can be sensible. As a description of a whole SOC it is a roadmap, not a product.
What does an agentic SOC need underneath it?
Most agentic SOC evaluations focus on the agent: how well it reasons, how natural its summaries read. The agent is the visible part. Five things underneath decide whether it works.
1. Data the agents can reach, in every tier. Most SIEM storage tiers were designed around a human running an interactive query, so older data is parked somewhere cheaper and slower and must be moved back before anyone can use it. In Microsoft Sentinel, data held only in the data lake tier isn't available for real-time analytics features and threat hunting; detection on it means building scheduled KQL jobs or summary rules and promoting the results into the analytics tier. In Splunk Cloud, archived data cannot be searched until it is restored, and Splunk states that the restoration process can take up to 24 hours. An agent asked to check whether an indicator appeared eight months ago either cannot, or has to wait for a person to arrange it.
Agents change the trade-off. A long-running agent hunting in the background does not need a sub-second answer, because nobody is sitting at a console waiting for it. A query over older, colder data can take a little longer without costing anyone's time. So the right design is storage that is fast where a person or a real-time detection needs it, cheap where an agent can wait, and queryable by the agent in every tier without a restore step.
2. Detection that does not wait for an agent. Agents investigate; they should not be the first line of detection. The detection layer underneath needs stated latencies for each kind of data: what fires in real time, what fires within minutes, what runs on a schedule. Ask for those numbers per tier, not a single headline.
3. An orchestrator and bounded specialists. One general agent with access to everything is the hardest thing in the SOC to govern. A better pattern is an orchestrator that assigns work to specialist agents, each with its own tool scope: the triage agent can read, the response agent can isolate a host, and neither can change a detection rule.
4. A decision record for every action. Every step an agent takes should write to a record a person can read back later: what it was asked, what it queried, what it found, what it did, and who approved the consequential step. If you cannot reconstruct why a case was closed six months later, you cannot defend the SOC in an incident review or to a regulator.
5. Separation of data from instructions. SOC agents read attacker-controlled text all day: filenames, email bodies, user agents, DNS queries. Greshake and colleagues showed in 2023 that applications built on language models blur the line between data and instructions, letting an attacker plant prompts in content the model will later retrieve. OWASP ranks prompt injection first in its Top 10 for LLM applications. An agentic SOC needs its agents to treat telemetry as evidence, never as instructions, and a vendor should be able to show you how that is tested.
Where do people stay in an agentic SOC?
The agent does the work that is mechanical, slow and where human attention runs out. People keep the decisions where a wrong answer has consequences. A useful way to write this down is one line per job.
| Job | What the agent does | What a person decides |
|---|
| Triage | Clusters, deduplicates and scores alerts, and says why it dismissed each one | The suppression boundary: what the agent may close without asking |
| Investigation | Joins endpoint, network, identity and cloud evidence into one timeline and drafts a verdict | Close, escalate or send it back |
| Threat hunting | Turns a hypothesis into queries across retained data and returns results with the query shown | Whether the result is trusted and acted on |
| Detection engineering | Drafts, tests and tunes rules against historical data; flags rules that stopped firing | Approve, amend or reject deployment |
| Data engineering | Configures sources, parsers and routing; checks pipeline health | Whether a new source, scope or pipeline is correct |
| Response | Prepares containment steps and can take pre-agreed reversible actions | Any action outside the pre-agreed set |
Tariq and colleagues' review of alert fatigue in ACM Computing Surveys reviews responses through automation, augmentation and human-AI collaboration, and examines where existing solutions fall short. The lesson for buyers is that the handover between agent and person is the product. A vendor that cannot show you exactly where each job hands over has not designed it.
How do you evaluate an agentic SOC? A scorecard
Use this scorecard to compare vendors on the same terms. Score each criterion from 0 to 3, multiply by the weight, add the results and divide by 3 to get a score out of 100. Adjust the weights to your own risk position, but keep the criteria: each one maps to a way an agentic SOC fails in production.
Scoring: 0 = not offered. 1 = roadmap, or shown only in a demo. 2 = available, with limits the vendor states. 3 = in production, with evidence you measured in your own live trial.
| # | Criterion | What to ask | Evidence to request | Weight | Your score (0 to 3) | Weighted (score × weight) |
|---|
| 1 | Data reach | Can agents query every storage tier, for the whole retention period, without a restore or promotion step? | A hunt during your trial over data older than your hot window | 10 | | |
| 2 | Detection latency | What fires in real time, near real time and on a schedule, for each data source? | Stated latency per tier and per source type | 10 | | |
| 3 | Evidence citations | Does every claim in a verdict link to the underlying event? | Every escalation from your trial, with every claim traced to source | 10 | | |
| 4 | Decision record | What share of agent actions is recorded, and can the record be altered? | A decision record exported from your trial, and how alteration is prevented | 10 | | |
| 5 | Scope and authority | What can each agent read, change and do unattended, and where is the human decision for each job? | The per-agent permission list | 10 | | |
| 6 | Reversibility | Which actions run unattended, and how is each one undone? | A live reversal during your trial, plus the unattended-action list with rollback steps | 8 | | |
| 7 | Measured outcomes | What resolution rate and true-positive rate do you publish, over what window and population? | Your trial results against the success measures you set on day one, plus published figures with denominator, window and method | 10 | | |
| 8 | Injection resistance | How are agents kept from following instructions planted in telemetry? | The result of your unannounced injection test during the trial | 8 | | |
| 9 | Human-AI teaming | How does a case move between agent and analyst, and what load does escalation create? | Escalations per day and analyst time per escalated case, measured in your trial | 8 | | |
| 10 | Cost model | What is charged: ingest, storage, queries scanned, agent activity, human escalation? | Cost per investigation measured in your trial, projected to your yearly volume | 8 | | |
| 11 | Residency and exit | Where is data processed, and what leaves with you: raw data, detections, decision records? | Residency documents, and a data-export test run during your trial | 8 | | |
Weights total 100. To score, write each vendor's 0 to 3 in the blank column, multiply by the weight, add the weighted column and divide the total by 3.
Why 60 is the cut-off. A vendor that scores 2 on every criterion (available, with limits it states) lands at about 67. Falling under 60 means several criteria sit at 1 or 0: roadmap, demo only, or not offered. A vendor scoring under 60 is selling a roadmap.
What to do below 60. Do not buy on that score. Either narrow the proof to the jobs where the vendor scored 2 or 3, and keep a human approval on everything else, or extend the trial until the missing evidence has been measured and score again. The criteria most often scored 1 in practice are data reach, measured outcomes and cost model, because they are the hardest to fake in a live trial and the easiest to leave out of a slide.
How to run the evaluation: a live trial, not a replay
Why a live trial. Replayed incidents and scripted demos can be tuned for the test. A vendor who knows the incidents, or has weeks to adjust prompts and rules before scoring, is being measured on its preparation, not on your SOC. Security engineer Alex Beaver describes proofs of concept where he spent more time prompt-engineering the agent than it would have taken to build the logic ("The Asymptote of the AI SOC is Determinism", Secure at Scale, 22 September 2026). A live trial in your own environment, with attacks the vendor does not know about, measures what you will actually get.
Your environment, your live data, attacks the vendor is not told about. Score what the agents did, not what the demo showed.
Two more checks to run during the trial. Ask each vendor which steps are fixed, deterministic playbooks and which are agent reasoning, and why: work that repeats is usually cheaper and easier to audit as deterministic automation. And measure cost per investigation, not just the licence, because agent work carries a cost every time it runs.
