AI in the SOC: Detection and the Security Operations Center

11 min read

The first time I sat behind the glass in a working security operations centre, what stuck with me was the silence between the analysts. They were not typing. They were reading. Hour after hour, parsing alerts that mostly said nothing, waiting for the one that said something. The job was attention, and attention is the most fragile resource a SOC has.

AI is now pressing on that resource from two sides. Attackers use it to manufacture more believable noise faster than humans can sort. Defenders use it to triage that noise before it reaches the analyst. The same technology shows up on both sides of the glass in the same quarter, and the SOCs I see thrive are the ones that refuse to pretend either side is winning yet.

This piece is the operator view. What AI-augmented attackers do differently in 2026, where AI inside the SOC earns its keep, where it adds expensive noise, and how to wire AI Security into workflows the SOC already runs.

The attacker side: faster, cheaper, more convincing

Three shifts on the offensive side change what reaches the analyst’s queue.

Phishing at scale, with grammar. Generative models have removed the cheapest tell defenders relied on for two decades. A 2026 spear-phish reads like the legal counsel it impersonates, in the right register, with the right internal jargon, sometimes referencing a real meeting from a leaked calendar. Volume is up, quality is up. The SOC sees the same intent dressed better.

Voice and video deepfakes for social engineering. The vishing call asking the help desk to reset a CFO’s MFA now arrives in the CFO’s actual voice. Insurance claims from 2025 already include cases where the deepfake worked and the wire moved. The SOC owns the post-mortem.

Adversarial evasion of detection models. The detection layer is itself a model now. Attackers test against open-source classifiers offline until they have a payload that slips through, then they ship. The technique is documented in MITRE ATLAS as the AI counterpart to MITRE ATT&CK. Any defence built on a single static model is a target.

The takeaway is unglamorous. The blue team’s first job in 2026 is not to deploy more AI, it is to assume the red team already did, and recalibrate what “normal” looks like in the inbox, the call recording, and the model output the SOC depends on.

The defender side: where AI inside the SOC earns its keep

Inside the SOC, AI is doing real work in three narrow places. Narrow tools that ship beat broad tools that demo.

LLM-assisted triage. The first hour of every analyst’s shift used to be reading. A language model that drafts the “what happened, what is the host, what is the user, what is the recommended next step” summary against the raw alert removes most of that reading. The analyst still decides, the model just stops them re-typing the same paragraph forty times a day. The condition is that the model summarises, never actions.

Anomaly detection on the right surface. Anomaly detection was promised for fifteen years and disappointed for fourteen, mostly because it was pointed at network traffic where the signal-to-noise is brutal. The version that works in 2026 is pointed at user and entity behaviour with rich context (identity, app, time, location, peer group). It still produces false positives. The difference is that the model offers an explanation an analyst can read in ten seconds: “this account printed three hundred customer records at 02:17, peer group prints two on average, last similar event was a confirmed exfiltration in March.” Explanation is the load-bearing word. An anomaly score without it is a riddle.

Automated runbook execution on the boring end. The bottom third of the SOC’s runbook is mechanical: enrich the IP, pull recent logins, kick the file to the sandbox, open the ticket. An agent that does this on its own, with the analyst approving any action that touches production, frees the team for work that needs judgement.

The trap: false-positive storms and analyst burnout

Here is the side the vendor decks skip. The same models that catch the subtle attack also produce alerts at a rate the team cannot service. A detection model that improves recall by a few points often degrades precision by more, and the cost lands on the humans you were trying to free.

I have walked into two SOCs in the last six months where the ML-driven detection layer produced more alerts than the team had hours to read. Both were sold as labour savers. Both became labour multipliers, because the model was tireless and the analyst was not. One had quietly muted the channel. The model kept running. Nobody was listening.

The fix is operational. Before you turn a detection model on in production, you need three things in writing: who owns the alert volume budget, what the tuning loop is, and what happens when the channel exceeds budget for two weeks (the answer must be “the model is muted or retrained”, not “the analysts work harder”).

Wiring AI Security cases into the existing SOC workflow

The cleanest pattern treats AI-specific incidents as a new alert class on the existing pipeline, not a parallel pipeline. The SOC already knows how to detect, triage, contain, investigate, and learn. AI threats just add new evidence types (prompts, model versions, retrieval contexts) and new containment moves (rollback, kill switch, quarantine the training data) to the same workflow.

Get the AI & data signal, daily.

335k+ subscribers read this every morning. One email, both newsletters. Unsubscribe anytime.

LowMedium / HighYesNo

Signal sources
SIEM, EDR,
identity, model
monitoring

LLM-assisted
triage
(summarise only)

Severity

Agent runbook
(human approves
any action)

Human analyst
investigates

AI-specific
incident?

Invoke AI
incident response:
snapshot, rollback,
kill switch

Standard
SOC playbook

Post-incident
review feeds
detection tuning

7wData

Three integration moves matter. Feed model-monitoring signals into the SIEM as a first-class source, not a separate dashboard nobody opens. Give the AI team a seat on the SOC’s on-call rotation for AI-specific incidents. The SOC has the incident discipline, the AI team has the model knowledge, neither can run the response alone. Third, let the post-incident review feed back into the detection model’s training set with clean labels. Most teams skip this and wonder why their detection drifts.

The response runbook sits in AI Incident Response. The threat surface the SOC defends sits in AI Attack Surface and Prompt Injection. The wider AI Security hub is the home base.

What good looks like in 2026

A SOC running AI well looks ordinary, which is the point. Analysts own the calls. Models do the reading humans cannot scale. The agent does the clicks humans should not be doing. Alert volume sits inside a budget the team can service. The post-incident review changes both the runbook and the model that triaged the alert. The AI team and the SOC are in the same channel at 2 a.m. when something moves.

The SOCs I watch struggle do the opposite. They bought a platform, turned everything on, measured nothing, and the queue got longer. AI did not fail them. The operating model around it never got built.

The defenders who get this right in 2026 will not have flashier dashboards. They will have shorter queues, calmer analysts, and a tighter loop between every incident and the next detection. That is the only scoreboard worth keeping.

Yves Mulkers

Yves Mulkers is the founder of 7wData and a widely followed voice in the data and AI community. He curates the 7wData and AI Beat newsletters, reaching hundreds of thousands of data and AI professionals, and writes on data strategy, analytics, AI, and the evolving data ecosystem.