An agentic SOC is a security operations centre in which AI agents plan and carry out multi-step security work, such as triage, investigation, threat hunting and detection engineering, across the SOC's tools and data, while people set each agent's scope and keep the decisions that carry consequence. The difference from earlier automation is the unit of work. A playbook is given steps. An assistant is given a question. An agent is given a goal, and works out the steps itself.
That makes the agentic SOC an architecture question as much as an AI question. An agent is only as good as the data it can reach, the detections running underneath it, the authority it has been granted and the record it leaves. This guide covers how an agentic SOC works, where people stay in it, what it costs, and how to evaluate one, with a weighted scorecard you can copy into your own buying process. For the broader definition of AI in the SOC, see what is an AI SOC.
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 measured evidence you have seen.
| # | Criterion | What to ask | Evidence to request | Weight |
|---|---|---|---|---|
| 1 | Data reach | Can agents query every storage tier, for the whole retention period, without a restore or promotion step? | A live hunt 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? | Three closed cases, with every claim traced to source | 10 |
| 4 | Decision record | What share of agent actions is recorded, and can the record be altered? | Coverage figure and how it is enforced | 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? | 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? | Figures with denominator, window and method | 10 |
| 8 | Injection resistance | How are agents kept from following instructions planted in telemetry? | Test results against planted prompts in logs | 8 |
| 9 | Human-AI teaming | How does a case move between agent and analyst, and what load does escalation create? | Escalation rate and analyst time per escalated case | 8 |
| 10 | Cost model | What is charged: ingest, storage, queries scanned, agent activity, human escalation? | A priced example for your own data volume | 8 |
| 11 | Residency and exit | Where is data processed, and what leaves with you: raw data, detections, decision records? | Data residency statement and export format | 8 |
Weights total 100. A vendor scoring under 60 is selling a roadmap. 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 proof of concept and the easiest to leave out of a slide.
How to run the evaluation:
- Pick three closed incidents from the last year, including one where the evidence was more than three months old at the time.
- Give each vendor the same raw data and the same three incidents, without the answers.
- Score criteria 1 to 5 from what the agents actually did, not from the demo script.
- Ask for criteria 6 to 11 in writing, with the evidence listed in the table.
- Have the analysts who worked the original incidents score the verdicts blind.
- Keep the scorecards. They are the start of your own governance record for whichever platform you choose.
What does an agentic SOC cost?
Pricing models differ more than the products do. Per-GB ingestion pricing charges for data volume, and pushes teams to leave sources out. Query-scanned pricing, such as Sentinel's data lake tier, charges each time data is read, which matters more with agents than with people, because a patient agent hunting over a year of data reads far more than an analyst would. Per-endpoint pricing is predictable but can hide the cost of log sources. MDR pricing buys hours of human analysts.
Ask each vendor what an agent's hunt over twelve months of your data would cost on their model. The answer tells you whether their pricing was designed for agents or for people.
SenseOn's cost model has three parts: edge processing that removes unnecessary data before the pipeline; routing down three pipelines, configured by Weave, SenseOn's security engineering agent, with storage separated from compute; and compression, with pricing calculated on the compressed storage volume rather than raw ingest. Together these cut costs by about 40% against a traditional SIEM. SenseOn's price also covers the work of its Agentic Cybersecurity Team (ACT), charged for the agents' activity rather than as an MDR service, and there is no charge when a case is handed to a person. See pricing for the detail.
What are the risks of an agentic SOC?
Silent wrong closure. A broken playbook throws an error. An agent that starts closing a class of true positives produces a calmer queue and no error at all. Review a sample of agent-closed cases on a schedule, and track the result.
Over-permissioned agents. An agent with broad write access is a new privileged identity in your estate. Treat it like one: least privilege, named owner, reviewed scope.
Injection through telemetry. Covered above. Anyone who can get a string into your logs can try to instruct your investigator.
Cost runaway. On query-scanned pricing, agents that hunt widely can generate bills nobody forecast. Cap it, or choose a model that does not charge per read.
Lock-in of the decision record. If the record of why cases were closed lives only inside one vendor's platform, leaving means losing your audit history. Ask what leaves with you.
How SenseOn runs an agentic SOC
SenseOn is an Intelligence Fabric: the Data Fabric connects and normalises security signals, and the Intelligence Fabric correlates them into cases. Horus is the agent orchestrator analysts work with. It coordinates specialist agents for defined work, and each job names its human decision: Resolve gathers and joins case evidence and an analyst decides whether to close or escalate; Hunter prepares hunt queries and evidence for a person to review; Forge drafts and tests detection changes for a detection engineer to approve; Weave supports source and pipeline setup for a person to validate; Insight ranks posture findings for the accountable owner to prioritise.
Underneath, SenseOn detects at three speeds: in real time on the endpoint through the Universal Sensor, in near real time across all log sources as they stream through SenseOn's message queue, and with scheduled analytics that run about every five minutes across the data lake. SenseOn's agents can run queries and threat hunts across all retained data, in every storage tier and for the whole retention period. Data rolls from one tier to the next automatically, and any source can be routed straight into the tier that suits it, without losing detection or agent hunting over it.
Every AI and analyst action writes to Decision Trace, an append-only record with 100% coverage by design rather than by sampling. SenseOn publishes its outcomes with their method on proof points: 92.5% of incidents resolved by AI under human governance, measured over a rolling 30-day window across all customer environments, and a true-positive density of 0.68% across more than 30 million investigated cases. The job-by-job detail is on AI for security, and the architecture is on the platform page.
Related reading: SOC as a service for the managed alternative, SOC automation for what to automate first, and agentic AI security for governing the AI agents elsewhere in your estate.
Frequently asked questions
What is an agentic SOC?
An agentic SOC is a security operations centre where AI agents plan and carry out multi-step security work, such as triage, investigation, hunting and detection engineering, across the SOC's tools and data. People set each agent's scope and keep the consequential decisions. The difference from SOAR is that an agent is given a goal and works out the steps, rather than following a script written in advance.
What is the difference between an agentic SOC and an AI SOC?
The terms overlap and vendors use them interchangeably. "AI SOC" is the broader label for any SOC where AI does investigative work, including assistants that only answer questions. "Agentic SOC" is narrower: it means AI agents that plan and act across tools on their own initiative within a granted scope. Compare what each product actually does unattended rather than the label.
Is an agentic SOC the same as an autonomous SOC?
No. Both use AI agents, but an agentic SOC keeps a declared human decision for each job, while an autonomous SOC removes it. Autonomy is reasonable today for high-confidence, low-consequence alert classes. For the whole SOC it is a roadmap, and accountability for a closed case still has to sit with a named person.
How do you evaluate an agentic SOC platform?
Score it on what the agents actually do with your own data, not on a scripted demo. The criteria that matter most are data reach across every storage tier, detection latency per source, evidence citations in every verdict, decision-record coverage, per-agent scope, reversibility, measured outcomes with denominators, injection resistance, human handover, cost model and data exit. The scorecard in this guide weights all eleven.
Will an agentic SOC replace SOC analysts?
No. It removes most tier-1 triage work and changes the rest. Analysts move towards detection engineering, hunting and governing the agents: setting scopes, reviewing decision records and checking agent-closed cases. Research on human-AI teaming in the SOC argues for moving between automated, augmented and collaborative modes case by case, which keeps skilled people at the centre of the work.
Sources
- Srinivas, S. et al. (2025). AI-Augmented SOC: A Survey of LLMs and Agents for Security Automation. Journal of Cybersecurity and Privacy, 5(4), 95.
- Baruwal Chhetri, M., Tariq, S. et al. (2024). Towards Human-AI Teaming to Mitigate Alert Fatigue in Security Operations Centres. ACM Transactions on Internet Technology.
- Tariq, S. et al. (2025). Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities. ACM Computing Surveys.
- Greshake, K. et al. (2023). Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. ACM AISec Workshop.
- NIST (2023). AI Risk Management Framework 1.0.
- OWASP. LLM01: Prompt Injection.
- MITRE. ATT&CK.
- Microsoft Learn. Manage data tiers in Microsoft Sentinel.
- Splunk. Store expired Splunk Cloud Platform data in a Splunk-managed archive.
How SenseOn writes, checks and corrects its content: editorial standards.
