I've sat through nine AI SOC demos since January. Every vendor said agent. By my read, two were selling one: a system that plans and carries out its own investigation by calling tools and acting on what it finds.
The rest were an LLM summarization layer on a product I already own, or a security orchestration, automation, and response (SOAR) platform with a model wired into a few decision points.
The architecture underneath the label drives production failures, the year-two line item, and accountability when the system closes a real incident. Three patterns cover most of the market: wrappers, workflows, and agents. Real products often blend them, so treat this as a working buyer's taxonomy, not a clean market segmentation.
In brief:
- AI SOC can describe an assistant, an AI-enabled workflow, or an agentic system. Treat it as a working architecture taxonomy, not a vendor category.
- A wrapper assists a human; a workflow follows mostly predefined control logic with AI at bounded steps; an agent lets the model choose the next investigative step and tool based on the evidence so far.
- These are dominant risk patterns, not exclusive ones: wrappers can hallucinate or over-recommend, workflows break on alerts their authors never anticipated, and agent behavior is harder to attribute after the fact.
- Don't classify a product by whether it acts after hours. Classify it by who controls the next step, which actions run without approval, and what decision-and-action record it retains.
Why AI in the SOC needs a taxonomy at all
The practical definition of an AI SOC is a security operations function where AI performs analysis or response work. It's accurate and unhelpful, because it says nothing about where the control flow lives, and control flow is what a buyer is actually paying for.
One label, three very different things underneath
Phrases like agentic AI and autonomous SOC now appear so uniformly across vendor materials that they no longer identify a specific architecture, and LLM wrappers used as chatbots or workflow triggers now claim agent status too. A marketing label doesn't reliably reveal whether a product can independently select tools and take action, or only assist an analyst.
Anthropic's engineering team draws the useful architectural distinction: systems whose paths are controlled by predefined code, versus systems in which the model dynamically directs its own process and tool use.
That line, not the badge on the datasheet, is what a buyer needs to find. The distinction splits into a few questions worth asking separately: who owns the control flow, which actions can run without approval, what case state persists, how the work is audited, and how far the system can adapt within its bounds.
Wrappers: an assistive layer over an existing tool
A wrapper is an assistive interface around an existing security product. A prompt or case context goes in; a summary, query, draft, explanation, or recommendation comes back. A wrapper may use retrieval and session context, but it doesn't independently direct a multi-step investigation, and the analyst or a separate workflow decides what happens next.
What they do well, and where they stop
Wrappers earn their keep on query translation and on summarization or drafting. Microsoft's NL2KQL work turns plain language into Kusto Query Language (KQL), and practitioners use LLMs in detection engineering to draft triage checklists and rule fragments, best treated as suggestions a human validates before adoption.
A Cloud Security Alliance benchmark reported analysts using AI assistance completed the study's scenarios 45 to 61% faster and identified required actions 22 to 29% more accurately than manual teams.
The study involved vendor participation and specific scenarios, so read it as evidence of assistive potential, not a production guarantee: tool integrations, alert quality, case mix, and analyst experience all move the realized number.
These are assistive gains, and the analyst still carries the investigation. I've bought a wrapper knowingly and been happy with it, because my analysts write queries faster. The vendor that lost me sold the same architecture as an autonomous SOC at agent pricing.
Workflows: orchestrated automation with AI in the loop
A workflow is orchestrated automation whose control flow is authored in advance. The playbook can call AI for bounded tasks such as classification, enrichment, extraction, triage, or summarization, but policy-authored logic controls the sequence, permissions, escalation paths, and irreversible actions.
Deterministic paths, AI at the decision points
The best implementations are explicit about the boundary: AI handles judgment where it adds value, and authored logic executes the steps that must stay reliable and auditable, with irreversible actions behind deterministic controls or human approval.
A workflow can be reproducible, but only when teams version the playbook, prompts, models, tools, data sources, and sampling settings. If it calls an LLM, don't assume identical outputs without those controls and a retained execution record. That reproducibility is why workflows suit environments where alert types are known and the audit bar is high.
Their limit is maintenance and coverage. Playbook-heavy SOAR accumulates scripts, brittle integrations, and unclear ownership over time, and a workflow handles the unanticipated only as well as its authored fallbacks and exception queues allow.
Agents: systems that decide and act
An agent is a system in which the model chooses the next investigative step and uses tools in response to the evidence collected so far. Dynamic planning, not unrestricted action, is the distinction. An agent can run read-only enrichment autonomously while still requiring approval for containment, account disablement, or notification.
What qualifies a product as an agent
Anthropic's working definition centers on LLMs using tools autonomously in a loop, while NIST's agentic definition emphasizes independent decisions, goal-driven behavior, learning from interactions, and adaptation to changing environments. In SOC terms, agentic investigation is an evidence-driven loop whose next steps change based on what it finds.
The strong evaluation questions are whether the model, rather than a fixed playbook, selects the next step; whether it keeps case state across steps; and which actions it can take without approval. State and unattended action are important to probe, not strict requirements for the label.
ReliaQuest, in its own terminology, distinguishes a single AI agent that executes one SOC task from an agentic system that orchestrates several toward end-to-end outcomes.
In production, autonomy runs on graduated levels, and bounded agency with humans in the loop remains the practical model. Human-in-the-loop means a person approves before an action; human-on-the-loop means the system acts within authorization while people supervise and can intervene.
Gartner's 2024 research, Predict 2025, argues there will never be a fully autonomous SOC, best read as a caution against full replacement, not a rejection of automation.
How to tell which one a product really is, and why it changes what you buy
The category sets your failure modes and commercial exposure. Misclassify, and you pair agent-grade risk with wrapper-grade oversight, or pay agent prices for wrapper capability.
The questions that expose the category
These questions test architecture, deployed autonomy, governance, and economics separately, which is the only way to see past a polished demo.
- Who selects the next investigative step? The clearest architecture test: show whether a human-authored playbook, deterministic logic, or the model picks the next tool and action. Anthropic's workflow-versus-agent line turns on exactly this.
- Which actions run without human approval? Ask for an action-permission matrix (read-only queries, enrichment, ticketing, notification, account disablement, host isolation, firewall changes) and whether approvals are configurable by action, asset criticality, and confidence.
- What happens when nobody is watching? Useful, but it reveals configured autonomy, not architecture. A workflow can execute an approved containment step unattended, and an agent can be deliberately held to read-only investigation.
- Show a novel investigation, not a known-path demo. Supply an unfamiliar alert and ask for the initial hypothesis, tool calls, evidence returned, plan changes, confidence, and escalation decision.
- Show the auditable decision record. Don't demand the model's private reasoning; ask for exportable logs of tool calls and parameters, retrieved data, model and version, policy checks, action results, confidence, approvals, and outcome.
- Replay the same case under pinned conditions. With model version, prompts, tool schema, retrieval sources, and sampling settings fixed, compare the evidence and action sequence. Output variation reveals reproducibility and change control, not whether the product is an agent.
- Turn off the AI layer and see what remains. Frame it as an incremental-value test: what automation, integrations, and detection remain, and what does the AI layer actually add?
Taken together, these expose where control actually lives and where the governance work starts. In my last two evaluations, the questions revealed a narrower autonomy boundary than the opening demo suggested, so buy and price the category you can actually govern.
Pricing tracks architecture loosely and varies too much to predict: alert or investigation volume, endpoints, data, users, cases, or compute all show up in AI SOC contracts, and per-alert models can punish noisy environments. Model it against 90 to 180 days of your own alert and action volume, not a clean demo, and get costs at current, double, and triple volume.
Accountability shifts too. A workflow failure traces to a human-authored step, while agentic failure is harder to attribute across model behavior, tool use, and dynamic routing.
Contracts should cover output accuracy, data handling and retention, model and subprocessor changes, audit access and log retention, tool permissions, rollback and emergency-disable controls, incident notification, and responsibility for consequential automated actions.
Frequently asked questions about AI in the SOC
What does an AI SOC actually mean?
An AI SOC is a security operations function where AI performs analysis or response work, a practical definition, since the term has no stable industry standard. The label spans the three architectures in this taxonomy: an assistant, an AI-enabled workflow, and an agent.
Gartner's 2026 Security Operations Hype Cycle treats AI SOC agents as an early-maturity category near the Peak of Inflated Expectations. Verify any exact penetration or maturity figures against the underlying Gartner report before using them in board or procurement material, since the widely quoted numbers come from secondary summaries.
What is the difference between an AI agent and an LLM wrapper?
A wrapper passes a prompt to a model and returns output for a human or a workflow to act on. An agent lets the model plan the next step from prior results, call tools, and act within defined bounds.
The dividing line is who controls the next investigative step: if a fixed playbook or a human always does, it isn't an agent, though it may still be an AI-enabled workflow rather than a mere wrapper.
What counts as an agentic SOC?
An agentic SOC is a governed operating model in which AI agents can perform bounded investigation and response across multiple tools, with explicit supervision, approvals, reversibility, and evidence trails. Governance and clear bounds define it, and humans stay at defined decision points.
How do you evaluate an AI SOC product's real capability?
Force the architecture into the open: ask who selects the next investigative step, get the action-permission matrix, run a novel alert through it, replay a case under pinned conditions, and request the exportable decision-and-action record rather than the model's private reasoning.
Then replay your own historical alerts in a proof of concept instead of accepting vendor benchmarks.