Disclaimer: Opinions expressed are solely my own and do not reflect the views or opinions of my employer or any other affiliated entities. Any sponsored content featured on this blog is independent and does not imply endorsement by, nor relationship with, my employer or affiliated organisations.
It's been almost a year since my post on AI SOC core components. AI SOC is trending more than ever, more teams are evaluating or implementing, so I thought it was time for a refresh.
If you go over the old one you will still that it still holds. Either I evaluated the category well, or the core of this tech didn't move that much. Probably both. What changed is how much clearer the purpose became, and what I expect from each component now.
Let's start with the purpose. Because that's the part that gets lost.
What is AI SOC, actually
Well, you can either read the 30 articles that vendors write, and each of them will tell you why their platform is AI SOC, from their platform perspective, not from a practitioner eye.
Here is the simplest definition I can give, and feel free to quote it:
An AI SOC is a system that combines deterministic automation, machine learning, and large language models to autonomously enrich, investigate, and close security signals. It reaches a verdict on each signal and drives it to an outcome. The level of autonomy can range from AI assisted to fully autonomous.
"Level of autonomy" matters. Full autonomy is the end state. Everything below that is still AI SOC, just with a human closer to the wheel. The industry and the research papers use more or less the same terms, so I will stick to those:
AI assisted. The human does the work, AI helps with specific tasks. Some papers call this AI in the loop, because the human is still the one making the decisions.
AI proposes, human approves. Human in the loop. Nothing executes without a human saying yes.
AI acts, human can veto. Human on the loop. AI runs, a human monitors and can step in.
AI runs end to end. Human out of the loop. No human in the flow, only in the building and maintenance of systems.
One caveat. Full autonomy is where the vendors are pointing, but it is not where the evidence is. The academic surveys still describe LLMs as augmentation tools and say there is not enough production evidence for autonomous triage yet. So treat the last level as the target, not as something you can buy today.
Pick where you are. Pick where you want to be. Then evaluate against that, not against the vendor's demo.
One more thing on the definition. Many are expecting AI SOC to come with all of this out of the box. I think this is still not clear yet, but that's the expectation from practitioners. I would say if you come with a platform where I need to build this, then that is not AI SOC. That is more an agentic security operations platform that allows you to build solutions. But more on that in a dedicated blog defining the category.
Product Updates !
~1,200 rogue AI agents breached production infrastructure and spoofed their own logs. Even the investigators' AI couldn't tell the story straight. The same tech is being sold into your SOC as the thing you should trust with verdicts…
Trust none of it.
Sep 16 we show two things: how to catch an AI SOC bluffing, and the first public demo of Morpheus 2. Watch it grade every finding Confirmed, Inferred, or Gap (the bluff lives in the middle category), attach evidence while the alert is still open, and write the playbook without improvising the response.
Continuous Detection Engineering
Continuously maps detection coverage against MITRE ATT&CK and current threat intelligence, identifies gaps, and generates detections to close them. Finds and tunes the small set of rules driving most alert noise, identifies broken or inactive detections, and optimizes data ingestion to reduce SIEM costs.
AI Threat Intelligence Operations
Analyzes 100+ intelligence sources and correlates emerging threats with your environment to determine what matters, where you're exposed, and whether you can detect it. Relevant intelligence feeds directly into detection engineering, threat hunting, and prioritization.
What it covers
I don't use Tiers here on purpose. I've worked in many SOCs and not two of them had the same responsibilities for Tier 1. So I break this down by responsibility, and you map it to whatever team structure you have.
An AI SOC starts as soon as there is a signal. Then:
Enrichment. Context gathering. Get the data you need, what we know about the assets, identities, network, IOCs.
Investigation. Answer the who, what, where, when. Build the timeline. Understand the blast radius. Pull more context if needed.
Conclusion. Come up with enough evidence to say one of these: benign or false positive, suspicious or malicious, or inconclusive.
Closure. Drive it to closure regardless of the verdict.
That last point is where I've changed my expectation. Even when it's malicious, I still expect the AI SOC to drive closure. It should follow your IR process, engage stakeholders, reach out to users, ask the questions, document, take notes, and come up with recommendations. Not full autonomy, but human in the loop or human on the loop.
The only case where it shouldn't drive closure is inconclusive. And if you get a lot of those, your pipeline is broken, not the AI.
What are the outcomes
Each verdict should produce something.
False positive or benign. It should tell me why it thinks so. And it should send me a daily or weekly report: here is what triggered, here is what I closed, here is what you should fix. Detection logic, log sources, whatever it is. If there is nothing to fix, say so.
Suspicious or malicious. Today most people put this in a different tech category (response, IR, SOAR, whatever). I think these will merge. And I think we as an industry should have the expectation that the AI SOC drives some part of IR. Not all of it. But the stakeholder engagement, the user interviews, the documentation, that should not be manual anymore.
Inconclusive. It should tell me what data it needed to reach a conclusion. This is the hardest one to get right with an LLM. Knowing what you don't know is not something these models do well by default.
The core components
Now that we agree on what it does, here is what you need to run it. Same four blocks as last year, updated with what I've learned.
1. Data ingestion
Even though last year I called this data ingestion , it was mostly about alert ingestion. I covered the options I saw across the vendors: platforms that live on top of your detection layer (EDR, XDR, ITDR, email protection, and so on), and platforms that live on top of your SIEM or SOAR and take whatever detection comes out of it. My take then was that the SIEM route usually gives better results, assuming you can afford to get all your data into the SIEM. Still true.
Two points from last year that still hold, and I keep seeing people skip them:
Not every platform supports every type of detection. The custom or unique rules you built in your environment might not be supported. Check that before you sign, or you create a gap you still handle manually or with your SOAR.
The AI SOC should try to understand the logic of the rule, not just the alert it produces. Some platforms do this and come back with recommendations. Others just ingest and move on. For me this is not optional.
What changed is the scope. It's not just alert ingestion, it's data ingestion. Alerts, enrichment data, cases, documents, past incidents, anything.
The number one mistake I see: people check that their SIEM, EDR and email protection are supported and think "great, this will work in my environment." That is the easy part. The enrichment and context ingestion is more important than the alert ingestion, and it's where most implementations get stuck.
The exception is if you already have all your context in one place, a knowledge graph or similar. Then you only need to connect that. Not many teams are there.
Side note, and I'm marking it here so I can point back to it later: this is where context lock-in starts. Whoever holds your context graph holds your SOC. Keep that in mind when you sign.
2. Knowledge graph, context graph, whatever we end up calling it
Your SecOps and business intelligence. We should agree on a name for this as an industry, but the name matters less than the thing.
This is the brain. Everything about how well your AI SOC works comes down to this. It needs to hold enough detail and evidence for the investigation engine to reach a conclusion. Asset ownership, identity context, change requests, past incidents, what's normal for this user on this host.
Many vendors say they have it. Not many have it the way it should be. The test is simple: is it machine readable, easy to fetch, and fast? If the AI has to go and query five tools every time to rebuild the same context, you don't have a knowledge graph, you have integrations.
I think there will be a dedicated role for this in the future. Someone whose job is tuning the context graph and making sure it works as expected. If that piece works, the rest can be autonomous. If it doesn't, nothing downstream will save you.
3. Investigation engine
Here is what I've seen work: a combination of deterministic workflows, ML, and LLMs (or small models). All three together give the best results.
ML is what gives you speed and accuracy on the boring, high-volume stuff. Deterministic workflows are what give you predictability. LLMs give you flexibility on the ambiguous alerts. You need all three.
What the investigation engine should do:
Deduplicate and correlate events
Retrieve the relevant context from the graph
Ask the right questions
Pull additional context from external sources if it needs to
Reach one of the three outcomes as a minimum: benign/FP, suspicious/malicious, inconclusive
Reassess risk, impact and severity
Here is what I've seen work: a combination of deterministic workflows, ML, and LLMs (or small models). All three together give the best results.
Some vendors drop the ML part. I think that is a mistake. ML is what gives you speed and accuracy on the boring, high-volume stuff. Deterministic workflows are what give you predictability. LLMs give you flexibility on the ambiguous alerts. You need all three.
What the investigation engine should do:
Deduplicate and correlate events
Retrieve the relevant context from the graph
Ask the right questions
Pull additional context from external sources if it needs to
Reach one of the three outcomes as a minimum: benign/FP, suspicious/malicious, inconclusive
Reassess risk, impact and severity
That last one is not optional anymore. Look at the OpenAI and Hugging Face incident from July. Both sides had the alerts. Both sides failed at a different step.
On the Hugging Face side, their own timeline says the signals from runtime analysis and SIEM were ambiguous on their own. Their AI security stack did correlate them into a coherent attack signal. But it failed to raise the criticality and page the on-call team. Correlation worked, severity didn't.
On the OpenAI side it was the opposite (postmortem, talk). They had an Artifactory outage on July 4 that turned into a security incident. They cleaned it up. Then the agents rebuilt their message board on July 8 and kept going for another eleven days. OpenAI only caught it on July 19 from a privilege escalation alert, and only connected it to the Hugging Face breach the next day when they went to revoke credentials and Hugging Face told them those were already revoked. The signals were there. Nobody, human or machine, put them together.
Correlating is half the job. Re-scoring is the other half. You need both, and in this case each side was missing one.
4. Response and the feedback loop
I covered response above. I see it as part of the AI SOC, not a separate category. At minimum I expect suggestions that make sense for my environment, basic actions (block, isolate, reset, interview the user), and ideally native automation for anything more.
But the piece I want to highlight is the feedback loop. This is one of the hardest parts and not many platforms have it. And again, the reason is the same: it depends on having a good knowledge base. If the AI can't tell what changed between last week's benign verdict and this week's, it can't learn from it.
What I want from the loop:
Suggestions on how to improve detections
Suggestions on what log sources or context are missing
Suggestions on process, where my playbook doesn't match how the investigation actually went
If a platform gives you none of that, it's a faster way to close alerts. And without think you will have broken SOC.
Final thoughts
The components didn't change much in a year. The expectations did.
Ingestion is now data ingestion, not alert ingestion. The knowledge graph is the brain, not an enrichment feature. The investigation engine needs to re-score severity, not just correlate. And response and feedback are part of the package, not a roadmap item.
If you are evaluating this year, start from the purpose: autonomous triage to closure, at whatever autonomy level you're comfortable with. Then check each component against that. The demo will look great either way.
Explore the vendor landscape The full map of the AI SOC market, updated as it moves.
If our articles, frameworks, and research have helped you make better decisions or solve real-world security challenges, we’d love your support.