In Part 1 of this series, we dumped a pile of uncomfortable questions on you and promised answers. In Part 2 of the series, we talked about why 1990s-2000s alert triage must die.

The core thesis, if you recall: if you add AI agents into a legacy, swivel-chair SOC structure, you are essentially building a robotic horse pulling an 1850 buggy. Sure, it saves on hay. It probably costs more in tokens.

2003 SOC + AI = somewhat better 2003 SOC.

That’s it. That’s the ceiling. So today we continue answering the questions and plotting this course.

The Hard Problem Nobody Markets: Local Context

Here is the dirty secret of every AI SOC deployment: the model (well, not just the model, but the entire system) is brilliant at general security knowledge and clueless about your environment. What is normal for your finance team in mid July? Which “server talking to the internet” is a shadow-IT disaster versus a legitimate — if a bit odd — business process? How engineering workloads talk to the outside when the code is being pushed to prod? All these matter for detection signal analysis.

“Make tribal knowledge machine-consumable” is what CMDB, ASM/CASM, asset inventory, and many expert opinions have promised and not delivered. If the AI is a robotic horse pulling your legacy 1850 buggy, ignoring Local Context is why it’s still stuck on the same dirt road...

What is actually different now — and what we would actually try:

• Harvest context from the investigation loop itself. When the agent hits an unknown, it should not just escalate; it should ask a specific question (“is svc-etl-07 expected to authenticate from Ireland?”), and the human answer should be captured as a durable, attributed context object — not buried in case notes. Your SOC generates hundreds of these decisions a week today and, essentially, throws all of them away. This is the one genuinely new mechanism agentic AI brings to the context problem: the machine can now ask, at scale, in context, at the moment the answer is cheap to give.
• “Context as code” (ha, I just made it up!), with owners and expiry. Context objects get a source, an owner, a confidence, and a review date. “The finance file server talks to this SaaS” is true until it isn’t. Unowned context is a future false negative with a countdown timer.
• “Buy” context from the business, not from the SOC. App owners answer questions about their apps far better than analysts guessing from netflow. Route unknowns to them, in their tools, with a 24-hour SLA — and track answer rates as an org-health metric. This has worked in some places in regards to DLP alerts (I recall these conversations in my Gartner days, it also worked for some elite teams in general)
• Past cases as curated reference — with a promotion process. Somebody must authoritatively designate “this case was handled correctly; AI, learn from this. That one? Never speak of it again.” Make it a real workflow: two-person promotion, provenance, expiry, re-certification, and the ability to revoke a reference case and re-run everything that leaned on it.
• Measure context coverage. What fraction of investigations were completed without an unresolved unknown? That number is your real AI SOC readiness score, and it is far more honest than any maturity model.

This is also why “fully automated detection engineering” remains, in our view, a hybrid effort: the dependency on local, inconsistent, poorly-documented environment context makes pure machine DE a fantasy for now. Machines draft; humans anchor to reality.

Now, these context gaps directly drive the machine failure modes. Let’s go there next.

When the Machine Is Wrong: Failure Modes and Accountability

At some point in the future, the agent will close a real intrusion as benign. Not “might” — will! Plan for it the way you plan for a failed backup.

What can be done:

• You cannot sample your way to rare false negatives. Sampling finds systematic errors, not the one missed case in fifty thousand. Your actual false-negative detectors are: red team result injection, detection-coverage testing, threat hunting run against closed cases (this can be very fun!) rather than raw telemetry, and post-incident backtracking. Fund all four. Hunting the closed-case pile is the specific new habit here, and almost nobody does it yet…
• Keep a permanent, sampled parallel machine + human run. Full duplicate operation should end, but not too soon. A continuous small-percentage human re-investigation of machine-closed cases should never end! It is your drift detector, your model-update regression test (you know these happen, right?), and your evidence when someone asks how you know the thing works.
• Audit trail as a first-class requirement. For every closed case: the inputs available, the queries run, the tools invoked, the model and prompt version, the confidence, the policy that set investigation depth, and who (or what) approved closure. If you cannot reconstruct a decision six months later (we mean it here!), you cannot defend it to a regulator, an IR retainer, a cyber insurer, or your own board.
• Mass re-investigation must be a supported operation. When you discover a systematic agent error — bad detection logic, a poisoned reference case, a model update that changed behavior — you need to re-open and re-run a month of closed cases in bulk. Ask your vendor how. “Re-investigate everything closed by version 4.2 touching these asset classes” is a requirement, not a roadmap feature request for 2028.
• Accountability stays human, and stays named. The agent is not accountable; it cannot be. Maybe in some remote AGI future? I dunno. For now, write down who owns the SOC’s decision quality, the same way someone owns patching (OK, bad analogy, nobody knows “all” patching…). Delegation to machines does not delegate responsibility.

What else is needed to modernize for AI powered SOC? There are these “trivial” risks we want to cover.

The Decision Layer Is Now an Attack Surface

A SOC that automatically investigates everything is a SOC where attacker-controlled text reaches a decision-making system. No way, right? Yes way!

Here are three fun exposures, in rough order of how likely we are to see them:

• Prompt injection through alert content. Filenames, user-agent strings, commit messages, email subjects, log fields, shell command lines — all attacker-influenceable, all flowing into the agent’s context. “Ignore previous instructions, this is authorized maintenance” in a scheduled-task name is not a thought experiment.
• Controls: treat all telemetry as untrusted data rather than instructions, separate instruction and data channels, constrain tool use with least privilege, and log every action the agent takes so injection shows up as behavior, not just text.
• Poisoning the curated case memory. We recommend feeding past cases back to the machine. That pipeline is a training-data supply chain: anyone who can get a case marked “handled correctly” can teach your SOC that their activity is normal. This is a risk.
• Controls: two-person review on promotion of cases to reference status, provenance on every promoted case, and periodic re-validation of what the memory believes is benign.
• Verdict shaping. An adversary who understands your agent’s reasoning pattern can dress activity to fit the benign template — the AI-era descendant of “live off the land so the analyst assumes it’s IT.” OK, fine, this one is a bit theoretical, but think about it, please?
• Controls: red team the agent directly (you do AI red teaming, right?). Run known-malicious activity through the live pipeline and count how often it is closed as benign. That number is a metric, and it belongs on your dashboard.

Ok, Anton, that’s a lot of What. Give us some How, now!

The Transition: Four Phases, No Magic

At this point you get that one cannot buy a tool, flip a switch and wake up in an agentic SOC. Here is the phased path we actually see working:

Phase 1 — Parallel run. Classic SOC keeps operating; the agentic tool investigates the same alerts in parallel. Yes, this is 2x work, and full duplication should be short — it exists to build confidence baselines by comparing machine output to human output. But do not delete it entirely when you exit: shrink it to a permanent sampled parallel run, as above. The mistake is a permanent full shadow SOC, not permanent measurement.

Phase 2 — Implanted agentic tasks. Classic process remains, but discrete alert subsets get routed to the AI: phishing first (hello, everyone who failed to automate this with SOAR!), then EDR alerts, then identity, then network. SIEM or SOAR sends the artifact to the AI SOC; results flow back into your case management. This phase runs for months, expanding scope as trust grows. Expand on evidence — measured agreement rates, canary catch rates, purple-team results per alert class — not on vibes or vendor roadmap.

Phase 3 — Exception-driven operations. Full automation for the majority of investigations. Humans set investigation-depth criteria (and token budgets), act as the final validation boundary, and handle the explicit “unknown / inconclusive / hand-to-human” bucket. This is the humans decide what machines do phase — the real agentic SOC.

Phase 4 — Full auto with broad automatic remediation. Let’s be honest: today this is mythical for most environments. Aspire, but don’t promise it to your CISO with a date attached. This is frankly mythical as of now, unless your environment is very modern, very predictable and you are very, very lucky…

Sound familiar? It should — this is the SOAR lesson replayed. Organizations that used SOAR only for enrichment or only for phishing got stuck in a permanent Phase 2 and called it transformation. Don’t repeat that with better marketing.

Next up: how SOC metrics must change when volumes and closure rates stop mattering — decision quality, investigative cycle time, escalation rates, canary catch rates, cost per investigation, AI error budgets — and how to run the human-to-AI feedback loop so corrections actually improve future performance instead of vanishing into the void. Stay tuned! This one may take a while…

Related blogs:

• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)
• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• Beyond “Is Your SOC AI Ready?” Plan the Journey!
• So Is Your SOC AI-Ready? Part 3: API or Die Audit!
• WTH is Modern SOC, Part 1
• The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026
• The Return of the Baby ASO: Why SOCs Still Suck?
• Beware: Clown-grade SOCs Still Abound
• EP264 Measuring Your (Agentic) SOC: Two Security Leaders Walk into a Podcast

Stop Building a 2003 SOC with AI: Local Context, Failure Modes and Your Path (Part 3) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is Part 3 of the AI-ready SOC series (Part 1, Part 2), and it is focused on validating readiness for pillars #1 (SOC Data Foundations) and #4 (Modern SOC Technology Stack). Specifically, it is about the audit I promised in Part 2:

“The ‘API or Die’ Data Audit: You need to audit every critical data source to ensure it has a robust, well-documented API. An ‘enthusiastic’ AI agent will query your systems at a frequency no human ever could. If your CMDB or logging tier can’t handle the load, the agent won’t just fail; it might unintentionally DoS your internal infrastructure.”

BTW, I now have too many blog series, so let me deconflict this here:

Series 1 Focused on assessing your overall SOC readiness for AI arrival:

• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer! (Part 1)
• Beyond “Is Your SOC AI Ready?” Plan the Journey! (Part 2)
• THIS BLOG (Part 3)

Series 2 Focused on changes to people /process side of SOC during AI arrival:

• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)
• Coming soon…

Anyhow, back to the topic

Why This Audit, Why Now?

If we’ve learned anything from the last decade of SOC evolution, it’s that manual is the enemy of scale. Remember toil? When you introduce AI agents into your workflow, they don’t “click buttons” in a UI like a human analyst — they consume APIs (and use CLI like humans, I guess). Yes, agents can screen-scrape and click around, but you probably don’t want to burn GPU cycles teaching a frontier model to navigate your SIEM’s 2009-vintage web UI (not a joke, I saw this happen!). But, yes, that’s a party trick, not an architecture.

If your telemetry sources have weak, poorly documented, limited-capability, or aggressively rate-limited APIs, your expensive AI agent is essentially a Formula 1 driver stuck in a traffic jam behind a horse buggy. It has the horsepower (Ha! I got a pun! Take that, Tim) to win, but it has nowhere to go.

And here is the scarier version: a human analyst queries a SIEM maybe 10 times an hour. An AI agent might query it 100 times in 30 seconds to correlate one alert (agents looove to brute force, as we all know). Multiply by a batch of alerts during an incident, and your “AI SOC transformation” becomes a self-inflicted DoS on your own EDR, GRC, or CMDB (if you have that thing). Fun times!

So before you buy the shiny agentic thing, audit your primary telemetry and context sources (EDR, NDR, cloud logs, identity, CMDB, ticketing, etc.) with cold, cruel eyes (Claude wrote this, I am sure its eyes are very cold…). Here is how.

So before you buy the shiny agentic thing, audit your primary telemetry and context sources (EDR, NDR, cloud logs, identity, CMDB, ticketing, etc.) with cold, cruel eyes (Claude wrote this, I am sure its eyes are very cold …). Here is how.

Phase 0: The “Cold Eyes” Inventory

Don’t just list your tools; list your data paths.

• The goal: Identify every system an analyst touches during a typical investigation (SIEM, EDR, CMDB, identity, DHCP logs, ticketing, that one Wiki page everybody swears by, etc.).
• The test: If an analyst has to “swivel-chair” — copy-paste from one tab to another because there is no integration — that is a Priority 1 gap. Whatever the human bridges manually, the agent cannot cross at all.
• The how: Start by interviewing your SOC / D&R analysts and shadowing them during a real investigation. Review SIEM/EDR query logs to see which systems are consistently touched. Check SSO/IAM logs to see where they authenticate. Scan your internal wiki or shared drives to identify those “secret” cheat sheets or side-tools they rely on. If they are swivel-chairing (hi, 1990s SOC!), you will find the proof in their browser history or their documented SOPs.

Now run every item on that list through the five tests below.

Test 1: Connectivity & Accessibility (The “Can I Even Get There?” Test)

An AI agent needs a direct, programmatic path to the data. If a human has to “export a CSV”, “log into a separate portal”, or, worse, “Slack another human”, that data source is dead to the AI (agent UI scraping is doable, but sad and not scalable or reliable).

• Machine-readable documentation: Does the tool have a public (or well-documented internal) REST/gRPC API, or an MCP server? If the only way to learn the API is “emailing a support engineer,” you’ve already failed. (And no, MCP is not magic — it’s a protocol, not a personality transplant for your legacy tool.)
• Modern authentication: Does it support secure, programmatic auth (OAuth2, OIDC, scoped API keys, workload identity)? If it requires a “service account” with a static password and no MFA, congratulations, your AI enablement project just became a security liability. Remember vulnerability scanners that wanted an admin password for all systems back in the 2000s to do authenticated scanning?
• Network pathing: Can your AI orchestration layer — wherever the agent actually lives — reach the endpoint without weeks of firewall hair-pulling? This seems trivial for 2026, but I assure you it is anything but. And also: if this is too easy, perhaps you have a 1990s flat network?

Test 2: Performance & Throughput (The “Agentic Load” Stress Test)

This is where most “legacy” security tools break, and where you must test before an incident tests it for you.

• Concurrency limits: What is the maximum number of concurrent API requests the tool allows? If the answer is “one,” your agent is going to be very lonely. Keep in mind, agents like to swarm (OK, yours may not yet, but this is coming).
• Rate limiting: When exactly do the “429 Too Many Requests” errors start flying? Or, worse, the response is there, but the data is 1–99% incomplete? Will your threat intel provider cut you off the moment an agent starts enriching a batch of 23000 IPs because it, well, felt like it? Find the burst capacity of your stack now, on your terms. Don’t wait until you need it.
• Response latency: Measure time-to-first-byte on realistic queries. If a simple process tree query takes 45 seconds, your agent times out, retries, times out again… and your MTTR goes up… if you are lucky. Or, something else breaks, if you are not. “Multi-hour data queries” (hi again, the 1990s!) are an automatic fail here.

Test 3: Data Quality & Schema (The “Context Fidelity” Test)

Having an API is step one. Having useful data at the end of it is step two. AI agents are only as smart as the context they can read when they need it — GIGO is still law! BTW, the agentic spin on GIGO is of course being “confidently wrong.”

• Structured output: Does the API return JSON or YAML? If your legacy ticketing system returns a 2MB “stream of consciousness” text (well, text-ish) blob, your AI will burn tokens (and, thus, your money) just trying to find the root cause. Force structured entry at the source (yes, this is the case management revamp from Part 2, and yes, this is painful and not fun at all).
• Schema stability: Is the API versioned? If the vendor silently renames src_ip to source_address, your agent logic breaks instantly and quietly (OK, this is not fair, a smarter model will in fact figure this one out… but it will cost ya!). Quiet breakage in a SOC is the worst kind.
• Joinable fields: Does the telemetry include correlation keys (cloud_instance_id, user_sid, asset IDs) so the agent can pivot to the next tool without guessing? Agents that guess entity resolution are agents that hallucinate incidents…

Test 4: Functional Depth (The “Can It Actually Do Work?” Test)

An AI-ready API shouldn’t just be for reading data; eventually it is for taking action — with the human/agent handoff lines you drew in Part 2 firmly in place. Due to vulnerability apocalypse fears, a lot of vendors started to promise automatic remediation, and guess what? This means needing APIs to act on systems.

• Read/write balance: Can the API perform response actions — isolate a host, disable a user, update a rule? Read-only APIs give you an AI-powered observer, not an AI-augmented SOC of the future.
• Granular scoping: Can you give the agent least-privilege access? “Read all logs” but “isolate only these subnets”? If the tool’s permission model is “admin or nothing,” that’s a hard stop for autonomy.
• Server-side filtering: Does the API support filtering at the source (?status=active&severity=high)? If the agent must pull 10,000 records to find 5, you’re paying token tax on the vendor’s laziness. But hey, somebody is getting rich…

Test 5: The Auth & Agent Identity Layer

Agents need keys — and keys need governance. Free wisdom from the 2010s, I guess. The 1990s are finally over!

• The audit question: Do you have a centralized way to manage API credentials and identities for your agents — as workload identities with registration, ownership, rotation, and revocation? Let me guess … mmmm … the answer is ‘no’?
• The risk: “Shadow AI” starts the day a helpful analyst hands their personal API key to an LLM to “help out.” Your audit must define how agents authenticate, how permissions are scoped, and who owns each agent identity (yes, really). If you can’t answer “which agent did this and on whose behalf?”, you are not ready for an agentic SOC.

The “Agentic Readiness” Scorecard

For every primary tool, assign a score:

• Level 1 — The Dinosaur: No API. UI-only. (Status: replace, or accept it’s invisible to your AI. Or suffer and pay for scraping the UI “agentically”)
• Level 2 — The Relic: Basic API, poorly documented, slow, falls over under load. (Status: high risk)
• Level 3 — The Standard: Decent REST API and docs, but read-mostly, limited response capabilities. (Status: usable with additional tools?)
• Level 4 — The Modernist: Robust, fast, versioned APIs with real write capabilities and granular RBAC. (Status: AI-ready)
• Level 5 — The Agent-First: Native agentic support (MCP, high concurrency, agent-aware auth, feedback loops). (Status: the gold standard, and yes, these exist in 2026)

Where You Arrive: The Binary Map

When you finish, you shouldn’t have a “nice-to-have” list. You should have a binary map:

1. Machine-ready: API is fast, documented, structured, and scoped. Your agents can use it.
2. Legacy debt: No API, or a brittle one. These sources are invisible to your AI.

And here’s the uncomfortable conclusion: if a data source is invisible to your machine, it should probably not be part of your modern detection strategy. We are moving to a world where “if it isn’t via API, it didn’t happen.” By the way, those living in organizations with modern IT stacks are surprised this is even an issue worth discussing. But, I assure you, it is…

This audit is also, not coincidentally, foundational work for an engineering-led SOC and ASO: the same API-first plumbing that feeds your agents feeds your detection-as-code pipelines, your metrics (pillar #5!), and your humans too. Fix it once, win three times.

So: which of your “critical” tools is actually an API-less paperweight? Name and shame (or just vent) in the comments!

Related blogs and podcasts:

• “Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!” (Part 1)
• “Beyond ‘Is Your SOC AI Ready?’ Plan the Journey!” (Part 2)
• “A Brief Guide for Dealing with ‘Humanless SOC’ Idiots”
• EP249 Data First: What Really Makes Your SOC ‘AI Ready’?
• EP252 The Agentic SOC Reality: Governing AI Agents, Data Fidelity, and Measuring Success

So Is Your SOC AI-Ready? Part 3: API or Die Audit! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

(with key ideas from Augusto Barros)

In Part 1 of this series, we dumped a pile of uncomfortable questions on you and promised answers. The core thesis, if you recall: if you add AI agents into a legacy, swivel-chair SOC structure, you are essentially building a robotic horse pulling an 1850 buggy. Sure, it saves on hay. It probably costs more in tokens.

2003 SOC + AI = somewhat better 2003 SOC.

That’s it. That’s the ceiling.

So today we start answering the questions. And we start by attacking the most sacred cow of traditional security operations: the alert triage process.

Let’s Kill Triage. Seriously.

For a quarter of a century, the standard SOC pipeline has been carved in stone:

Detect → Triage → Investigate

Human L1 analysts sit in front of a flashing alert queue, spending 3–7 minutes per alert (and sometimes much more…) deciding whether something is a false positive or deserves escalation to somebody more senior (and more expensive…and just as human). We built this process for one reason and one reason only: humans do not scale (For the purist: OK, they do scale, but linearly with pay). Triage was a compromise born of “built-in” scarcity. We — obviously — never had enough human eyes to deeply investigate every signal hitting the SIEM, so we invented a cheap filtering step to ration the expensive investigation step.

Sometime in the 2010s, SOAR made triage easier, by first adding alert enrichment and then …. in many places, nothing more. In others, select alert types were triaged by the hard-coded playbooks.

Now, let’s do AI. It doesn’t get bored correlating IPs or summarizing logs at 3am. It doesn’t quit after 18 months to go do threat hunting somewhere else. Because machine scale allows comprehensive analysis of every signal, the triage step can just go and vanish.

The new pipeline collapses to:

Detect → Investigate.

Why spend minutes “skin-deep” triaging an alert to decide whether it deserves a look, when the machine can perform a full, deep investigation of 100% of your alerts? Gather the local context, pull the historical cases, map the artifacts, render a verdict with evidence — all before a human ever shows up.

For the impatient: the cost discussion is coming! Don’t freak out … just yet.

Wait — Can They Actually Do That Today?

Fair question, and here is where we owe you honesty rather than a slide.

Today’s “AI in SOC” ranges from “genuinely investigates” to “enriches beautifully then bullshits confidently.” The second one is an old SOAR chained to a language model aka the exact trap this blog warns about. If you cannot tell which one you bought, you probably bought the second one…

Our rough test for telling them apart, usable in a POV:

• Does it ask new questions, or only pre-decided ones? Enrichment runs a fixed lookup list. Investigation forms a hypothesis, queries, reads the result, and changes what it asks next. Watch the query sequence, not the summary.
• Does the conclusion move when the evidence moves? Feed it two near-identical alerts with one materially different fact. If the verdict does not change, you have a narrator.
• Does it ever return “inconclusive”? A system with no uncertainty output has no calibration. Run away.
• Does it show its work in a form a human can re-run? Queries, artifacts, timestamps — not just a paragraph asserting “no evidence of compromise.” OK, this is tricky, I admit.

Where does this leave the “kill triage” claim? Honestly: directionally right, unevenly available. For high-volume, well-bounded, evidence-rich alert classes — phishing, commodity EDR detections, identity anomalies — deep machine investigation of 100% is achievable now.

For multi-stage, low-signal, who-the-hell-knows-what-happened, context-heavy cases it is not, and anyone telling you otherwise is, ahem, exaggerating, to put it mildly. The pipeline collapse is real; the coverage is a rollout, not a switch.

Depth Gating: The New Triage Wears a Suit

So, if deep investigation is token-expensive — and it is, sorry! — then somebody, somewhere, is deciding how deep the machine goes on which alerts. We can call this decision A New Triage, while bending the truth a bit. It just moved from a human clicking a queue to a policy sitting in a config file, and pretending otherwise is how you end up with an unexamined control that quietly decides what you never look at. And, just as before, mistakes and decisions cost money.

So let’s examine it. Explicitly:

• Who owns the investigation depth policy? Not procurement. Not “whoever set up the tool.” This is a detection-engineering artifact with a named owner, version history, and a review cadence.
• Who owns the budget, and what happens when it runs out mid-month? If the honest answer is “all investigations get shallower,” you have just invented an availability attack against your own SOC. Define degradation behavior in advance: which alert classes keep full depth, what gets queued, what pages a human (do you still have said human handy?)
• What is systematically under-investigated? Every gating rule creates a shadow. Write the shadow down. What gets triaged out? Review it quarterly against your threat model, not against your token bill. Well, OK, against both, really, but mostly vs the threats.
• Are your thresholds guessable? If low-severity, off-hours, or particular-source alerts predictably get the cheap path, an adversary who learns that shapes activity to land there. Treat depth policy as security-sensitive configuration, not ops tuning.

Triage stops being a job and becomes a policy — and policies get attacked, drift, and rot. This is the broader theme of the whole series: humans move from doing the work to defining the rules for the work, which is harder, not easier, and needs the governance to match.

(And yes, “cost per investigation” becomes a real SOC metric — one that will fight with “detection coverage” in every budget meeting. More on the metrics carnage in a future part.)

So What Do the Humans Do?

Remember my favorite modern SOC question? “It’s 2030, you have a SOC, what do humans do?” If machines own frontline investigation for the vast majority of alerts, what happens to the people? Two dominant paradigms are emerging, and the answer for most organizations will be “both, in some mix”:

1. The Elite Threat Hunter Model. With the routine noise fully investigated by machines, humans are finally unchained from the queue. They pivot to hypothesis-driven hunting, deep-dive research, and the nuanced multi-stage attacker behaviors where AI (for now!) still struggle. Humans hunt; machines grind. Sorry, but “100% automated hunting” is not (today).

2. The Engineering-Driven SOC Model. This is our classic ASO mantra: humans build machines; machines do the work. Analysts evolve into detection and SOC engineers. Their day shifts from consuming alerts to building, tuning, testing, versioning and (yes) rolling back the AI logic and detection-as-code pipelines. Treat agents as engineering artifacts, not magic pets.

And the New L1 Is…

“OK, but classic L1 is dead. What do entry-level humans do?” OK, this is tricky! This is where a lot of “humanless SOC” enthusiasts embarrass themselves.

I think the new starter role is AI validation: sampling and reviewing AI-generated case files, validating the agent’s query logic against the data it actually had, hunting for hallucinated context and confidently wrong conclusions (got those?), and owning the “1% bucket” — the exceptions where the AI raises its digital hands and says “I don’t know, human, help me.” (Your AI SOC must have an explicit process for this bucket. If your vendor’s agent never says “I don’t know,” run.)

Now the two objections this role deserves, because “verify-and-validate is the new L1” is a slogan until you answer them.

Objection 1: where does the competence come from? Checking an agent’s homework requires knowing what good looks like — and L1s historically learned that by doing triage, badly, for a year. We removed the training ground and assumed the graduates.

So build the ground back deliberately:

• Structured re-investigation as training. New analysts independently work a small set of already-closed cases without seeing the agent’s verdict, then compare. This is deliberate practice, and it doubles as an evaluation signal on the agent.
• Curated case libraries as curriculum. The promoted-case archive is the best SOC textbook your org will ever have, sequenced from trivial to nasty. Use it as onboarding, not just as machine memory. You have AI, use it!
• Rotation into hunting and detection engineering on a schedule, not “when someone has time.” Validation-only career paths produce validators, not investigators.

Objection 2: automation bias is real and it will eat your review process. Humans reviewing plausible, well-written machine verdicts approve them, every time. You do that, I do that (hey, I just did this with this blog sentence to illustrate this very point). You can’t order people not to. Well, you can order, but they won’t do it. This is one of the best-documented findings in human-automation research, and hoping your team is special is not a thing.

Design against it:

• Blind review first. The reviewer forms a verdict before seeing the agent’s. Order matters more than effort here.
• Canary cases. Inject known-bad cases with deliberately wrong agent verdicts into the review queue at a low rate. Measure catch rate. This measures the reviewers, and it is the only honest read on whether your validation layer is real.
• Stratified, not random, sampling. Random sampling over a population that is 99% benign finds nothing. Oversample: agent-reported low confidence, unusual query paths, crown-jewel assets, first-time-seen behaviors, and anything closed suspiciously fast.
• Incentives on catches, not throughput. If reviewers are measured on cases reviewed per shift, you have built a rubber stamp with a salary. Measure disagreements raised and misses found.

What’s Next?

Killing triage and re-blueprinting the humans is necessary but not sufficient. If your SOC still reports “alerts closed per analyst per shift,” you are measuring a process that no longer exists.

Next up: failure modes, local context pain, how SOC metrics must change when volumes and closure rates stop mattering …

Related blogs:

• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• Beyond “Is Your SOC AI Ready?” Plan the Journey!
• WTH is Modern SOC, Part 1
• The Return of the Baby ASO: Why SOCs Still Suck?
• Beware: Clown-grade SOCs Still Abound
• EP264 Measuring Your (Agentic) SOC: Two Security Leaders Walk into a Podcast

Stop Building a 2003 SOC with AI: Triage Must Die (Part 2) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

One particular aspect of an agentic or AI-powered SOC (but NOT “humanless SOC”) has bothered me over the last few months: specifically, the people and process side of such a SOC. If you recall my blog posts (part 1, part 2 and this video) about AI SOC readiness, I hinted at certain elements of a traditional process stack and legacy personnel profiles (both technical and leadership) that make AI adoption inside SOC incredibly difficult.

So we (me and Augusto Barros @ Prophet Security) want to create a modernized people and process framework for a SOC powered by AI and intelligent agents. Otherwise, what I am observing is a lot of “robotic horse pulls a buggy” kind of operations — where everything is kept exactly the same as it was in 2003, but “AI SOC” tools are simply tacked on to perform some of the tasks.

I believe that people and process components must change far more dramatically, and such changes are a critical requirement for achieving “step change” SOC with AI capabilities. Simply adding AI tools and Ai agents to a 2003-style SOC will produce, at best, marginal results. Things would get better, but not better enough to counter the feared “bad guy with AI.”

The SOAR Analogy

The analogy I want to use here is SOAR adoption from 10+ years ago. Back then, organizations simply shifted a few processes — or even just specific tasks — to a machine, and then kept the rest of their operations exactly the same. Because of that, I observed a lot of SOAR tools being used strictly for alert enrichment or for dealing with one specific, isolated type of alert, like phishing. To follow this analogy to the present day, I now frequently see an “AI SOC” being utilized only for EDR alerts or only for phishing alerts (wow, what a coincidence!)

A First-Principles Approach

What I really want to build is a first-principles approach to the specific personnel, skills, processes, and practices required to run a true agentic SOC in the late 2020s.

Now, if you prefer incremental change, that is OK, I won’t judge. However, you must be aware that the same principles caused organizations to struggle with cloud adoption. People often hear that “lift and shift” is bad. Most consultants will tell you that “lift and shift” is fine as a first step, but you eventually need to modernize and take more steps. Unfortunately, many organizations never make that second step. The same risk applies to the AI SOC. 2003 SOC + AI = somewhat better 2003 SOC.

BTW, many artifacts of the modern, engineering-powered SOC — which we covered in our now-famous ASO (Autonomic Security Operations) paper back in 2021s — apply here as well. In fact, if you recall, one of our core principles was: Humans build machines; machines do the work.

In the context of an agentic SOC, that evolves into:

Today, humans build the machines with the help of other machines, and then the machines do the heavy lifting.

So, our questions so far:

• What do humans do in an agentic SOC?
• What do entry-level humans do?
• What SOC processes stay the same despite AI?
• What SOC processes can just go and vanish (triage)?
• What processes get handed to machines?
• Are there new processes for humans?
• What is the new human role for validation?
• How do we check AI quality without fully redoing the work?
• How SOC metrics must change due to AI and agents? (some ideas)
• What do humans and machines do jointly? What does it mean, practically?
• How to HITL in a SOC without breaking the humans or machines?
• What is the effective mechanism for the human-to-AI feedback loop so that corrections actually improve future SOC performance?
• Is “fully automated” detection engineering a realistic goal, or does the dependency on local, inconsistent environment context make it inherently a hybrid human-machine effort?
• What do humans do before SOC (TI) and after SOC (IR)?
• What is the first step to move from a legacy SOC to an agentic SOC?
• Can we run legacy and agentic SOC structures in parallel during transition, or does this duplication create operational friction?
• Is it easier to move from a modern non-AI SOC (aka “SOCless D&R”) to an AI SOC?

Looking Ahead

This blog post is just the first part of the series. My goal here is simply to collect the right questions we need to be asking, but I promise we will provide concrete answers in upcoming posts. This research is being undertaken together with my former colleague, Augusto Barros, now at Prophet Security

Related blogs:

• Beyond “Is Your SOC AI Ready?” Plan the Journey!
• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• WTH is Modern SOC, Part 1
• Baby ASO: A Minimal Viable Transformation for Your SOC
• Beware: Clown-grade SOCs Still Abound
• EP264 Measuring Your (Agentic) SOC: Two Security Leaders Walk into a Podcast
• New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5)
• The Gravity of Process: Why New Tech Never Fixes Broken Process and Can AI Change It?

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

You read the “AI-ready SOC pillars” blog, but you still see a lot of this:

How do we do better?

Let’s go through all 5 pillars aka readiness dimensions and see what we can actually do to make your SOC AI-ready.

#1 SOC Data Foundations

As I said before, this one is my absolute favorite and is at the center of most “AI in SOC” (as you recall, I want AI in my SOC, but I dislike the “AI SOC” concept) successes (if done well) and failures (if not done at all).

Reminder: pillar #1 is “security context and data are available and can be queried by machines (API, Model Context Protocol (MCP), etc) in a scalable and reliable manner.” Put simply, for the AI to work for you, it needs your data. As our friends say here, “Context engineering focuses on what information the AI has available. […] For security operations, this distinction is critical. Get the context wrong, and even the most sophisticated model will arrive at inaccurate conclusions.”

Readiness check: Security context and data are available and can be queried by machines in a scalable and reliable manner. This is very easy to check, yet not easy to achieve for many types of data.

For example, “give AI access to past incidents” is very easy in theory (“ah, just give it old tickets”) yet often very hard in reality (“what tickets?” “aren’t some too sensitive?”, “wait…this ticket didn’t record what happened afterwards and it totally changed the outcome”, “well, these tickets are in another system”, etc, etc)

Steps to get ready:

• Conduct an “API or Die” data access audit to inventory critical data sources (telemetry and context) and stress-test their APIs (or other access methods) under load to ensure they can handle frequent queries from an AI agent. This is important enough to be a Part 3 blog after this one…
• Establish or refine unified, intentional data pipelines for the data you need. This may be your SIEM, this may be a separate security pipeline tool, this may be magick for all I care … but it needs to exist. I met people who use AI to parse human analyst screen videos to understand how humans access legacy data sources, and this is very cool, but perhaps not what you want in prod.
• Revamp case management to force structured data entry (e.g., categorized root causes, tagged MITRE ATT&CK techniques) instead of relying on garbled unstructured text descriptions, which provides clean training data for future AI learning. And, yes, if you have to ask: modern gen AI can understand your garbled stream of consciousness ticket description…. but what it makes of it, you will never know…

Where you arrive: your AI component, AI-powered tool or AI agent can get the data it needs nearly every time. The cases where it cannot become visible, and obvious immediately.

#2 SOC Process Framework and Maturity

Reminder: pillar #2 is “Common SOC workflows do NOT rely on human-to-human communication are essential for AI success.” As somebody called it, you need “machine-intelligible processes.”

Readiness check: SOC workflows are defined as machine-intelligible processes that can be queried programmatically, and explicit, structured handoff criteria are established for all Human-in-the-Loop (HITL) processes, clearly delineating what is handled by the agent versus the person. Examples for handoff to human may include high decision uncertainty, lack of context to make a call (see pillar #1), extra-sensitive systems, etc.

Common investigation and response workflows do not rely on ad-hoc, human-to-human communication or “tribal knowledge,” such knowledge is discovered and brought to surface.

Steps to get ready:

• Codify the “Tribal Knowledge” into APIs: Stop burying your detection logic in dusty PDFs or inside the heads of your senior analysts. You must document workflows in a structured, machine-readable format that an AI can actually query. If your context — like CMDB or asset inventory — isn’t accessible via API (BTW MCP is not magic!), your AI is essentially flying blind.
• Draw a Hard Line Between Agent and Human: Don’t let the AI “guess” its level of authority. Explicitly delegate the high-volume drudgery (log summarization, initial enrichment, IP correlation) to the agent, while keeping high-stakes “kill switches” (like shutting down production servers) firmly in human hands.
• Implement a “Grading” System for Continuous Learning: AI shouldn’t just execute tasks; it needs to go to school. Establish a feedback loop where humans actively “grade” the AI’s triage logic based on historical resolution data. This transforms the system from a static script into a living “recipe” that refines itself over time.
• Target Processes for AI-Driven Automation: Stop trying to “AI all the things.” Identify specific investigation workflows that are candidates for automation and use your historical alert triage data as a training ground to ensure the agent actually learns what “good” looks like.

Where you arrive: The “tribal knowledge” that previously drove your SOC is recorded for machine-readable workflows. Explicit, structured handoff points are established for all Human-in-the-Loop processes, and the system uses human grading to continuously refine its logic and improve its ‘recipe’ over time. This does not mean that everything is rigid; “Visio diagram or death” SOC should stay in the 1990s. Recorded and explicit beats rigid and unchanging.

#3 SOC Human Element and Skills

Reminder: pillar #3 is “Cultivating a culture of augmentation, redefining analyst roles, providing training for human-AI collaboration, and embracing a leadership mindset that accepts probabilistic outcomes.” You say “fluffy management crap”? Well, I say “ignore this and your SOC is dead.”

Readiness check: Leaders have secured formal CISO sign-off on a quantified “AI Error Budget,” defining an acceptable, measured, probabilistic error rate for autonomously closed alerts (that is definitely not zero, BTW). The team is evolving to actively review, grade, and edit AI-generated logic and detection output.

Steps to get ready:

• Implement the “AI Error Budget”: Stop pretending AI will be 100% accurate. You must secure formal CISO sign-off on a quantified “AI Error Budget” — a predefined threshold for acceptable mistakes. If an agent automates 1,000 hours of labor but has a 5% error rate, the leadership needs to acknowledge that trade-off upfront. It’s better to define “allowable failure” now than to explain a hallucination during an incident post-mortem.
• Pivot from “Robot Work” to Agent Shepherding: The traditional L1/L2 analyst role is effectively dead; long live the “Agent Supervisor.” Instead of manually sifting through logs — work that is essentially “robot work” anyway — your team must be trained to review, grade, and edit AI-generated logic. They are no longer just consumers of alerts; they are the “Editors-in-Chief” of the SOC’s intelligence.
• Rebuild the SOC Org Chart and RACI: Adding AI isn’t a “plug and play” software update; it’s an organizational redesign. You need to redefine roles: Detection Engineers become AI Logic Editors, and analysts become Supervisors. Most importantly, your RACI must clearly answer the uncomfortable question: If the AI misses a breach, is the accountability with the person who trained the model or the person who supervised the output?

Where you arrive: well, you arrive at a practical realization that you have “AI in SOC” (and not AI SOC). The tools augment people (and in some cases, do the work end to end too). No pro- (“AI SOC means all humans can go home”) or contra-AI (“it makes mistakes and this means we cannot use it”) crazies nearby.

#4 Modern SOC Technology Stack

Reminder: pillar #4 is “Modern SOC Technology Stack.” If your tools lack APIs, take them and go back to the 1990s from whence you came! Destroy your time machine when you arrive, don’t come back to 2026!

Readiness check: The security stack is modern, fast (“no multi-hour data queries”) interoperable and supports new AI capabilities to integrate seamlessly, tools can communicate without a human acting as a manual bridge and can handle agentic AI request volumes.

Steps to get ready:

• Mandate “Detection-as-Code” (DaC): This is no longer optional. To make your stack machine-readable, you must implement version control (Git), CI/CD pipelines, and automated testing for all detections. If your detection logic isn’t codified, your AI agent has nothing to interact with except a brittle GUI — and that is a recipe for failure.
• Find Your “Interoperability Ceiling” via Stress Testing: Before you go live, simulate reality. Have an agent attempt to enrich 50 alerts simultaneously to see where the pipes burst. Does your SOAR tool hit a rate limit? Does your threat intel provider cut you off? You need to find the breaking point of your tech stack’s interoperability before an actual incident does it for you.
• Decouple “Native” from “Custom” Agents: Don’t reinvent the wheel, but don’t expect a vendor’s “native” agent to understand your weird, proprietary legacy systems. Define a clear strategy: use native agents for standard tool-specific tasks, and reserve your engineering resources for custom agents designed to navigate your unique compliance requirements and internal “secret sauce.”

Where you arrive: this sounds like a perfect quote from Captain Obvious but you arrive at the SOC powered by tools that work with automation, and not with “human bridge” or “swivel chair.”

#5 SOC Metrics and Feedback Loop

Reminder: pillar #5 is “You are ready for AI if you can, after adding AI, answer the “what got better?” question. You need metrics and a feedback loop to get better.”

Readiness check: Hard baseline metrics (MTTR, MTTD, false positive rates) are established before AI deployment, and the team has a way to quantify the value and improvements resulting from AI. When things get better, you will know it.

Steps to get ready:

• Establish the “Before” Baseline and Fix the Data Slop: You cannot claim victory if you don’t know where the goalposts were to begin with. Measure your current MTTR and MTTD rigorously before the first agent is deployed. Simultaneously, force your analysts to stop treating case notes like a private diary. Standardize on structured data entry — categorized root causes and MITRE tags — so the machine has “clean fuel” to learn from rather than a collection of “fixed it” or “closed” comments.
• Build an “AI Gym” Using Your “Golden Set”: Do not throw your agents into the deep end of live production traffic on day one. Curate a “Golden Set” of your 50–100 most exemplary past incidents — the ones with flawless notes, clean data, and correct conclusions. This serves as your benchmark; if the AI can’t solve these “solved” problems correctly, it has no business touching your live environment.
• Adopt Agent-Specific KPIs for Performance Management: Traditional SOC metrics like “number of alerts closed” are insufficient for an AI-augmented team. You need to track Agent Accuracy Rate, Agent Time Savings, and Agent Uptime as religiously as you track patch latency. If your agent is hallucinating 5% of its summaries, that needs to be a visible red flag on your dashboard, not a surprise you discover during an incident post-mortem.
• Close the Loop with Continuous Tuning: Ensure triage results aren’t just filed away to die in an archive. Establish a feedback loop where the results of both human and AI investigations are automatically routed back to tune the underlying detection rules. This transforms your SOC from a static “filter” into a learning system that evolves with every alert.

Where you arrive: you have a fact-based visual that shows your SOC becoming better in ways important to your mission after you add AI (in fact, you SOC will get better even before AI but after you do the prep-work from this document)

As a result, we can hopefully get to this instead:

The path to an AI-ready SOC isn’t paved with new tools; it’s paved with better data, cleaner processes, and a fundamental shift in how we think about human-machine collaboration. If you ignore these pillars, your AI journey will be a series of expensive lessons in why “magic” isn’t a strategy.

But if you get these right? You move from a SOC that is constantly drowning in alerts to a SOC that operates truly 10X effectiveness.

P.S. Anton, you said “10X”, so how does this relate to ASO and “engineering-led” D&R? I am glad you asked. The five pillars we outlined are not just steps for AI; they are the also steps on the road to ASO (see original 2021 paper which is still “the future” for many).

ASO is the vision for a 10X transformation of the SOC, driven by an adaptive, agile, and highly automated approach to threats. The focus on codified, machine-intelligible workflows, a modern stack supporting Detection-as-Code, and reskilling analysts as “Agent Supervisors” directly supports the core of engineering-led D&R. So focusing on these five readiness dimensions, you move from a traditional operations room (lots of “O” for operations) to a scalable, engineering-centric D&R function (where “E” for engineering dominates).

So, which pillar is your SOC’s current ‘weakest link’? Let’s discuss in the comments and on socials!

Related blogs and podcasts:

• “Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!” (Part 1 to this blog)
• “Modern SecOps: What an AI-ready SOC actually means with Anton Chuvakin” video
• “A Brief Guide for Dealing with ‘Humanless SOC’ Idiots” (the classic!)
• “SOC is Not Dead Yet It May Be Reborn As Security Operations Center of Excellence” (oddly related!)
• EP236 Accelerated SIEM Journey: A SOC Leader’s Playbook for Modernization and AI
• EP242 The AI SOC: Is This The Automation We’ve Been Waiting For?
• EP252 The Agentic SOC Reality: Governing AI Agents, Data Fidelity, and Measuring Success
• EP249 Data First: What Really Makes Your SOC ‘AI Ready’?

Beyond “Is Your SOC AI Ready?” Plan the Journey! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of security operations, there is a growing fascination with the concept of a “decoupled SIEM,” where detection, reporting, workflows, data storage, parsing (sometimes) and collection are separated into distinct components, some sold by different vendors.

Closely related to this is the idea of federated log search, which allows data to be queried on demand from various locations without first centralizing it in a single system.

When you combine these two trends with the emergence of AI agents and the “AI SOC,” a compelling vision appears — one where many of security operations’ biggest troubles are solved in an elegant and highly automated fashion. Magic!

Magical decoupled SIEM + magical federated log search + magical AI agents

=

90X the magic

(Is my math mathing? Cheap + good + fast + AI powered … pick any …ehh… I digress!)

However, a look at the market reveals a conflicting — dare I saw opposite — trend. Many organizations are actively choosing the very opposite approach: tightly integrated platforms where search, dashboards, detection, data collection, and AI capabilities are bundled together — and additional things are added on top (such as EDR).

Let’s call this “EDR-ized SIEM” or “SIEM with XDR-inspired elements” (for those who think they can define XDR) or “supercoupled SIEM” (but this last one is a bit of a mouthful..)

While some suggest this is a split between large enterprises choosing disaggregated stacks and smaller companies opting for closer integration, this doesn’t fully capture the success rates of these different models (one is successful and another is, well, also successful but at a very small number of extra-large, engineering-heavy organizations)

If one were to take a contrarian view (as I will in this post!), it might be that the decoupled and federated approach, with or without AI agents, is destined to be a secondary, auxiliary path in the evolution of SIEM.

Log Centralization: The End Is Nigh?

This isn’t a nostalgic vote for outdated, 1990s-era ideas (“gimme a 1U SIEM appliance with MySQL embedded!”), but rather a realistic assessment based on past lessons, such as the niche fascination with security data science.

Many years ago (2012), while at Gartner, I wrote a notorious “Big Analytics for Security: A Harbinger or An Outlier?” (archive, repost), and it is now very clear that late 2000s-early 2010s security data science “successes” remained a tiny, micro minority examples. A trend can be emergent, growing tenfold from a tiny base of 0.01% of companies, yet still only reach 0.1% of the market — making it an outlier, not a harbinger of the mainstream future.

Ultimately, the evidence suggests that a decoupled, federated architecture will not form the basis of the typical SIEM of 2027. Instead, the centralized platform model, enhanced and supercharged by AI, will reign supreme (and, yes, it will also include some auxiliary decentralized elements as needed, think of it as “90% centralized / 10% federated SIEM” — a better model for the future).

My conclusion:

1. SIEM has a future! If you hate SIEM so much that you … rename it, then, well, SIEM still has a future (hi XDR!)
2. Decoupled SIEM and federated log search belong in the future of SIEM.
3. However, decoupled SIEM and federated log search (In My NSHO) are not THE future of SIEM.
4. I think this because both are just too damn messy for many clients to make them work well. They also fail many compliance tests (well, the federated part, not the decoupled)
5. AI and AI agents are a very big part of the SIEM future. However, AI agents do not make decoupled SIEM and federated log search less messy enough (“I didn’t save any logs from X, hey AI agent .. get me logs from X” does not work IRL)

Put another way:

The Romantic Ideal: The theory is that scalable data platforms and specialized threat analysis are dramatically different, so they should be handled by specialists, and modern APIs should make connecting them “easy.” Magic!

The Real Reality: A natively designed, single-vendor, integrated SIEM is inherently simpler and easier to manage and support than a multi-component stack you have to assemble “at home.” It is also faster! AI integrated inside it just works better. With decoupling, also lose the benefit of having a “single face to scream at” when things break. Reality!

Here is my “decoupled SIEM reading list” (all fun reads, obviously not all I agree with):

• Security is about data: how different approaches are fighting for security data and what the cybersecurity data stack of the future is shaping up to look like
• Future of security operations isn’t interfaces like SIEM, it’s access to data
• Prepare for SIEM Evolution
• Building the SOC of the Future (video)
• Security Data Lakes: A Reality Check
• The SIEM Stack Is Breaking: What Comes After Splunk and Legacy Security Infrastructure
• Next generation of SIEM will be a focused security layer running on top of a commodity data layer
• A Year-End Reflection on the SIEM and SecOps Landscape
• Changes in SIEM Market
• Navigating the data current: Exploring Cribl.Cloud analytics and customer insights

Please argue on socials (X or LinkedIn) or in comments!

Related posts:

• Decoupled SIEM: Brilliant or Stupid?
• Log Centralization: The End Is Nigh?
• Debating SIEM in 2023, Part 1
• Debating SIEM in 2023, Part 2
• Why Your Security Data Lake Project Will … Well, Actually …
• EP190 Unraveling the Security Data Fabric: Need, Benefits, and Futures
• EP197 SIEM (Decoupled or Not), and Security Data Lakes: A Google SecOps Perspective
• Detection as Code? No, Detection as COOKING!
• Back to Cooking: Detection Engineer vs Detection Consumer, Again?

Decoupled SIEM: Where I Think We Are Now? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025

I will be really, really honest with you — I have been totally “writer-blocked” and so I decided to release it anyway today … given the date.

So abit of history first. So, my “SOC visibility triad” was released on August 4, 2015 as a Gartner blog (it then appeared in quite a few papers, and kinda became a thing). It stated that to have good SOC visibility you need to monitor logs (L), endpoint (E) sources and network (N) sources. So, L+E+N was the original triad of 2015. Note that this covers monitoring mechanisms, not domains of security (more on this later; this matters!)

5 years later, in 2020, I revisited the triad, and after some agonizing thinking (shown at the above link), I kept it a triad. Not a quad, not a pentagram, not a freakin’ hex.

So, here in 2025, I am going to agonize much more .. and then make a call (hint: blog title has a spoiler!)

How do we change my triad?

First, should we …

… Cut Off a Leg?

Let’s look at whether the three original pillars should still be here in 2025. We are, of course, talking about endpoint visibility, network visibility and logs.

My 2020 analysis concluded that the triad is still very relevant, but potential for a fourth pillar is emerging. Before we commit to this possibly being a SOC visibility quad — that is, dangerously close to a quadrant — let’s check if any of the original pillars need to be removed.

Many organizations have evolved quite a bit since 2015 (duh!). At the same time, there are many organizations where IT processes seemingly have not evolved all that much since the 1990s (oops!).

First, I would venture a guess that, given that EDR business is booming, the endpoint visibility is still key to most security operations teams. A recent debate of Sysmon versus EDR is a reflection of that. Admittedly, EDR-centric SOCs peaked perhaps in 2021, and XDR fortunately died since that time, but endpoints still matter.

Similarly, while the importance of sniffing the traffic has been slowly decreasing due to encryption and bandwidth growth, cloud native environments and more distributed work, network monitoring (now officially called NDR) is still quite relevant at many companies. You may say that “tcpdump was created in 1988” and that “1980s are so over”, but people still sniff. Packets, that is.

The third pillar of the original triad — logs — needs no defense. Log analysis is very much a booming business and the arrival of modern IT infrastructure and practices, cloud DevOps and others have only bolstered the importance of logs (and of course their volume). A small nit appears here: are eBPF traces logs? Let’s defer this question, we don’t need this answer to reassert the dominance of logs for detection and response.

At this point, I consider the original three legs of a triad to be well defended. They are still relevant, even though it is very clear that for true cloud native environments, the role of E (endpoint) and N (network) has decreased in relative terms, while importance of logs increased (logs became more load bearing? Yes!)

Second, should we …

Add a Leg?

Now for the additions I’ve had a few recent discussions with people about this, and I’m happy to go through a few candidates.

Add Cloud Visibility?

First, let’s tackle cloud. There are some arguments that cloud represents a new visibility pillar. The arguments in favor include the fact that cloud environments are different and that cloud visibility is critical. However, to me, a strong counterpoint is that cloud visibility In many cases, is provided by endpoint, network, and logs, as well as a few things. We will touch these “few things” in a moment.

YES?

• Cloud native environments are different, they suppress E and N
• Cloud visibility is crucial today
• Addresses unique cloud challenges
• Cloud context is different, even if E and N pillars are used for visibility
• CDR is a thing some say

NO?

• Cloud INCLUDES logs (lots, some say 3X in volume), and also E and N
• Too much overlap with other pillars (such as E and N)
• Cloud is a domain, not a mechanism for visibility.
• CDR is not a thing, perhaps

Verdict:

• NO, not a new pillar, part of triad already (via all other pillars)

Add Identity Visibility?

The second candidate to be added is, of course, identity. Here we have a much stronger case that identity needs to be added as a pillar. So perhaps we would have an endpoint, network, logs and identity as our model. Let’s review some pros and cons for identity as a visibility pillar.

YES?

• Identity is key in the cloud; we observe a lot of things via IDP … logs (wait.. we already have a pillar called “logs”)
• By making identity a dedicated pillar, organizations can ensure that it receives the attention
• ITDR is a thing

NO?

• But identity visibility is in the logs … we already have logs!
• Too much overlap with other pillars (such as logs and E as well)
• Identity is hugely useful and critical, but as context. This post is about activity streams
• ITDR is kinda a thing, but it is also not a thing

Verdict:

• Sorry, still a NO, but a weak NO. Identity is critical as context for logs, endpoint data and network telemetry, but it is not (on its own) a visibility mechanism.

Still, I don’t want to say that identity is merely just about logs, because “baby … bathwater.” Some of the emerging ITDR solutions are not simply relying on logs. I don’t think that identity is necessarily a new pillar, but there are strong arguments that perhaps it should be…

What do you think — should identity be a new visibility pillar?

Add Application visibility?

Hold on here, Anton, we need more data!

Here:

and

Now let’s tackle the final candidate, the one I considered in 2020 to be the fourth leg of a three legged stool. There is, of course, application visibility, powered by increased popularity of observability data, eBPF, etc. Application visibility is not really covered by endpoint orgs and definitely not by EDR observation. Similarly, application visibility is very hard to deduce from network traffic data.

YES?

• Application visibility is not covered by E and N well enough
• SaaS, cloud applications and — YES! — AI agents require deep application visibility.
• This enables deeper insights of the app guts, as well as business logic

NO?

• Is it just logs? Is it, though?
• Do organizations have to do application visibility (via ADR or whatever?) Is this a MUST-HAVE … but for 2030?
• Are many really ready for it in their SOCs today?

Verdict:

• YES! I think to have a good 2025 SOC you must have the 4th pillar of application visibility.
• And, yes, many are not ready for it yet, but this is coming…

So, we have a winner. Anton’s SOC visibility QUAD of 2025

1. Logs
2. Endpoint
3. Network
4. Application

Are you ready? … Ready or not, HERE WE GOOOO!

Related blogs:

• WhatDR or What Detection Domain Needs Its Own Tools?
• Revisiting the SOC Triad 2020
• Baby ASO: A Minimal Viable Transformation for Your SOC

SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.