And yes, don’t jump on me for the vendors in the visual. When I say SIEM, I include both the more traditional ones and the SIEM alternatives, next-gen, decoupled, integrated SecOps, whatever we decide to call them this week.

There is also a really cool blog from the Elastic team, a proper deep dive into how they run this internally, with some great insights. One that stood out was how much they improved agent accuracy, not by changing the model, but by giving the agent better context.

That part matters a lot.
Overall, don’t use agents for everything. Go deterministic where you can and where it makes sense. Agents are useful, but they are not some magical replacement for every workflow just because we discovered the word “agentic.”
They also touch on why dumping walls of AI-generated text in front of analysts is not particularly useful. But that is a topic for another Friday SIEM post, because the UX disaster we are creating around AI in SecOps deserves its own rant.

Overall, I think we will see most, if not all, SIEM vendors adding some form of Agent Studio.

What surprised me is that not many added this capability through acquisition. A lot of them seem to be building it in-house. I still suspect we will see at least one acquisition in this space, maybe even this year.

And just to separate two things that are getting mixed together a lot.

When I say AI SOC, I usually mean the pre-built stuff. Investigation agents, triage agents, response agents, all ready to go.

When I say Agent Studio, I mean the build-your-own part. You get templates, tools, connectors and some building blocks, but you can create or customize the agents yourself.

So yes, SIEM added SOAR, then AI SOC, and now Agent Studios as well.

Have a siemless weekend ahead!

Read the Linkedin Post and comments

I think more people are finally realizing how important detection engineering is. Bad detections create a ton of pain downstream. But if we go even further left, the data pipeline matters just as much. Garbage in, garbage out still applies, even if the garbage is now being investigated by an AI agent with expensive frontier model .

If I had to put the SecOps lifecycle on a scale of importance, I’d probably put more weight on the left side. The funny part is that the left side is also the quiet one. Alerts, investigations and incidents usually make it obvious when something is wrong.

Pipelines and detections, on the other hand, can be broken for weeks without anyone noticing.

In most SIEMs, you won’t find out until an alert is supposed to fire, assuming it ever does.
By default, not many SIEMs give you particularly good pipeline monitoring(SIEM vendors don't jump now to convince me yours has the best one), so you need continuous testing to catch broken ingestion, parsing or detection logic before the attacker does.

And this is where I think attack emulation, detection validation, pipeline monitoring and the broader SecOps resilience bucket become really important.

Because if you don’t continuously test whether your detections actually catch what they were designed to catch, you basically have two options: trust that they work, or let the attacker QA them for you.
Neither is a great strategy.

Same for pipelines. If logs stop arriving, fields change, parsers break or some connector quietly dies, you might still have a beautiful SIEM dashboard. It just happens to be beautifully wrong.

Attack emulation has obviously been around for a long time, so none of this is particularly revolutionary. What I think is changing is that the category starts to expand. Automated red teaming, BAS, attack emulation, detection validation and probably parts of pipeline validation start converging into something closer to a continuous SecOps resilience layer.

And I think that becomes even more important as the SOC gets more automated. If agents are going to investigate, triage and eventually make more decisions for us, someone still needs to make sure the foundations underneath them are not held together with duct tape and three broken API integrations.

Does attack emulation remain its own category, or does it eventually become a native part of the SIEM / SecOps architecture?

Have a great weekend ahead!

Originally posted on LinkedIn on 11 September 2026
Read the original post and the comments

In case you missed it, RunReveal got acquired by ClickHouse. Yes, you guessed it, this is ClickHouse moving into the SIEM space. They will say they remain a neutral foundation for everyone building security products on top of them.

This is the shift I predicted. Companies that sat on the far left of the secops shift map (data layer, storage, query) are moving right. First they become a SIEM, then they add the rest: AI SOC, SOAR, agent builder.

On the other side, vendors that started in AI SOC and SOAR/automation are now heading toward the SIEM.

Both sides are converging on the same spot. The SIEM space is going through real disruption.

I will say, AI SOC as a technology was the catalyst that triggered the SIEM migration as well. Or AI is the catalyst for rethinking your SecOps stack.

Originally posted on LinkedIn on 4 September 2026.
Read the original post and the comments.

Great work as always by Rob van Os

There are few things caught my attention, and the first one is a SIEM story.

The SIEM is still the single pane of glass for most SOCs. 45% vs 24% for SOAR.
And I think I know why SOAR lost this battle.

🔸 Most SOAR platforms had way better case management than any SIEM. But it never connected well enough with the SIEM. In the end you had to jump back and forth to run queries and investigate, and if your investigation lives in one tool and your case lives in another, you consolidate on the one where you you have all the data to get the job done. That usually ends up being the SIEM in this case.
Funny enough, the same report shows SOAR has taken over as the primary automation tool (70% vs 45% for SIEM).
So SOAR won automation, lost the screen.

▫️Second, only 27% say they use AI embedded in existing tooling. Show me a security tool in 2026 that doesn't ship AI summaries by default. EDR, SIEM, email security, everything has an LLM baked in whether you asked for it or not. My read is not that the rest don't use AI, it's that they don't register it as using AI. When AI is a feature instead of a decision, it becomes invisible. Which also means every AI adoption number in every survey out there is probably understated.

▫️ Third, the AI value numbers. Around 60% report seeing some value from AI in the SOC. But 57% also say they have no AI adoption strategy at all. So who answered the value question? If it's everyone, then people without a strategy (and possibly without real usage) are rating value, and of course you see no value in something you don't use. If it's only the AI users, then the value picture is a subset and shouldn't be read as "AI delivers limited value in the SOC". Before we conclude AI is underdelivering, I want to know the denominator.

Originally posted on LinkedIn on 28 August 2026
Read the original post and the comments

You’ve probably seen the posts and blogs from Rafał Kitab about the very different numbers floating around the SOC. How many alerts analysts handle, how long investigations take, how much time is wasted, how much automation saves.

And somehow, depending on which report you read, the numbers can be very different.

I think some of them are made up. Or, to be nicer, calculated in ways that serve very different purposes.

So we want to see what the reality actually looks like.

No vendor benchmark. No hidden agenda. No “AI saves analysts 97.3% of their day” conclusion already written before we collect the data.

Just practitioner research.

If you’re a SOC leader and want to participate, let us know.

On the plus side, I feel like I’m seeing fewer of those wild reports lately. Not sure if all the ranting changed how the market publishes these numbers, or LinkedIn finally learned to stop serving them to me 😄

Originally posted on LinkedIn on 21 August 2026
Read the original post and the comments

Alex Hurtado put out a really good breakdown of the SIEM operating models this week . Traditional, Decoupled, Integrated SecOps, Federated, and Standalone.

Love the visual, and yes, I think these are currently all the flavors and I see it as operating model map.

Every decision starts with questions about your environment. Your telemetry footprint. Your engineering capacity. Your ecosystem. Whether you’re rebuilding or optimizing. Whether you’re cloud native or still carrying legacy.

Choosing a SIEM it should depend on your PPT. Not the PowerPoint deck you’ll use to present your new SIEM, but your People, Processes, and Technology.

Changing the SIEM platform is only one piece.

Every one of these architectures assumes a different way of operating.

Different workflows. Different responsibilities. Different levels of engineering maturity. In many cases, a completely different skill set within the team.

Some models make perfect sense for lean teams that want simplicity and automation. Others only become practical when you have a larger team with dedicated engineering resources.

So now you have a great resource to help you with this 😀

Originally posted on LinkedIn on 14 August 2026.
Read the original post and the comments

Back at BlackHat after a long pause. It was great catching up in person with peers, prospects and customers.

Full impressions post next week. Right now I am past 24 hours on the road thanks to canceled flights.

First time attending as a vendor, but also as an analyst and researcher of this space. Two different lenses on the same show floor.

First observation. The expo is frown a lot. Maybe even bigger than RSAC, and shorter, so you do not get enough time to walk it properly and see everyone.

Second observation. AI SOC dominated. 40 plus vendors positioning directly in the category. Add 13 SIEM vendors that now claim AI SOC capability and were loud about it. Add EDR vendors. Add NDR vendors, and there were enough of them claiming it that we added a dedicated AI SOC capability field for NDR on our tracker. Put it together and we are close to 60 companies advertising AI SOC in some shape or form. If you want the nuances, you know where to find them SecOps Unpacked.

Now the SIEM part, because this is the SIEM post.

SIEM did not have strong presence at least not as a headline. One of the most widely deployed technologies in security, and it was not heavily advertised. Some rip and replace messaging, as always.

My take. You can break SIEM apart. You can decouple storage, pipeline, detection, search. But what you end up with is still SIEM, just a different deployment model. SIEM is not a product category anymore, it is the core of the SOC.

AI SOC was the theme of this Black Hat. It will be even louder at the next RSAC. Because it is the thing driving the largest transformation of the SOC in the last decade.

And if you walked some of those booths and still cannot make sense of the messaging, the full evaluation framework is on SecOps Unpacked.

More next week.

Originally posted on LinkedIn on 7 August 2026.
Read the original post and the comments.

The play makes a lot of sense.

Cribl has been moving toward the SIEM space for a while and the detection layer was the missing piece. CardinalOps gives them detection engineering, coverage assessment, finding broken and noisy rules. Not a full SIEM yet, but the direction is clear.

And they are not the only ones heading this route. We are seeing more and more players that started as data pipelines moving into SIEM and adding AI SOC on top. The AI SOC piece is what makes them compelling. In the past you needed SOAR-like capabilities to offer the investigation piece, now the agents cover that.

On the other side we see vendors that started as AI SOC moving left into the SIEM piece. Far left into data pipelines is harder to get. But that's where the demand is. Many orgs looking into AI SOC don't just want triage, they want to replace or consolidate their SIEM, MDR and SOAR costs. Every AI SOC conversation is a consolidation conversation.

How I see this playing out, three types of implementations:

>> Platform play. This is where the ISOC category is getting stronger. The usual large players that offer everything.

>> Point solutions and decoupled SIEM. Many smaller solutions added to the stack, combo of vendors plus build it yourself.

>> Existing stack plus MDR and/or AI SOC on top. For those that want minimal tech disruption. And here I think the demand is high, AI SOC with MDR or MDR with AI SOC capabilities.

If you some additional play let me know, writing a full blog piece on this topic.

Originally posted on LinkedIn on 17 July 2026.
Read the original post and the comments.

Look at the large players (some might say traditional SIEM). They all have AI SOC now. It became that commoditized.

Some will argue it's not as deep as the pure-play AI SOC vendors.

You're right. It's not.

But what even is AI SOC?

Over the past year I spoke with over 200 practitioners, and AI SOC meant something different to almost every one of them.

In general, I hear: autonomous triage. Close what's noise, escalate what's worth investigating. But triage itself means different things to different people.

Some see basic enrichment. Some expect AI SOC to go deep, even run forensics. Others expect remediation steps staged and ready, so they just approve execution.

I tried creating key components few times, maybe one day they get standardized and we all agree what it should have until than every SIEM can say it has AI SOC.

In my view it should have:
-Data Ingestion and Normalization Engine
-Knowledge Graph (Context is everything)
-Investigation Engine (combo of automations, LLM rules)
-Response (Remediation actions and Feedback Loop)

So yes, every SIEM has AI SOC. How good, how broad, how deep is up to you to decide. On SecOps Unpacked we tagged it, so you can see which vendors expand further and which stay at basic triage.

And guess what. A SIEM with SOAR, AI SOC, and all the other bells and whistles is still called a SIEM. I don't think the name changes anytime soon.

Do you think we should have this checkbox on SecOps unpacked profiles for AI SOC vendors? Does it even matter to you?

Originally posted on LinkedIn on 10 July 2026.
Read the original post and the comments.

29 are pure-play SIEM with an AI SOC layer. The rest are AI SOC platforms that added SIEM to round out the portfolio.

What stands out is how many other categories they touch. Buy a SIEM from one of the larger players and you get SOAR, UEBA, case management, threat intel, vulnerability context, and 15 other things on top of it.

Most of it is checkbox. It exists to survive an RFP, avoid losing a deal, and give the account team an upsell conversation. I do not blame them. I do the same as a practitioner: I check what my SIEM does natively before I go looking for a point solution. 😅

But good enough is doing a lot of work there.

The SIEM wins or loses on detection quality, query performance, and cost at scale. Everything else is table stakes.

What makes this interesting is that when you map all these capabilities across vendors, many are converging on the same footprint. That is exactly what Gartner's ISOC category describes.

https://lnkd.in/drpSJ7zC

So yeah, is there checkbox feature in your SIEM that you really like?

Originally posted on LinkedIn on 19 June 2026.
Read the original post and the comments.

What I refer to as readiness is monitoring the health of your pipeline. Are the log sources you ingest in good shape? Are your detections in good shape?

I was thinking about a topic for this week and this came to mind. Then I went back through my experience over the years, just to realize the process was almost always broken.

Why I say this: SIEM is usually managed by your engineering team. They implement, fine tune and configure the platform (in some cases even external contractors). They set up the log sources, schemas etc. And they monitor if the data flows as expected, no sharp drops or spikes.

Then it falls on the detection engineering team, or even SOC analysts, to say when something is broken.
Because when you build detections you realize the data is missing key fields or is not parsed properly.
Or as a SOC analyst you see alerts with minimal context, or rules that stopped firing a long time ago. You tell detection eng, they go back to SIEM eng.

In other words, your pipeline can be broken for a very long time and no one will know. Because everyone is too busy doing triage, or building detections for the latest security article that doesn't affect you at all, but you want to show you are covered.

Is it just my experience, or others noticed this problem let's say even trend?

Originally posted on LinkedIn on 12 June 2026.
Read the original post and the comments.

This week: SIEM onboarding

Most SIEM projects don't fail on technology. They fail on planning.

Connect as many systems as possible. Ingest whatever logs you can. Switch on a pile of detections. Then burn the next few months tuning.

The irony is that almost every project kicks off with a detailed implementation plan. Then reality hits. Timelines slip, priorities shift, and the team drifts right back into this reactive loop.

Start with threat assessment and threat modeling.
Know who you're defending against and which techniques actually matter in your environment.

From there:
Build your detection strategy.
Identify the data those detections require.
Then, and only then, decide what logs belong in the SIEM.

Threat intel informs detections. Detections inform data. In that order.

Having the right data and structure together with Detection engineering is the foundation.

Get it right and everything downstream gets easier. Get it wrong and you'll spend months chasing false positives, hoarding data you don't need, and tuning rules that should never have existed.

There are solid tools now for detection engineering, attack mapping, and validation.

Not everything is a crown jewel. If every system is business critical, none of them are.

Rafał Kitab Kitab wrote the definitive version of this, built on 30+ SIEM onboarding projects. He breaks the work into three 30-day phases (centralize and learn, build detections, protect crown jewels) and makes the case for why threat intel drives the whole thing.

https://lnkd.in/eQCt3FWC

I won't ask the question, but I know you will be tempted to share a story, or maybe not 😃

Originally posted on LinkedIn on 26 June 2026.
Read the original post and the comments.

So I will start with the Latio report, I went over it yesterday. For those that didn't see it..

They just dropped their 2026 Security Operations report. Good work. I like how they break the categories, clean and honest about where the lines blur.

I really like "The Guide to Modernizing a SOC Program." visual. That flowchart is the report. It starts in the right place: do you already have a way to ingest and search log data? Everything branches from there.

Adding my take.

If you are running a SIEM migration, or call it SOC modernization, the first question is usually: should I go decentralized data? And in many cases yes, it makes sense. Cheaper. Sometimes faster.

But do not rush.

First check if your current SIEM already supports decentralized data. A lot of them added bring your own bucket and federated search in the last two years. You might already own the thing you are about to migrate for.

Then ask. Why do you want to change the SIEM in the first place? Is it just cost?

If cost is the only reason, fix the data pipeline and the storage tier. You do not need a new platform for that.

If it is more than cost, detection portability, query speed, analyst experience, then maybe you do need different tech.

But understand what you are signing up for. New tech means new processes. You will re-tune detections, retrain analysts, rebuild runbooks.

The migration is the easy part. The process change is the work.

The report sequences it well: optimize the pipeline, decouple the detection engine, then move the data. Half-finished migrations are how teams end up with logs sprawled across three places and nobody sure where they live.

And only then look at where AI SOC fits your case. Agents sit downstream of your data. Bad data in, hallucinations out. No AI analyst fixes a broken data architecture.

More on my next release of the SecOps Shift Map.

LI anyways hates links,so just dropping them here anyhow probably I rolled the dice on low engagement because I want to share links 😅

In case you missed my blog from yesterday around Agent Builders for SecOps: https://lnkd.in/eefyJPjD

And Latio report: https://lnkd.in/eKGa8bKW

Originally posted on LinkedIn on 5 June 2026.
Read the original post and the comments.

I saw a post this week about email being dead. Email is still here. Same with SIEM. Every few years a new category shows up to bury it, and every time SIEM is still standing.

The waves:
UEBA (2014 to 2016). Gartner coined the term. The pitch was that behavioral analytics and ML would make rules-based correlation obsolete. People forget this one, but it was the first real "SIEM is dead" push.

XDR (2018 to 2021). The loudest wave. Nir Zuk of Palo Alto Networks coined the term in 2018 at Ignite, and Cortex XDR shipped in early 2019. Palo Alto's line was literally that SIEM needs to be eliminated and replaced.

Security Data Lake / decoupled SIEM (2020 to 2023). The argument: SIEM is just an overpriced database. So decouple storage from analytics, bring your own lake, and put a detection engine on top.

And now Gartner has a name for the next one: ISOC, the integrated SOC. SIEM, SOAR and AI SOC in one platform, positioned as the next-gen SIEM.

Notice the difference. UEBA, XDR and the data lakes all claimed to kill SIEM. ISOC does not. The new term IS the SIEM.

SIEM does not die. It absorbs the challenger and takes its name.

So will ISOC be the SOC revolution everyone wants? My bet: no. Not because the tech is bad, but because the thing that kills a SIEM was never the category.

Like Rafał Kitab said in a recent post https://lnkd.in/dRQMFsZN your SIEM won't die because of a new term. Your processes and your people can kill it, through bad implementation.

Side note: on the SecOps Unpacked list I now track 36 vendors that pair SIEM with AI SOC. The category is not dying. It is eating its challengers.

Originally posted on LinkedIn on 29 May 2026.
Read the original post and the comments.

If you caught last month post, the SIEM ate the SOAR entree, is finishing the AI SOC main dish, and agent builder is now on the dessert menu.

CrowdStrike, Datadog, Databricks, Elastic, Google SecOps, Palo Alto and many others are adding this. Most are beta or pre-GA, but the direction is clear.

How this has layered over time:
SIEM → added SOAR → added AI SOC → now adding Agent Builder
(and many other things in between but for the sake of the argument I keep it simple)

The SIEM has also been going through major re-architecture in the past few years, and today I was reading a great post by David Bizeul who mentioned that Gartner is working on a new category: ISOC (Integrated Security Operations Center).
https://lnkd.in/dxUDfjxq

This can grow into the new term for next-gen SIEM platforms. Because we all know calling it "next-gen" is lame.

How many years will it take for the new term to stick? Who knows.
But I see SIEM vendors going with "SIEM is dead, long live ISOC" sooner than later.

Side note: if you ask me, I would have gone with Intelligent over Integrated.

But Gartner probably has reasoning behind that choice. Integrated signals the convergence of multiple tools into one platform, which is a safer analyst framing than betting on AI staying central to the definition long term.

Working on a more in-depth piece on this for the blog next week.

Until then, have a great SIEMless weekend.

Originally posted on LinkedIn on 22 May 2026.
Read the original post and the comments.

A few questions I'm curious about:

▪️ SIEM Query Language. Is anyone still writing it by hand? Or are your analysts just typing English and letting the LLM generate the query underneath? And when the generated query is wrong, who catches it?

▪️Parsers. Are you still building custom parsers for your messy log sources, or do you trust AI to handle schema translation and OCSF mapping? How is it working on the weird vendor-specific stuff?

▪️Detections. Anyone still constructing detections by hand for the rules that matter? Or is AI writing them now? What about the existing rule estate, are you using AI to find broken or stale rules?

▪️Dashboards. Is the old way of building custom dashboards gone? Are you letting the SIEM generate visuals on the fly during investigations? What about your operational dashboards, SOC wall, exec metrics, compliance reports, are those still hand built?

Curious to here where we stand with these?

Originally posted on LinkedIn on 15 May 2026.
Read the original post and the comments.

Where AI Actually Belongs in Your Pipeline?

We have been saying this for years. Bad data plus bad processes plus automation equals bad outcomes, faster.
With AI, the same applies. The only catch is now you get it 10x faster and at 100x scale.

Every time I say this on the blog, a podcast, or at a conference, someone asks: "OK, but what's the fix?"

And yes, I’m a big believer in not just pointing at problems without offering a direction forward.

What worked for me throughout my career is simple:
Use the right tools for the right job.

Most teams default to the path of least resistance. They bolt AI onto the end of the pipeline, which in SIEM terms means alerts. It feels like the obvious move. Alerts are where the pain is visible. But it's the wrong place to start, and now it's also the expensive place to start.

We moved from user-based pricing, where you pay a flat rate regardless of activity, to usage-based pricing, where every query, every token, every inference call costs something. That shift makes tool selection a financial decision, not just a technical one.

Burning tokens on noisy, low-quality alerts is not just inefficient. It is a budget problem.

The right sequence is this. Use AI first where it compounds. Start with your data pipeline. Fix structure, normalization, and coverage gaps. Then move to detections. Improve logic, reduce noise, raise signal quality. Only after that should you apply AI to triage and analysis.

If you skip straight to the alert layer, you are not accelerating your SOC. You are paying to automate a broken process.

Shift left. Then use AI.

Originally posted on LinkedIn on 8 May 2026.
Read the original post and the comments.

LOG EVERYTHING. I know for some of you this might be scary, you see cash burning instantly, million dollar bills. And yes, depending on the size of the company and the SIEM they use, this might be doable. I have been part of orgs where it was, I loved it. You get a new log source, try to pull as much as possible.

Best part was whenever I needed to create a new detection I would just get everything I needed, no need to go through the log onboarding process again. Additional logs for forensics or deep investigation, I get them right away. Audit comes, we have everything, pass it on the fly.

Then there is the least optimistic way, onboard whatever we need just to have basic coverage and pass an audit or get a cert. Minimal coverage. I think in this case you are better off just using an MDR or MSSP, don't even bother. Anyhow you have partial coverage with them.

And we have the sweet middle, where you onboard just what you need, increase and decrease logs based on usage, you have a nicely balanced bill. In my opinion this one looks good on paper. In reality, adding logs is never easy, simply because of other stakeholders, and you will always have audit findings that need to be prioritized over engineering work. You end up paying close to option 1 and getting close to option 2.

Maybe I'm missing some other approach, let me know.

Originally posted on LinkedIn on 1 May 2026.
Read the original post and the comments.

SIEMs own the data, so they have the upper hand here.

Especially for teams that send everything into the SIEM, you will get amazing triage results inside it, simply because the SIEM has all the data. If done right, they can query that data the fastest and most optimized way to get you the best results. Timeline analysis, blast radius, all the bells and whistles.

But ONLY if you get all the data there.

This means enrichments as well.

Then you will be limited on response.

As I explained in my previous posts, SIEM vendors were smart to play the SOAR card. The bad part is that they never invested enough to make it shine. In my opinion, unless you have all response in a single ecosystem, you need a vendor agnostic agentic, automation, and orchestration layer.

Where the pure play and SOAR vendors have the upper hand is when you don't send everything to your SIEM.

They do enrichment better, but they are somewhat limited on what APIs they have available with the SIEM to run queries and retrieve data, or with any other system from which you ingest alerts and detections.

And SOAR-like vendors will shine with the response. Slapping MCP for response won't make the cut.

On this and more, I will join Chris Hughes on May 4th where we will discuss this and other fun topics.

https://lnkd.in/dXzpAJiy

ʜᴀᴠᴇ ᴀ ɢʀᴇᴀᴛ ᴡᴇᴇᴋᴇɴᴅ!

Originally posted on LinkedIn on 24 April 2026.
Read the original post and the comments.

The SOAR entree. Most if not all large SIEMs shipped their own SOAR. Latest was Elastic announcing Elastic Workflows this March. They're calling it the end of the "SOAR automation tax."

The patterns split into a few categories.

Acquisition path: Palo Alto (Demisto), Splunk (Phantom), Google SecOps (Siemplify), Fortinet (CyberSponse).

Took years for some to even get a unified UI. Separate infra, a lot of stitching, you could sense it. Development slowed or got abandoned. What's left is mostly case management with basic automation and integrations stuck within the vendor ecosystem.

Built from scratch: Elastic and Datadog developed natively. Worked with Datadog's for a few months. Decent, simple, but not a true automation platform. More case management orchestration.

EDR turned SIEM turned SOAR: CrowdStrike and SentinelOne. Checkbox items. Great at basic case orchestration within their own ecosystem and automating notifications. That's about it.

The AI SOC main dish. Most major SIEM players now have some form of AI SOC. I expect the same pattern as SOAR. Some acquire, others build. Same fragmentation likely. This connects to what Ross Haleliuk wrote recently about AI agents challenging the SIEM business model. SIEMs charge for ingestion. AI agents don't care if data is centralized. People expect analytics and workflow automation, not just storage.

Agent Builder as dessert. CrowdStrike, Palo Alto, Databricks all have agent builder capabilities now. Most still early beta but that's the direction. Building an agent framework natively inside a SIEM is hard and I don't think most vendors are there yet.

Standalone automation platforms have a real advantage here. Being on the builder side and seeing what it takes, the complexity is significant. I expect many SIEM vendors will go the acquisition route. Same playbook as SOAR.

And we might end up in the same place too. SIEM vendors building agent builders around their own ecosystems rather than connecting to everything. Agents that only work within one vendor's stack defeats the whole purpose.

A SOC doesn't run on one vendor.

Originally posted on LinkedIn on 17 April 2026.
Read the original post and the comments.