Agentic SOC: State of the Field

On this page

• Question
• Current position
• Supporting evidence
• Production evidence by SOC function
• Counter-evidence
• Anchor artifacts
• How this position has evolved
• Open sub-questions

Question

What does an agentic SOC look like in 2026, and where are the load-bearing capabilities, gaps, and emerging standards? Specifically: which functions (triage, detection engineering, response action, threat hunting, post-incident review) have credible agentic implementations in production? Where are the trust boundaries between defender LLMs, the SIEM/XDR substrate, and human approvers? What does maturity progression look like for an enterprise SOC adopting agentic capability?

Current position

The 2026 agentic SOC is converging on a vendor-driven, copilot-plus-specialized-agents pattern. Microsoft Security Copilot anchors one end of the market with a fleet of role-specialized agents (Security Analyst, Alert Triage, Conditional Access Optimization, Data Security Posture, Data Security Triage) plus 15 partner agents in the Security Store. CrowdStrike is extending Falcon with AIDR (AI Detection & Response), reframing EDR/XDR as agent-aware. Google anchors the other hyperscaler end with a matching roster on the Google SecOps and Google Unified Security substrate — alert triage and investigation, malware analysis, detection engineering, threat hunting, and third-party context agents — orchestrated with A2A and MCP and shipped alongside per-agent identity and LLM-as-a-judge anomaly-detection governance. Microsoft also operates a separate defender-AI stack at the AppSec / vulnerability-research layer via MDASH (multi-model agentic scanning harness, 100+ specialized agents in a Prepare-Scan-Validate-Dedup-Prove pipeline; announced May 2026). The defender-side surface is no longer “buy an AI tool”; it is “deploy a coordinated set of agents under shared governance,” and both hyperscalers now ship that governance — identity, authorization, and anomaly detection — alongside the agents.

Three load-bearing capabilities distinguish a real agentic SOC from an LLM bolted onto a SIEM:

1. Defender-LLM governance. The same identity, authorization, and audit substrate that secures agentic AI applications (see Microsoft Entra Agent ID, Microsoft ZT4AI) applies to defender agents. A triage agent is a non-human identity that must be inventoried, authorized, and audited.
2. Action authority and blast radius. What an agent can do unilaterally, with HITL approval, or never. The Plan-Validate-Execute pattern from the agentic-AI side translates directly: the SOC variant gates response actions through approval workflows.
3. Continuous evaluation. The prompt-volume-to-alert ratio is one signal-to-noise metric; the broader question is how the four-quadrant red-team coverage from CMM D7 L4 applies to the defender agents themselves.

Supporting evidence

• Microsoft’s Secure Agentic AI end-to-end makes “Defend with agents and experts” Pillar 3 of its framework. Vendor framing now treats agentic defense as first-class.
• Google’s agentic SOC is the second hyperscaler instance of the copilot-plus-specialized-agents pattern: Gemini agents across Google SecOps and Google Threat Intelligence, governed by per-agent cryptographic identity, an LLM-as-a-judge anomaly detector, and a Security Command Center posture dashboard. Those governance primitives map onto the reference architecture’s Identity and Observability planes, which is direct evidence that the defender-side stack is the same architecture as the application-side stack. Performance figures are vendor-reported.
• Behavioral anomaly detection for agents supplies the runtime profiling primitives that defender agents both consume and emit.
• Agent observability practices apply symmetrically: the SOC is both the consumer of agent telemetry and itself an agentic system that must be observable.
• CR framework (Continuous Detection / Continuous Response, May 2026) is a third vendor framing of the converged SOC: detection, investigation, and response run as one continuous loop on a single reasoning plane, where closed investigations compress automatically into new context-specific detections on top of a Security Context Graph. It is single-vendor-coined and directional, with no independent benchmark, but it names the same shift the Mallory threads, not cases framing points at: the rule-library-plus-case-queue SOC giving way to a continuously reasoning loop.
• Gartner’s seven evaluation questions (analysts Lawson and Davies) supply the buyer-side complement to these vendor framings: criteria to separate genuine operational improvement from marketing, centered on TDIR and mean-time-to-contain outcomes, autonomy boundaries (human-in- versus human-on-the-loop), integration depth, and explainability. Gartner frames a wide projected gap between AI-SOC-agent adoption and measurable improvement that structured evaluation is meant to close. Maxim Kovalsky’s capability-based, configure/buy/build vendor framework is the practitioner instance of the same buyer-side discipline, resolving each AI-security capability against the actual deployment rather than the marketing claim.
• OWASP’s State of Agentic AI Security and Governance frames the constraint the defender side inherits from the application side: organizations are deploying agents faster than they can govern them, and the report argues governance must move from periodic audit to continuous oversight. A SOC standing up defender agents and monitoring agentic applications operates on both sides of that mismatch at once — its own agents are an under-governed deployment, and the agents it watches grow faster than review cycles. The report also names human oversight at machine speed as an unsolved problem, which is the same trust-boundary tension the action-authority capability above tries to bound.
• Open-weight specialized agents are an alternative to the vendor stacks, not only a research curiosity. Brown and Prashant’s (AWS) Open Trajectory Gym shows a security agent post-trained in-house — supervised fine-tuning, group-relative reinforcement learning on trajectories, and test-time prompt evolution — lifting a 27B open-weight model’s benchmark solve rate nearly threefold in under a day. It is a pentest-agent demonstration rather than a defender deployment, but it establishes that a SOC is not limited to buying vendor agents; it can train open-weight agents against its own evaluation-driven optimization loop.

Production evidence by SOC function

The SOC functions named in the question — triage, detection engineering, response action, threat hunting, post-incident review, and the evaluation that spans them — now have credible agentic implementations. The evidence groups by function rather than by source, because the same capability surfaces across vendor products, practitioner production accounts, and open research: |Unprompted

• Whole-SOC architecture. The supervisor-worker topology recurs at every scale: Microsoft’s and Google’s copilot-plus-specialized-agent fleets at the hyperscaler end, and Salesforce’s Polyphonic supervisor-worker SOC (Beyond the Chatbot) as a production instance of the same shape.
• Detection engineering. Agents author detection content from live telemetry instead of humans writing rules against vendor libraries. GreyNoise’s Orbie generates rules from internet-scale honeypot data; Palo Alto’s SYARA applies cost-ordered, YARA-like semantic detection; Microsoft’s BinaryShield adds privacy-preserving cross-service threat-intel sharing. The recurring claim is that domain knowledge embedded in tooling matters more than model choice.
• Threat hunting. Datadog’s automation-boundary work migrates from a single agent to an orchestrator-subagent system and names an explicit boundary between where AI accelerates hunting and where it adds risk; SANS’s SIFT — Find Evil wires Claude Code into a DFIR workstation over MCP.
• Incident response and triage. Wiz’s Shai-Hulud post-mortem scales internet-scale incident response with multi-agent triage engines that parallelize victimology and automate secret-impact analysis; Salesforce’s 30-alerts work shows behavioral-baseline triage at production scale; Uber’s ADR runs a SOC-shaped triage-then-reason detector over its own agent fleet across a ten-month production deployment, surfacing credential exposure as the dominant true positive and reporting a 49% false-positive share on context-rich coding sessions (arXiv:2605.17380); Stripe’s “Guardrails beyond Vibes” runs threat-modeling and security-request-routing agents with offline and online evaluation.
• Evaluation. Airbnb’s capability-centric evaluation argues that outcome-only benchmarks misjudge agents on the multi-stage find→confirm→patch→validate loop; Meta’s “measuring agent effectiveness” talk and Maxim Kovalsky’s capability-based vendor framework approach the same problem. With Gartner’s criteria and DefenseBench’s scores, this cluster frames the evaluation gap below. Uber’s ADR-Bench adds a 302-task, MCP-native comparator, though it measures detection of attacks against agents rather than agents performing SOC work, so it narrows the attack-detection axis without closing the agents-do-defense-work gap.

Across these accounts the production pattern is consistent: a supervisor-worker (orchestrator-subagent) topology, an explicit human-authority boundary, evaluation built into the loop, and domain knowledge carried in the tooling rather than the model. That convergence — vendor framings and practitioner production accounts pointing the same direction — supports the developing position stated above. The practitioner accounts include talks from the Unprompted March 2026 agenda.

Counter-evidence

Independent benchmarks (narrowing)

A public defender-agent benchmark now exists: DefenseBench, whose active BOTSv3 benchmark scores agents on incident investigation over Splunk’s Boss of the SOC v3 dataset. It narrows but does not close the gap. It is a research preview on a single Splunk-derived dataset, with thin published methodology, and its leaderboard currently measures general coding agents rather than purpose-built defender agents. There is still no broad, multi-task, community/academic comparator equivalent to AgentDojo’s role on the agent-security side, and vendor-published numbers still dominate the AI-SOC-agent category. Gartner’s evaluation framework supplies buyer-side criteria (what to ask, what outcomes to measure) but not scored product comparisons.

Anchor artifacts

The agentic SOC has its own reference architecture and capability maturity model, separate from the Agentic AI Security RA and Agentic AI Security CMM that secure agentic-AI applications. Both are now built:

• Agentic SOC Capability Maturity Model — the maturity half. Two coupled axes (a per-function autonomy ladder L0–L4 and eight maturity domains L1–L5) under one gating rule: maturity gates autonomy, so a function’s earned autonomy ceiling is set by its weakest governing domain. Right-sized by an org-profile axis; crosswalked to SOC-CMM, NIST IR 8596, and ATT&CK + D3FEND + ATLAS.
• Agentic SOC Reference Architecture — the structural half. Six planes (orchestration, identity & action-authority, deterministic policy & enforcement, data & knowledge, observability & evaluation, human-authority boundary) with per-function agent surfaces, realizing the CMM’s function × autonomy grid.

The two pairs share primitives: per-agent identity, action-authority gating, and observability recur on both sides, so the SOC’s own agents are secured by the application-side stack like any other non-human identity; the overlap stops there. The SOC’s operational architecture (detection engineering, threat hunting, response-action authority, and continuous evaluation as first-class planes and domains) is a surface the application-security stack does not model; capturing it is what the dedicated pair exists for. The earlier alternative, annotating the existing RA with a defender mode, is superseded by the dedicated pair. One contribution opportunity surfaced during the build: MITRE D3FEND is thin on AI-era defensive techniques, tracked as the D3FEND AI-defense technique gap.

How this position has evolved

The page was seeded 2026-05-13 during the wiki scope expansion. The entries below track shifts in the position as evidence accumulated; operational history (which pages were created or linked when) lives in log.md.

• 2026-05-15. *From Threat Intel to VulnOps* named four structural framings the thesis had implied but not stated. L1-SOC absorption: alert triage, initial investigation, and ticket routing move into existing SOC-automation and AI platforms, driving a workforce shift. “Monitor mode” end state: SOC teams hand routine work to agents and shift to supervision. CISO role evolution: from incident commander to a router translating between AI-enabled operational teams and business leaders. “Threads, not cases”: case queues give way to live analyst-agent investigation threads. The source is single-vendor (Mallory / Jonathan Cran), so these are directional. It also gave VulnOps a second framing, CTI plus vulnerability-management fusion, independent of the discovery-and-remediation-DevOps framing.

• 2026-05-25. CR added a third vendor framing of the converged SOC, after Microsoft’s copilot-plus-agents pattern and Mallory’s CTI fusion: detection treated as compressed investigation, run as one continuous loop on a single reasoning plane over a Security Context Graph. Vendor-coined and unbenchmarked, but it points at the same shift from rule-library-plus-case-queue to a continuously reasoning loop.

• 2026-05-25. Gartner’s seven evaluation questions supplied buyer-side criteria centered on TDIR and mean-time-to-contain outcomes, autonomy boundaries, integration depth, and explainability. This addresses the evaluation sub-question with criteria to ask, not scored product comparisons, so it narrows but does not close the benchmark gap below.

• 2026-05-25. Corrected an over-stated absence claim. The counter-evidence had read “no public benchmark equivalent to AgentDojo for defender agents”; DefenseBench (BOTSv3, over Splunk’s Boss of the SOC v3) disproves it. The gap was narrowed to its accurate form: DefenseBench is a single-dataset research preview that currently scores general coding agents, so a broad multi-task comparator is still missing.

• 2026-05-25 / 26. The Unprompted March 2026 defender talks, read through the agentic-SOC lens, converged on one production pattern: a supervisor-worker topology, an explicit human-authority boundary, evaluation built into the loop, and domain knowledge carried in the tooling rather than the model. With vendor framings and practitioner accounts pointing the same way, the status moved from seed to developing.

• 2026-06-01. Captured Google’s defender-side surface in Google Agentic SOC, addressing a gap in the thesis’s vendor coverage. Google’s offering is the same copilot-plus-specialized-agents pattern as Microsoft: Gemini agents for alert triage and investigation, malware analysis, detection engineering, threat hunting, and third-party context, on the Google SecOps and Google Unified Security substrate, orchestrated with A2A and MCP and governed by per-agent cryptographic identity and an LLM-as-a-judge anomaly detector. It is consistent with the supervisor-worker-plus-governance convergence; the performance figures remain vendor-reported.

• 2026-06-02. Resolved the anchor-artifact sub-question: the agentic SOC gets its own reference architecture and capability maturity model, distinct from the Agentic AI Security RA/CMM rather than a defender-mode annotation on them. The pairs overlap only where the SOC’s own agents must be secured like any other non-human identity; the SOC’s operational architecture (detection engineering, threat hunting, response-action authority, continuous evaluation) is its own surface. Also reframed the production-evidence section around SOC function rather than the Unprompted conference, since the same capabilities are evidenced across vendor products, practitioner accounts, and benchmarks; retired the talks-vs-RA/CMM comparison page the section had leaned on.

• 2026-06-03. The dedicated pair was built. The Agentic SOC CMM and Agentic SOC RA were authored as origin: produced deliverables from an approved design spec, closing the anchor-artifact sub-question in practice rather than in principle. The CMM’s organizing idea — maturity gates autonomy, with a function’s earned ceiling set by its weakest governing domain — is the structural choice the prior-art scan had left open (staged like the autonomy ladders versus continuous like SOC-CMM): the model carries both, a staged autonomy ladder per function and continuous CMMI-shape maturity domains that gate it. Three framing decisions accompanied the build: the durable subject is trusted-autonomy operations (mechanism-agnostic, written to outlast AI’s normalization), in-house AI applications are a monitored asset class rather than a separate framework (threat-modelled by ATLAS in D6, with AI-IR playbooks and AI-app telemetry), and AI is treated as a barrier-lowering enabler that brings SOC-grade automation below the cyber-poverty line, not only an autonomy ceiling-raiser. The build also surfaced the D3FEND AI-defense technique gap. Prior-art grounding landed alongside: the five-ladder comparison, NIST IR 8596, the MDPI survey, and the SIEM-less security data pipeline concept.

• 2026-06-02. An external prior-art scan grounded the planned pair against published work. Five levels-of-autonomy ladders converge on one spine: manual → assisted → approval-gated → conditional (human-in-the-loop) → delegated, with an asymptotic top tier rather than a terminal fully-autonomous level. They are a SOC-specific trusted-autonomy framework (Mohsin et al.), the MDPI *AI-Augmented SOC* survey, an offense-leaning cybersecurity-AI taxonomy (Mayoral-Vilches), the Darktrace AI Maturity Model for Cybersecurity, and the CSA Levels of Autonomy; the comparison is catalogued in Agentic SOC Autonomy Ladders. The incumbent SOC maturity standard, SOC-CMM, did not yet model AI or automation as of its May 2025 report, leaving the agentic surface open to occupy. NIST IR 8596 supplies a CSF 2.0 Secure/Defend/Thwart crosswalk target with no maturity tiers of its own. The scan also corrected a misattribution it had initially produced: the L0–L4 “Manual Operations → AI Delegation” level names belong to the Darktrace/CSA model, not to the MDPI survey. That primary was then read directly — its five levels (Manual → AI-Assisted → Semi-Autonomous → Conditionally Autonomous → Fully Autonomous) proved near-identical to the Mohsin et al. ladder, and the survey publishes an explicit crosswalk of those levels onto SOC-CMM maturity 1–5, a template for the planned model’s standards-crosswalk layer.

Open sub-questions

• The dedicated Agentic SOC RA and CMM are built (see Anchor artifacts), which closes the two design questions this section previously carried: the planes and domains are now fixed (six planes, eight functions, eight maturity domains), and the staged-versus-continuous choice resolved to carrying both — a staged per-function autonomy ladder gated by continuous CMMI-shape maturity domains.
• The “how” depth layer is the open follow-on: per-domain or per-function deep dives carrying dated control landscapes, tooling maps, and cost models, mirroring the application-security CMM’s domain deep dives. The CMM and RA fix the framework these hang from.
• The gating thresholds (which domain maturity supports which autonomy level) are anchored to the MDPI ↔ SOC-CMM correspondence but not yet empirically calibrated; the Gartner criteria and DefenseBench are candidate calibration signals.
• The remaining evidence gap is still evaluation: a broad, multi-task defender-agent comparator does not yet exist (see Counter-evidence).
• See Gaps Index for related open questions, including the D3FEND AI-defense technique gap.