Every SOC leader has heard the pitch by now: an AI SOC analyst that triages alerts around the clock, never burns out, and costs less than a graduate hire. The pitch is half right. LLM agents are genuinely good at parts of tier-1 work - reading an alert, pulling context, writing up what they found. They are also confidently wrong in ways that a tired human is not, and a SOC that lets an agent close incidents unsupervised has automated its false-negative pipeline.
The engineering question is not whether to use agents in security operations - alert volumes settled that argument years ago - but where to draw the autonomy line and how to verify the work happening below it.
What Agents Are Actually Good At Today
The honest capability list is narrower than the marketing and still valuable:
- ▸Enrichment on demand: Given an alert, the agent queries the SIEM for related events, checks the asset inventory, pulls WHOIS and threat-intel reputation for indicators, and assembles it all into one view. This is mechanical work that eats analyst hours.
- ▸First-draft triage narratives: A structured summary - what fired, which hosts and identities are involved, what surrounding activity looked like, a proposed MITRE ATT&CK technique mapping - that the analyst verifies rather than writes.
- ▸Cross-referencing at machine reading speed: Correlating a phishing report against mail logs, EDR telemetry, and previous cases in seconds.
- ▸Case hygiene: Timeline assembly, deduplication of related alerts, and consistent tagging, which quietly improve every downstream metric.
What agents are not good at is the actual decision: benign or malicious, close or escalate. Models are trained to be plausible; an alert that resembles ten thousand past false positives will read as one, including the eleventh time when it is not.
Read-Only First: The Tooling Ladder
Give the agent tools in stages, and make the stages explicit in policy.
1. Stage one: read-only queries - SIEM search, asset lookup, threat-intel APIs - with per-analyst credentials and full audit logging of every call. 2. Stage two: annotation rights - the agent can comment on cases, propose severity, and attach evidence, but cannot change case state. 3. Stage three: reversible actions behind human approval - quarantine a file, isolate a host, disable a token - each rendered as a one-click proposal showing exactly what will run. 4. Stage four, if ever: autonomous action for a narrow, measured class of alerts where months of shadow-mode data show the agent's false-closure rate at or below your human baseline.
Most SOCs should live at stages one and two for a long time. The value is already large there, and the failure modes are recoverable.
The Attacker Writes Your Input Data
Here is the threat-model twist that generic agent guidance misses: in a SOC, the untrusted input is the telemetry itself. Log fields, process command lines, email bodies, file paths, and user-agent strings are attacker-controlled by definition - and your agent reads all of them. A command line containing instructions aimed at the triage agent, claiming the activity is authorized red-team testing and should be closed as benign, is indirect prompt injection with a security outcome attached.
Treat every field the agent reads as hostile: render telemetry into structured summaries rather than feeding raw strings where possible, instruct and evaluate the model specifically against in-band instructions, and - most importantly - never let content-derived conclusions close a case without corroborating signals. Then red-team it: seed injection payloads into your own test telemetry and measure whether triage conclusions move. If your agent vendor cannot describe their defenses against this, that is your answer about maturity.
Measure False Closures, Not Time Saved
Vendors sell agents on mean-time-to-triage, which is the metric easiest to improve and easiest to fake - closing everything instantly optimizes it perfectly. The metric that matters is the false-closure rate: of the alerts the agent recommended closing, how many were re-opened, contradicted by a human review sample, or later tied to an incident?
Run the agent in shadow mode against historical cases with known outcomes before it touches live queues, and keep a standing human review sample of agent-closed alerts forever. Feed disagreements back as evaluation cases. This is the same golden-set discipline as any production LLM system, pointed at the decision that carries the risk.
The Realistic Business Case
The value of SOC agents in 2026 is not headcount replacement - it is giving scarce analysts their attention back. Enrichment, drafting, and case hygiene absorb a large share of tier-1 time; automating that work shortens queues without touching the risky decision boundary, and makes the analyst role more senior rather than obsolete, which helps the retention problem every SOC has. Teams that deploy agents with a tooling ladder, injection-aware design, and false-closure measurement will get compounding value from each capability upgrade the models deliver. Teams that buy an autonomous analyst off the shelf will discover its error rate during an incident review - the most expensive evaluation environment there is.