AI is arriving in security operations as a productivity story: faster triage, better investigations, fewer alerts, and more automation.

That is real. But the larger change is that AI creates new actions, attack paths, and evidence that security teams need to capture and understand. The question is no longer only whether an endpoint or identity behaved suspiciously. It is also: what did an agent know, which tools did it call, under whose authority did it act, what did it change, and what happened next?

SIEM Remains The System Of Record

AI will not eliminate the SIEM or security data platform. It may make the traditional SIEM UI less important, but it makes trusted data more important. If telemetry is incomplete, identity and asset context is inconsistent, or detections are weak, AI simply reaches conclusions faster on top of uncertain inputs.

A modern SIEM should therefore be more than a log store and search interface. It should be an evidence and control layer: a place where data is reliable, context is preserved, access is governed, and consequential actions can be explained.

There may be an opportunity for the SIEM to become the authoritative home of the security context graph: not merely a visualization, but the maintained relationship between identities, devices, workloads, applications, data, permissions, ownership, and policy. AI agents need that context before they can safely reason or act.

AI Creates New Security Telemetry

Traditional telemetry tells us what happened on a system or network. AI systems require us to capture part of the decision path as well. For consequential agent activity, organizations will need to know:

• Which identity and permissions the agent used
• What information and tools it could access
• Which systems it called
• What it changed or attempted to change
• Which policies, approvals, or exceptions applied

This is not only an incident-response requirement. It matters for audit, compliance, and accountability. If an agent changes data that feeds financial reporting, accesses sensitive information, or takes a production action, an application log saying “completed successfully” is not enough. Sarbanes-Oxley may not mention agents by name, but the underlying internal-control and evidence problem is obvious.

Intent Is Interesting, But It Is Not Truth

New endpoint vendors including Neo, Glow, Ent, and others are focusing on a different layer of the endpoint: observing user and agent behavior, then inferring intent. That is worth watching closely. Ent explicitly frames its approach as intent-aware security across human, AI, and application activity, while Neo and Glow are pursuing AI-era endpoint control and prevention from adjacent angles. Ent, Neo, and Glow are useful examples of the emerging category.

Traditional EDR is still needed for attacks that reveal themselves in low-level evidence: process execution, network activity, and known attacker techniques. But those signals can be insufficient when developers, administrators, and AI-enabled workers legitimately perform highly variable and sensitive work. We can find many attacks at the system layer, while insider-risk activity or misuse of legitimate access may remain hard to distinguish.

Intent signals can add context. Is a sequence of actions consistent with a developer deploying software, an administrator performing maintenance, or an agent moving outside its mandate?

But intent is a probabilistic signal, not a verdict. It should complement evidence from endpoints, identity, cloud, applications, data, and agents—not replace it. That is another reason we need a central correlator or analytics platform. Let’s keep calling that a SIEM.

Security Needs Three Clocks

The need to correlate all of that evidence creates a timing problem.

An endpoint or identity control may see a risky action immediately, but the evidence needed to understand it may be spread across cloud systems, containers, SaaS applications, sandboxes, and downstream tool calls. Some context arrives seconds later. Some appears only after an agent has completed a chain of work. Some only matters when an investigator or auditor returns months later.

Security therefore needs to work across three clocks:

• First, there is inline prevention: block the clearly dangerous action before it can do damage.
• Second, there is delayed contextual assessment: reassess the event minutes later, once the surrounding identity, application, cloud, and agent telemetry has arrived and can be rejoined.
• Third, there is long-term reconstruction: retain the evidence needed for hunting, incident response, audit, legal review, and lessons learned.

The point is not to delay every decision. It is to recognize that the best immediate decision and the best informed decision may occur at different times—and both need to be explainable.

What This Changes For MDR

This need to capture agent actions, join them with broader context, and preserve reliable evidence across all three clocks changes MDR too. The future MDR is not simply an AI SOC that processes alerts with fewer analysts. It has to operate the telemetry, detection, context, and accountability loop around AI-enabled environments.

That means ensuring the right telemetry is collected, maintaining the context graph that makes it useful, testing detections, defining which actions can be automated, preserving approvals and exceptions, and proving later what the system saw and did.

AI may reduce manual work in the SOC. It does not remove the need for a trusted security operating layer. When AI acts, security has to remember not only what happened, but why.

A company strategy deck is not a value-creation plan.

Over the past year, I have worked with private equity firms, boards, MSSPs, MDR providers, and cybersecurity vendors on corporate strategy, product direction, packaging, go-to-market, AI, and operating models. The situations have varied, but the underlying problem is often the same:

Most companies do not lack ideas. They lack the operating system required to turn those ideas into results.

They may have a board strategy, product roadmap, sales plan, AI initiative, and financial target. But these often exist as separate artifacts. Product is not aligned with go-to-market. Packaging does not reflect delivery economics. Sales targets assume demand that has not been validated. The board tracks outcomes without understanding their causes.

In a private equity-backed company, the value-creation plan should be the management system that connects the investment thesis to strategic choices, operating initiatives, accountable owners, leading indicators, and financial outcomes. It is not another presentation. It is how the company runs.

TL;DR

• Most strategy problems become operating problems.
• Product, packaging, sales, and delivery have to reinforce one another.
• Growth problems require diagnosis before more investment.
• AI matters when it changes customer outcomes or company economics.
• The CEO owns enterprise priorities, cross-functional trade-offs, and resource allocation; the board tests assumptions and improves the quality and speed of consequential decisions.

Packaging Exposes the Operating Model

I recently looked at a cybersecurity services portfolio that had grown organically over many years. The company had strong capabilities, valuable customer relationships, and deep domain expertise. It also had a large menu of services that could be combined in many different ways.

The initial question was how to improve the packaging. The deeper issue was the operating model.

Salespeople had too many options. Customers struggled to understand what they should buy. Delivery teams supported exceptions, custom combinations, and unclear boundaries between recurring services, add-ons, and projects. We worked backward from the customer: What problem caused the customer to buy? Which outcomes mattered? What should be included by default? What belonged in a fully managed service, a co-managed model, an add-on, or a paid project?

That led to a simpler product architecture with clearer entry points, packages, ownership boundaries, and upgrade paths. But this was not merely a marketing exercise. Packaging determines what sales sells, what customers understand, what delivery has to support, and where exceptions enter the system. It reveals whether product strategy and delivery economics are actually aligned.

A complicated catalog is often presented as customer choice. In reality, it can be evidence that the company has avoided making strategic decisions.

Diagnose Growth Before Funding It

In another situation, a company wanted to accelerate growth across several market segments. Two segments were underperforming, but for very different reasons.

In the first, the company was generating interest but failing to convert enough opportunities. The market recognized the problem, but the offer, proof, packaging, or sales process was not strong enough. In the second, too few qualified opportunities were entering the funnel. The company occasionally won business, but the market was not consistently responding to the message.

One was primarily a conversion problem. The other pointed toward ICP, positioning, channel, or market attractiveness. They required different responses. More marketing will not fix a broken buying process. More sales capacity will not fix a weak market position. Better enablement will not create urgency where customers do not feel it.

Yet companies often respond to a missed target by demanding more pipeline, hiring more salespeople, changing compensation, or launching another campaign. Sometimes that works. Sometimes it simply adds cost to a weak market thesis.

Before allocating more capital, management and the board have to establish what is actually true.

Operating Leverage Is the Real Test

For MSSPs, MDR providers, and other technology-enabled services businesses, productization is not defined by having a portal, integrations, proprietary technology, automation, or an AI story. The question is whether the delivery model becomes more scalable as the company grows.

The clearest test is what the next customer requires. If each new customer brings more tuning, analyst work, custom reporting, manual integration, and delivery exceptions, growth remains labor-dependent. If that customer can be served through reusable detections, workflows, automation, and product improvements, operating experience begins to compound.

I have seen enormous expertise trapped inside analysts, tickets, scripts, spreadsheets, and customer-specific processes. Productization means turning that knowledge into standard workflows, captured context, response policies, and automation so experts handle the exceptions rather than repeatable work. Done well, customer outcomes, consistency, and margins improve together.

AI should be judged by the same standard. It matters when it removes an economic or customer constraint: less repetitive work, faster product development or implementation, lower service-delivery costs, better sales productivity, or a meaningfully better customer outcome. If none of the underlying numbers move, the company may have an AI initiative. It does not yet have an AI operating model

The Board Needs Causality. The CEO Must Integrate.

I have seen board reporting with dozens of accurate metrics but limited operational clarity. The board can see that growth, gross margin, or retention is below plan, but not why. If gross margin is deteriorating, is it pricing, vendor cost, implementation effort, support burden, utilization, or delivery exceptions? If bookings are weak, is the problem pipeline, conversion, sales capacity, positioning, product competitiveness, or retention? And if churn is creeping into the customer base, why are we losing these customers? Probably one of the harder questions to answer, but just saying that they went with another competitor is not going to help build a sustainable business.

A useful value-creation plan makes those relationships visible. It connects the investment thesis, strategic priorities, accountable executives, leading indicators, financial outcomes, and decisions required.

The board should not run the company. It should help management confront the right facts and make consequential decisions quickly. Strong board members do more than review dashboards. They improve the quality, speed, and accountability of decisions.

The CEO’s role is different. Functional leaders optimize their areas. The CEO has to optimize the whole company. A custom feature may help close a deal but increase delivery cost. A broad portfolio may expand theoretical market size but weaken sales effectiveness. Cost reductions may improve short-term EBITDA while damaging product relevance. More services may increase revenue but make the company less scalable. The CEO’s unique responsibility is to connect market reality, strategic choices, product, go-to-market, organizational capability, operating cadence, and capital allocation. This is true in a high-growth company, a private equity portfolio company, a founder transition, or a turnaround. The urgency differs, but the work is remarkably similar: establish what is true, decide what matters, stop what does not, align the organization, and turn the strategy into measurable value.

These are the situations I find most interesting: a strong company entering its next phase, a cybersecurity business that has outgrown its original operating model, or an organization where product potential and market opportunity have not yet translated into consistent execution.

If you are a private equity sponsor, board member, or cybersecurity CEO working through one of these transitions—or looking for an operator to lead the next phase—I would welcome the conversation.

Strategy sets the direction. The operating system creates the value.

In the last post, I argued that AI maturity is not about tool count. The real question is whether AI is changing how the company works.

That leads to the next question: if AI is becoming a company operating system layer, what actually belongs inside that layer? The answer is not “a chatbot for every department.” It is a set of shared capabilities that help the company use context, signals, decisions, workflows, and governance more effectively.

The context layer

Every company has operating context, but most of it lives in places AI cannot reliably use: board decks, strategy documents, Slack threads, CRM notes, offsite summaries, and executive memory.

That context matters because it tells the company what good looks like. AI systems need to understand the company’s ICP, strategic priorities, product direction, pricing logic, market narrative, board-level constraints, and risk appetite. Without that, agents can still generate output, but they are not operating from the company’s actual logic.

This is where many AI efforts stay shallow. They automate tasks without encoding the context that should guide those tasks.

The signal layer

A company AI OS also needs signal. That signal comes from the systems where reality shows up:

• Sales calls and win/loss data
• CRM fields and pipeline movement
• Product usage and telemetry
• Support tickets and implementation friction
• Customer success notes and renewal risk
• Roadmap tradeoffs and engineering throughput
• Financial data, margin structure, and cost trends
• Market signals, competitor movement, and regulatory change

The point is not to dump all of this into a model. The point is to make the right signals available, governed, and useful. A company that cannot connect its customer conversations, product reality, and financial outcomes will struggle to make AI operationally meaningful.

The decision layer

The next layer is decision support. This is where AI should help the company reason across functions instead of just accelerating isolated tasks.

For example, sales may hear that a feature is winning deals, support may see that the same feature is causing implementation pain, product may be planning adjacent roadmap work, and finance may care about the gross margin impact. In many companies, those signals never meet in time to shape a better decision.

A useful AI operating layer should help surface those tensions earlier. It should not replace executive judgment, but it should improve the quality and speed of the inputs that judgment depends on.

The execution layer

Once context, signal, and decision support exist, AI can start to push work forward. This is where agents, workflows, and automations become useful.

The execution layer might help:

• Draft follow-ups from customer calls
• Turn product feedback into structured roadmap input
• Identify sales patterns across calls and accounts
• Prepare weekly operating reviews
• Monitor project slippage
• Summarize customer risk
• Suggest next actions for account teams
• Generate board-ready updates from operating data

This is where AI starts to feel less like a productivity tool and more like part of the company’s operating rhythm. But it only works if the earlier layers are in place. Otherwise, execution becomes more automation noise.

The governance layer

The governance layer is often treated as a blocker, but it should be part of the operating system itself. Companies need to define which models are approved, which data sources can be used, what retention rules apply, where human approval is required, and how agent behavior is monitored. The old version of this is a policy page that few people read. The better version is policy that agents can actually access and follow.

That does not remove the need for human governance. It makes governance executable.

The real test

A company AI OS is not a single platform. It is the connective tissue between company context, business signal, decisions, workflows, and governance.

The test is not whether the company has deployed AI tools. The test is whether AI helps the company operate with better speed, clarity, consistency, and control.

If AI only generates more content, it is still a feature layer. If it helps the company sense, decide, execute, and learn, it is becoming an operating layer.

In a previous post, I argued that AI is becoming a company operating system layer. The natural next question is how to tell whether that is actually happening inside a company.

The answer is not how many copilots are deployed, how many employees have access to ChatGPT, Claude, Cursor, or Codex, or how many AI experiments appear on an executive dashboard. Those are adoption signals. They are not operating model signals.

The better question is whether AI is changing how the company actually works.

Start with the workflow, not the tool

One mistake I see in AI maturity conversations is that they start with the wrong question: “How are you using AI?” It sounds reasonable, but it often produces a shallow answer. People list tools. Teams describe experiments. Executives get a dashboard. Everyone feels like something is happening.

A better diagnostic starts earlier. Before asking about AI, you have to understand how the company operates today:

• How does engineering ship?
• How does product decide what to build?
• How does sales learn why it wins or loses?
• How does customer success detect risk?
• How does finance understand cost and margin impact?
• How does governance decide which data AI systems can access?

If those workflows are unclear, inconsistent, or poorly instrumented, AI will not magically fix them. It will usually amplify the fragmentation.

AI activity is not AI operating leverage

Most companies already have plenty of AI activity. Engineers are using coding agents. Marketing teams are generating copy. Sales teams are summarizing calls. Product teams are drafting requirements. Support teams are experimenting with automation.

The problem is that much of this is happening independently. Different teams use different tools. Different people create different prompts. Different functions maintain different versions of the truth. Governance is often a policy page somewhere, not something agents can actually read and enforce. Management may see usage, but not impact.

That is not an AI operating model. It is distributed experimentation. A company can have high AI usage and still have low AI maturity.

What a real diagnostic should look for

A useful AI maturity assessment should not just ask who has licenses. It should look at whether AI is improving the operating system of the company.

That means asking:

• Are existing workflows documented well enough for AI to assist them?
• Are teams using shared patterns, or is every function inventing its own?
• Are the right data sources available, clean, and governed?
• Can the company measure whether AI improves speed, quality, cost, or predictability?
• Do agents know what data they are allowed to use, or are rules trapped in static documents?
• Is AI helping the company learn from customer calls, support tickets, product usage, roadmap decisions, and financial outcomes?

The point is not to create a more elaborate AI dashboard. The point is to understand whether AI is becoming part of how the company senses, decides, executes, and learns.

The board-level question

For CEOs, boards, and investors, the question should not be: “Do we have an AI strategy?” It should be whether AI is creating operating leverage.

A board should be asking:

• Is AI reducing decision latency?
• Is it improving engineering throughput?
• Is it helping sales understand why deals are won or lost?
• Is it improving retention signal?
• Is it exposing risk earlier?
• Is it changing the margin structure of the business?

If the answer is no, the company may still be in the experimentation phase, even if AI usage looks high.

That is why AI maturity is not about tool count. It is an operating model assessment. The companies that get this right will not be the ones with the longest list of AI tools. They will be the ones that turn AI into a repeatable way to improve workflows, decisions, governance, and execution. And last but not least, companies with clean workflows that are ideally already documented, will win in adopting AI quickly.

I had a few conversations over the past days that all pointed to the same conclusion: many technology companies are still being built like old SaaS companies. That is a mistake. If you are building a technology product now, the priority is not a polished frontend. It is the backend: the data layer, the ontology, the APIs, the analytics layer, the authentication model, and the infrastructure that makes AI agents fast, reliable, and cheap to run on top of the data backend. The frontend still matters, but it should not be the center of gravity anymore.

TL;DR

• Start with the backend and data model, not the dashboard.
• Build for token efficiency as a product requirement, not just an infrastructure metric.
• Expose core capabilities through APIs and agent-friendly interfaces first.
• Keep the UI light, flexible, and increasingly self-serve.
• If every deployment needs heavy forward deployed engineering, the product is not ready yet.

The Moat Is Moving Down the Stack

In the old SaaS model, a lot of value sat in the application layer. You built workflows, dashboards, role-based views, and configuration screens. In AI-native software, that is no longer enough. The durable part of the company is increasingly lower in the stack: the system that structures data correctly, retrieves the right context quickly, exposes useful actions cleanly, and does all of that in a reliable and token-efficient way.

If that layer is weak, the rest of the product becomes slow, expensive, brittle, and hard to customize. If that layer is strong, you can build a surprising amount on top of it very quickly.

The UI Should Get Thinner

A lot of teams still think about product development as: first build the dashboard, then add AI to it. I think it is increasingly the opposite. First build the backend that can answer questions, retrieve context, execute actions, and expose capabilities cleanly. Then add lightweight interfaces on top.

Initially, those interfaces may be very thin. In some cases they may barely be a product UI at all. A technical user might interact through Claude, another agent interface, or an internal tool layer. Over time, you can add more purpose-built interfaces and dashboards, but those should sit on top of a backend that already works well in a headless way.

Token Efficiency Is a Product Decision

One of the bigger mistakes right now is treating token usage as a backend optimization problem. It is not. It is a product design problem. If your system cannot give agents the right context in the right shape, the product becomes costly to operate and difficult to scale. That affects margins, response times, user experience, and the kinds of workflows that are even viable.

This is why the backend matters so much. You need data structures, query systems, and analytics layers that are built for AI interaction, not just for human dashboards. A beautiful interface on top of an inefficient backend is not an AI product. It is a demo with a future cost problem.

The Goal Is Self-Serve Customization

A lot of tech companies are also running into the same trap: they need too much forward deployed engineering to make each customer successful. That is understandable for now, but it is not where you want to stay. The goal should be to make the platform configurable enough that a solutions engineer, a sales engineer, or eventually even the customer can shape the experience without constantly pulling in core backend engineers.

That only works if the system is designed the right way. If the logic, data model, and capabilities are modular and exposed well, you can let people create their own views, workflows, and operating layers on top. If not, every customer request turns into a product detour.

Build the engine first. Build the data layer properly. Make it fast, cheap, reliable, and cleanly exposed. Then let the frontend become lighter, more dynamic, and more self-serve over time. That is increasingly the difference between an AI first company and a SaaS company with an AI feature.

Update (2026-02): I released the SIEM Maturity Framework Workbook (v1.0) that turns this post into a practical scoring tool.

I have been talking to a few AI SOC and new SIEM market entrants over the past few weeks. I have voiced some opinions in previous posts but have now started to capture a list of features that I believe represent the openings existing SIEM players have created in the market for these new vendors to emerge.

Before I outline what I think those features are, let me be clear: this is my list. I am aware that existing SIEM vendors will claim that they already do many of these things. All I will say is this: market churn and capital flow suggest that these capabilities are either not as mature or not as integrated as claimed.

And to the AI SOC companies and investors: be careful about the short-term problems your investments are solving. Yes, there is real traction with MSSPs that are overloaded with false positives. And yes, many will gladly pay to reduce alert workload by 80%. But in many cases, these problems are being addressed superficially. Make sure you audit the underlying approaches and verify that the foundational infrastructure is sound. Solving this problem on top of an existing detection infrastructure doesn’t solve the problem at the core, which is the detections themselves. We need to fix those with some of the suggestions below to not needing a top-layer, alert reducer.

Without further ado, here are the items I am tracking. I welcome other opinions and additions to the list (no guarantee I will include them). Over the coming weeks, I will also try to rate some of the players across these categories to enable comparison. I could use help with that. Ping me.

A. DATA & CONTROL PLANE ARCHITECTURE

• Federation – The ability to query and reason over data where it lives, without forced centralization.
  (Another post following here at some point about the limitations of federation).
• Data Pipeline Optimization – Dynamic ingestion pipelines that enrich, route, sample, and filter data based on use case, risk, and downstream value. Not static “send everything to the lake.”
• Data Awareness – Understanding what data exists, what is missing, and what has silently degraded. The system must continuously reason about its own observability.
• Performance as a First-Class Constraint – Fast joins and low-latency queries across all relevant data. Real-time rule execution at scale. This is not about basic scalability, but about maintaining predictable performance as rule count and complexity increase, without simply throwing more compute at the problem.
• Modern AI Integration – The ability to integrate with emerging architectural patterns and frameworks, including MCP servers, vector stores, and related systems.

B. DETECTION & LEARNING SYSTEMS

• Hypothesis-Driven Hunting – Hunting should start with explicit hypotheses, not ad-hoc queries. These hypotheses should evolve, fork, and self-update based on outcomes. Agents swarms anyone?
• Automated Detection Tuning (Closed Loop) – Detections must evaluate their precision and recall over time. False positives and false negatives are signals. Humans stay in the loop, but are not the tuning engine. This also helps separate the detection engineering from the tuning that should be done by analysts.
• Environment-Adaptive Detections – Rules and models must adapt automatically to the specific environment, business processes, and user behavior and analyst feedback. Generic detections are table stakes.
• Detection Lineage and Memory – The system must remember why a detection exists, how it has changed, and what outcomes it has historically produced.

C. ENTITY-CENTRIC RISK & CONTEXT

• Asset Awareness – Effective protection and detection start with understanding what is being protected. Entity visibility is foundational: who owns this entity, what does it do, and which business processes does it support?
• Real-Time Entity Risk Scoring – Each entity has a continuously updated risk score driven by behavior, exposure, and contextual signals.
• Entity Risk Context – Risk is not a number. It is a set of properties that help explain the risk and provide context for decision making.
• Business Context Integration – Entities must be tied to business processes, ownership, and criticality, and this context must inform alert generation and prioritization. Some people have started calling this the Context Graph.

D. OPERATIONAL REALITY (SOC, MSSP, ENFORCEMENT)

• Simple Query Interface: Support for both natural language and structured query languages (such as KQL). Analysts need both.
• Alert Triage Automation – Using ‘advanced’ context to tune detections. Ideally we have business context available to continuously improve our detections.
• Blindspot Detection – The system must actively identify where detections cannot exist due to missing or degraded logs or logging configurations. This includes making sure that log sources are actually staying up and keep reporting what they have to.
• Real-Time Readiness for Enforcement – We need our systems to become preventative. Therefore, its risk model must operate in near real time. Attackers are acting too fast.

A Few Additional Comments for Context

This is not meant to be a SIEM RFP. I am intentionally not listing table-stakes capabilities such as basic scalability, data source support, or baseline detection depth.

This list is less about features than about where intelligence and control actually live in the system. I am also not being prescriptive on how these features are built. Many of them can benefit from AI / LLM / ML approaches and, in fact, should be using them.

Look at the list, then look at your AI SOC platform of choice. How much of the above does it truly cover?

If you are evaluating an AI SOC platform and most of its value proposition lives above alerts rather than below them, you should be skeptical.

Update (2026-02): I released the SIEM Maturity Framework Workbook (v1.0) that turns this post into a practical scoring tool.

And why most of the arguments do not hold up under scrutiny

Over the past 18 to 24 months, venture capital has flowed into a fresh wave of SIEM challengers including Vega (which raised $65M in seed and Series A at a ~$400M valuation), Perpetual Systems, RunReveal, Iceguard, Sekoia, Cybersift, Ziggiz, and Abstract Security, all pitching themselves as the next generation of security analytics. What unites them is not just funding but a shared narrative that incumbent SIEMs are fundamentally broken: too costly, too siloed, too hard to scale, and too ineffective in the face of modern data volumes and AI-driven threats.

This post does not belabor each startup’s product. Instead it abstracts the shared assertions that justify recent funding and then stresses them to see which hold up under scrutiny. I am not defending incumbents. I am trying to separate real gaps from marketing (and funding) narratives.

The “SIEM is Broken” Narrative

A commonly cited industry report claimed that major SIEM tools cover only about 19% of MITRE ATT&CK techniques despite having access to data that could cover ~87%. That statistic is technically interesting but also deeply misleading: ATT&CK technique coverage is not an operational measure of detection quality or effectiveness, it primarily reflects rule inventory and tuning effort. Nevertheless, it has become a core justification for the “SIEM is obsolete” narrative. I wasn’t able to find the original report to validate what and how they tested, but I have seen SIEMs that cover much more and have big detection teams taking care of these issues.

The Five Core Claims Driving the Market Thesis

Across decks, interviews, and marketing copy, I picked five recurring themes that define what these companies think incumbents get wrong and what investors are underwriting as the path forward.

1. “Centralized SIEM architectures no longer scale”

The claim is that forcing security telemetry into a centralized repository is too expensive and too slow for modern enterprises generating terabytes of logs every day. The proposed fixes include federated queries, analyzing data where it lives, and decoupling detection from ingestion so you never have to move or duplicate all your data.

The challenge is that correlation, state, timelines, and real-time detection require locality. Distributed query engines excel at ad-hoc exploration but are not substitutes for continuous detection pipelines. Federated queries introduce latency, inconsistent performance, and complexity every time you write a detection. Normalization deferred to query time pushes complexity into every rule. You do not eliminate cost, you shift it to unpredictable query execution and compute costs that spike precisely when incidents occur. Centralizing data isn’t a flaw; it is a tradeoff that supports correlation engines, summary indexes, entity timelines, and stateful detections that distributed query models struggle to maintain in real time. In fact, if the SIEM was to store the data in the customer’s S3 bucket, you can keep cost somewhat under control.

2. “SIEM pricing is broken because it charges by data volume”

A frequent refrain is that incumbent SIEMs penalize good security hygiene by tying pricing to ingestion volume, which becomes untenable as data grows. The proposed response is pricing models untethered from volume, open storage, and customer-controlled compute.

The challenge is that cost doesn’t vanish because you hide volume. Compute, memory, enrichment, retention, and query costs all remain. If pricing is detached from ingestion, it typically reappears as unpredictable query charges, usage tiers, or gated features. Volume is not an arbitrary metric; it correlates with the cost a vendor (or customer) incurs. Treating cost as orthogonal to data volume does not make it disappear; it just blinds you to a key cost driver. I have dealt with all the pricing models: by user, by device, by volume, … in the end I needed to make my gross margins work, guess who pays for that?

3. “SIEM detections are weak because they rely on bad rules”

New entrants commonly assert that traditional SIEM rules are noisy, static, and unable to keep up with modern threat techniques. Solutions offered include natural-language detections, detections-as-code, continuous evaluation, and AI-generated rules.

The challenge is that many of these still sit atop the same primitives. For example, SIGMA is widely used as a community detection language, but it is fundamentally limited: it is mostly single-event, cannot express event ordering or causality, has no native temporal abstractions or entity-centric modeling, and cannot natively express thresholds, rates, cardinality, or statistical baselines. Wrapping these limitations in AI or “natural language” does not change the underlying detection physics. You can improve workflow and authoring experience, but you do not fundamentally invent a new class of detection with the same primitives. And guess what, large vendors have pretty significant content teams – I mean detection engineering teams – often tied into their threat research labs. Don’t tell me that a startup has found a more cost effective and higher efficacy way to release detection rules. If that were the case, all these large vendors would be dumb to operate such large teams.

4. “SIEMs lack context, causing false positives”

The argument here is that existing SIEMs flood analysts with alert noise because they lack deep asset context, threat intelligence, or behavioral understanding. New entrants promise tightly integrated TI feeds, cloud context, or built-in behavior analytics.

Context integration has been a focus of incumbent platforms for years. The real hard problem is not accessing context but operationalizing it without drowning analysts. More feeds often mean more noise unless you have mature enrichment pipelines, entity resolution, and risk scoring built into rules that understand multi-stage attack sequences. Adding more sources does not automatically improve signal quality. The noise problem is as much about rule quality and use-case focus as it is about context availability. Apply the same argument here with regards to the quality of threat feeds that I outlined in the last item.

5. “AI-native SIEMs will finally fix detection and response”

Perhaps the most seductive claim is that incumbent SIEMs were built for a pre-AI world and that new platforms built with agentic AI at every layer will finally crack automation, detection, and investigation.

The challenge is that AI does not eliminate the need for structured, high-quality, normalized data, or explainability, or deterministic behavior in high-risk contexts. AI can accelerate workflows, assist with investigation, and suggest hypotheses, but it does not replace the need for precise, reproducible, and auditable detection logic. Most AI-native claims today are improvements in UX and speed, not architectural breakthroughs in detection theory.

The Uncomfortable Conclusion

VC money is flowing because SIEM is operationally hard, expensive, and often unpopular with SOC teams. There is real pain and real gaps, especially around cost transparency, scaling, and usability. But declaring existing SIEMs obsolete because they are imperfect is not a thesis; it is a marketing slogan.

The core assumptions driving this funding wave deserve scrutiny: centralization is treated as a flaw rather than a tradeoff necessary for continuous detection, pricing complaints get conflated with architectural insights, detection quality is blamed on tooling rather than operational realities, and AI is overstated as a panacea.

On the flip side, here are a couple of directions that should be looked at:

1. Some of the new entrant SIEMs actually make a dent. They are rebuilding their entire pipelines and storage architecture with modern technologies, not old paradigms. They have a clear advantage and don’t have to deal with millions of lines of tech debt. Using an agentic AI architecture could be quite interesting here.
2. As the AI SOC emerges – and maybe become a reality – we will probably see more and more MCP servers exposing infrastructure information that can be leveraged, from alerts to context to response capabilities. But we’ll need to see how data schemas and all that will evolve.
3. The one innovation that has already generated some returns for investors is the entire data pipeline world. Companies like Observo (I had the privilege to be an advisor) have truly added something useful to the SIEMs and as I argue in one of my previous blogs, needs to really become a capability baked into each SIEM out there.

Thanks for the feedback, Jesse!

Before diving into cyber security and how the industry is using AI at this point, let’s define the term AI first. Artificial Intelligence (AI), as the term is used today, is the overarching concept covering machine learning (supervised, including Deep Learning, and unsupervised), as well as other algorithmic approaches that are more than just simple statistics. These other algorithms include the fields of natural language processing (NLP), natural language understanding (NLU), reinforcement learning, and knowledge representation. These are the most relevant approaches in cyber security.

Given this definition, how evolved are cyber security products when it comes to using AI and ML?

I do see more and more cyber security companies leverage ML and AI in some way. The question is to what degree. I have written before about the dangers of algorithms. It’s gotten too easy for any software engineer to play a data scientist. It’s as easy as downloading a library and calling the .start() function. The challenge lies in the fact that the engineer often has no idea what just happened within the algorithm and how to correctly use it. Does the algorithm work with non normally distributed data? What about normalizing the data before inputting it into the algorithm? How should the results be interpreted? I gave a talk at BlackHat where I showed what happens when we don’t know what an algorithm is doing.

So, the mere fact that a company is using AI or ML in their product is not a good indicator of the product actually doing something smart. On the contrary, most companies I have looked at that claimed to use AI for some core capability are doing it ‘wrong’ in some way, shape or form. To be fair, there are some companies that stick to the right principles, hire actual data scientists, apply algorithms correctly, and interpret the data correctly.

Generally, I see the correct application of AI in the supervised machine learning camp where there is a lot of labeled data available: malware detection (telling benign binaries from malware), malware classification (attributing malware to some malware family), document and Web site classification, document analysis, and natural language understanding  for phishing and BEC detection. There is some early but promising work being done on graph (or social network) analytics for communication analysis. But you need a lot of data and contextual information that is not easy to get your hands on. Then, there are a couple of companies that are using belief networks to model expert knowledge, for example, for event triage or insider threat detection. But unfortunately, these companies are a dime a dozen.

That leads us into the next question: What are the top use-cases for AI in security?

I am personally excited about a couple of areas that I think are showing quite some promise to advance the cyber security efforts:

1. Using NLP and NLU to understand people’s email habits to then identify malicious activity (BEC, phishing, etc). Initially we have tried to run sentiment analysis on messaging data, but we quickly realized we should leave that to analyzing tweets for brand sentiment and avoid making human (or phishing) behavior judgements. It’s a bit too early for that. But there are some successes in topic modeling, token classification of things like account numbers, and even looking at the use of language.
2. Leveraging graph analytics to map out data movement and data lineage to learn when exfiltration or malicious data modifications are occurring. This topic is not researched well yet and I am not aware of any company or product that does this well just yet. It’s a hard problem on many layers, from data collection to deduplication and interpretation. But that’s also what makes this research interesting.

Given the above it doesn’t look like we have made a lot of progress in AI for security. Why is that? I’d attribute it to a few things:

1. Access to training data. Any hypothesis we come up with, we have to test and validate. Without data that’s hard to do. We need complex data sets that are showing user interactions across applications, their data, and cloud apps, along with contextual information about the users and their data. This kind of data is hard to get, especially with privacy concerns and regulations like GDPR putting more scrutiny on processes around research work.
2. A lack of engineers that understand data science and security. We need security experts with a lot of experience to work on these problems. When I say security experts, these are people that have a deep understand (and hands-on experience) of operating systems and applications, networking and cloud infrastructures. It’s unlikely to find these experts who also have data science chops. Pairing them with data scientists helps, but there is a lot that gets lost in their communications.
3. Research dollars. There are few companies that are doing real security research. Take a larger security firm. They might do malware research, but how many of them have actual data science teams that are researching novel approaches? Microsoft has a few great researchers working on relevant problems. Bank of America has an effort to fund academia to work on pressing problems for them. But that work generally doesn’t see the light of day within your off the shelf security products. Generally, security vendors don’t invest in research that is not directly related to their products. And if they do, they want to see fairly quick turn arounds. That’s where startups can fill the gaps. Their challenge is to make their approaches scalable. Meaning not just scale to a lot of data, but also being relevant in a variety of customer environments with dozens of diverging processes, applications, usage patterns, etc. This then comes full circle with the data problem. You need data from a variety of different environments to establish hypotheses and test your approaches.

Is there anything that the security buyer should be doing differently to incentivize security vendors to do better in AI?

I don’t think the security buyer is to blame for anything. The buyer shouldn’t have to know anything about how security products work. The products should do what they claim they do and do that well. I think that’s one of the mortal sins of the security industry: building products that are too complex. As Ron Rivest said on a panel the other day: “Complexity is the enemy of security”.

Also have a look at the VentureBeat article feating some quotes from me.

This post is about capturing my talking points from the recent conference panel on the “Use of AI for Cybersecurity” at the Intelligence and National Security Alliance (INSA) conference. You can find my musings on the term AI in my previous blog post.

Here is the list of topics I injected into the panel conversation:

• Algorithms (AI) are Dangerous
• Privacy by Design
• Expert Knowledge over algorithms
• The need for a Security Paradigm Shift
• Efficacy in AI is non existent
• The need for learning how to work interdisciplinary

Please not that I am following in the vein of the conference and I won’t define specifically what I mean by “AI”. Have a look at my older blog posts for further opinions. Following are some elaborations on the different topics:

• Algorithms (AI) are Dangerous – We allow software engineers to use algorithms (libraries) for which they do not know what results are produced. There is no oversight demand – imagine the wrong algorithms being used to control any industrial control systems. Also realize that it’s not about using the next innovation in algorithms. When DeepLearning entered the arena, everyone tried to use it for their problems. Guess what; barely any problem could be solved by it. It’s not about the next algorithms. It’s about how these algorithms are used. The process around them. Interestingly enough, one of the most pressing and oldest problems that every CISO today is still wrestling with is ‘visibility’. Visibility into what devices and users are on a network. That has nothing to do with AI. It’s a simple engineering problem and we still haven’t solved it.
• Privacy by Design – The entire conference day didn’t talk enough about this. In a perfect world, our personal data would never leave us. As soon as we give information away it’s exposed and it can / and probably will be abused. How do we build such systems?
• Expert Knowledge – is still more important than algorithms. We have this illusion that AI (whatever that is), will solve our problems by analyzing data with the use of software systems that work with a cloud based database. Instead of using “AI” to augment human capabilities. In addition, we need experts who really understand the problems. Domain experts. Security experts. People with experience to help us build better systems.
• Security Paradigm Shift – We have been doing security the wrong way. For two decade we have engaged in the security cat and mouse game. We need to break out of that. Only an approach of understanding behaviors can get us there.
• Efficacy – There are no approaches to describing how well an AI system works. Is my system better than someone else’s? How do we measure these things?
• Interdisciplinary Collaboration – As highlighted in my ‘expert point’ above; we need to focus on people. And especially on domain experts. We need multi-disciplinary teams. Psychologists, counter intelligence people, security analysts, systems engineers, etc. to collaborate in order to help us come up with solutions to combat security issues. There are dozens of challenges with these teams. Even just something as simple as terminology or a common understanding of the goals pursued. And this is not security specific. Every area has this problem.

The following was a fairly interesting thing that was mentioned during one of the other conference panels. This is a “non verbatum” quote:

AI is one of the poster children of bipartisanship. Ever want to drive bipartisanship? Engage on an initiative with a common economical enemy called China.

Oh, and just so I have written proof when it comes to it: China will win the race on AI! Contrary to some of the other panels. Why? Let me list just four thoughts:

1. No privacy laws or ethical barriers holding back any technology development
2. Availability of lots of cheap, and many of them, very sophisticated resources
3. The already existing vast and incredibly rich amount of data and experiences collected; from facial recognition to human interactions with social currencies
4. A government that controls industry

I am not saying any of the above are good or bad. I am just listing arguments.

:wq