In the last two MDR posts, I looked at how MDR has to move beyond alert triage. First, the natural MDR extensions: asset and control coverage, exposure management, SIEM and data quality, cloud and identity posture, response orchestration, and proof that risk actually went down. Then, the deeper architecture: next-gen MDR as an AI-native SecOps control plane, where services become more productized, SIEM becomes symbiotic, and detection has to move into governed response.

This post is the next layer out.

Most conversations around AI in the MSP ecosystem still focus on copilots, workflow automation, and operational efficiency. Those are important, but they miss the larger transition underway. AI is forcing a redesign of the operational infrastructure underneath managed services itself, creating new platform dynamics and potentially large capital market opportunities across the SMB technology stack.

If MDR is becoming an AI-native SecOps control plane, what happens to the broader MSP market? My view is that the same operating shift is coming there too, but with a wider scope. The best MSPs will not just add AI to tickets, service desks, and support workflows. They may become the AI operations layer for SMB and mid-market infrastructure. That is a much bigger idea than “AI for MSPs.”

Services Are Becoming Software-Defined

Historically, software scaled and services did not. Services were people-heavy, exception-heavy, and hard to standardize. Good MSPs could improve process, stack discipline, and technician leverage, but the model still depended heavily on human execution.

AI changes part of that equation.

Support, remediation, governance, workflow routing, escalation, documentation, compliance evidence, and customer reporting can all become more software-defined. That does not eliminate the human operator. It changes the operator’s job from doing every step manually to designing, supervising, validating, and improving the operating loop.

This is why the boundaries between MSP, MDR, SaaS, outsourcing, and consulting start to blur. A managed service that is telemetry-driven, API-connected, AI-assisted, and outcome-accountable begins to look less like a traditional services business and more like an operating platform with humans in the loop.

MDR is one version of this. MSP is the broader version.

Copilot Is Not The End State

A lot of current AI messaging still sounds like copilot: summarize a ticket, draft a response, help an analyst investigate faster, recommend the next step, generate a report. That is useful, but it is not the final state. The customer is not really buying a better chat interface. They are trying to buy operational confidence.

For MSPs and MDR providers, the value stack is moving in this direction:

This is where MSP and MDR converge. The customer does not want a PSA queue, RMM console, SIEM, EDR tool, dashboard, or pile of alerts. They want uptime, resilience, recoverability, compliance, secure productivity, fewer surprises, and someone accountable when the system does not behave the way it should. The product becomes operational confidence.

The Hard Part Is Operational State

This is also where a lot of “AI-first MSP” thinking is still too shallow. The hard part is not putting an LLM on top of a ticket queue. The hard part is knowing enough about the operating environment to take action safely. To automate IT and security operations, the system needs to know what exists, who owns it, what it connects to, what is business-critical, what policy applies, what telemetry is missing, what action is allowed, what could break, who can approve, how to roll back, and whether the action worked.

That requires an operational middleware layer:

This should sound familiar from the MDR discussion. The same architecture problems show up again: context, telemetry, workflow, policy, action, proof. The difference is that MSPs operate across a wider surface area. They touch endpoint management, identity, SaaS administration, backup, patching, compliance workflows, help desk, procurement, user onboarding, security tooling, and business continuity. That makes the AI opportunity larger, but it also makes the operating problem harder.

This is also why I am a proud advisor to FlowMind. They are tackling this problem from exactly the right angle: building a context graph across IT, network, cloud, and security knowledge, then using that context to automate ticket triage, investigation, and response. The important part is not just classifying the ticket faster. It is understanding the live customer environment well enough to recommend or execute the right fix.

AI-First MSP Is A Refounding, Not A Feature Upgrade

The phrase “AI-first MSP” can make the transition sound easier than it is. A true AI-native provider probably needs a different labor model, pricing model, knowledge system, telemetry stack, escalation chain, customer contract, operating metric set, and governance architecture. That is closer to a refounding than a modernization project.

The old MSP model optimized for human leverage: more endpoints per technician, better ticket workflows, tighter vendor standardization, and stronger recurring revenue. The next model has to optimize for governed automation: more safe actions per operator, better telemetry coverage, faster remediation loops, clearer authority boundaries, and stronger proof of outcome.

That also changes what investors and strategic acquirers should underwrite. Scale alone is not enough. Recurring revenue alone is not enough. A large MSP platform with fragmented tools, weak data architecture, inconsistent telemetry, and human-heavy workflows may not be an AI-native operating platform. It may just be a large labor organization with good retention.

The quality question becomes more operational: can this provider turn distribution, trust, and access into a compounding operating system?

The Practical Test

The test is not “does this MSP have AI?” That question is already too shallow. The better test is whether the provider can answer a few operating questions consistently:

This is where diligence should move. Not just gross retention, endpoint count, technician utilization, or EBITDA margin, but whether the operating architecture is actually becoming more software-defined over time.

Distribution Is The Hidden Asset

The strongest strategic asset in the MSP market may not be the software stack. It may be the distribution layer.

MSPs already have something most AI vendors want and cannot easily build: trusted access into the SMB technology environment. They often have admin rights, endpoint access, SaaS integrations, procurement influence, business continuity responsibility, and a working relationship with the customer. That matters because SMBs generally do not have the internal capacity to manage AI transformation, AI governance, security operations, identity, SaaS posture, and workflow automation on their own. If AI agents become part of the workforce, somebody has to manage the operating environment around them. Identity, permissions, logging, workflow access, data boundaries, compliance, security, and incident response all have to extend from human employees to semi-autonomous systems.

That creates a larger role for the best MSPs and MDR providers. They can become SMB operational governance providers, not just outsourced IT or security teams.

The Market Will Not Reward Everyone

The dangerous assumption is that AI automatically increases the value of MSPs. It might. But it could also compress margins, reduce switching costs, commoditize service delivery, centralize operational intelligence in large platforms, and move value toward Microsoft, hyperscalers, or AI-native software vendors. The providers that benefit most will be the ones that turn service delivery into a software-defined operating model. The providers that only add AI features to the old model may see the opposite effect: more pricing pressure, less differentiation, and less tolerance for messy delivery. This is the broader implication of the AI-native MDR thesis. MDR may become the SecOps control plane. MSPs may become the operations and governance layer for the rest of the SMB technology stack.

The categories may keep their old names for a while: MSP, MDR, MSSP, SaaS, GSI, AI SOC. But the operating model underneath them is changing. The strategic question is no longer just who manages the tools. It is who becomes trusted to operate the customer environment as AI becomes part of the workforce.

MDR is not going away, but the old model is. The old model was service-first: collect alerts, have analysts investigate them, escalate what matters, and report what happened. That still solves a real problem, but it is not where the market is going.

The future MDR has to become product-first, AI-native, and action-oriented. It cannot just sit on top of EDR alerts and add analyst labor. It has to become the SecOps control plane that connects detection, investigation, response, exposure reduction, and proof of outcome.

This is not just an “AI layer” on top of alerts. It requires a different architecture, a different relationship with the SIEM, and a different operating model for response.

The Service Business Has To Become A Product Company

Traditional MDR was built as a service business. The product was often the people: analysts, playbooks, escalations, customer calls, and reporting. That model can scale to a point, but it starts to break when the market expects software-speed investigation and response.

Next-gen MDR has to invert the model. The platform becomes the core product, and services become the trust, expertise, and exception-handling layer around it. The test is margin and labor leverage. If more customers create more exceptions, more tuning, and more analyst burden, the company is still a service business. If more customers create more reusable detections, known-good patterns, automation recipes, and response policies, the service is becoming a product. Analysts still matter, but they should supervise, improve, validate, and handle edge cases. They should not be the primary execution engine for every repetitive investigation.

That is a hard transition because many MDR providers are not software companies. They can script, tune, and operationalize, but building a real SecOps platform is a different muscle.

The Moat Is Not AI. It Is Encoded Operational Judgment.

The defensible part of next-gen MDR is not that it uses AI. Everyone will use AI. The defensible part is whether the provider has converted years of SOC judgment into productized decision systems: known-good behavior, investigation procedures, response playbooks, customer-specific rules of engagement, approval policies, and feedback loops that improve the platform over time.

The best MDR providers will not simply have analysts assisted by AI. They will have a compounding operating system where every resolved case can improve future triage, investigation, automation, and response across customers. The weak version is service history trapped in analyst memory and exception lists. The strong version is structured, versioned, measurable operational knowledge embedded into the platform.

And let’s not forget the context graph. The data structure that learns the customer environments. The intelligence layer that fuses together individual data points to deliver a high signal, low friction security outcome.

MDR And SIEM Become Symbiotic

It’s a mistake think (or build a company around) next-gen MDR replaces the SIEM.

The SIEM is there for a reason. It stores logs, supports compliance retention, enables historical search, runs detections, and gives the customer a system of record for security data. Many customers already have years of detection logic, parsers, dashboards, and workflows inside it.

But the SIEM should not be the only operating layer for MDR. If MDR depends entirely on the (customer’s) SIEM, it inherits the SIEM’s latency, schema problems, data opacity, cost model, and workflow limitations.

The future relationship is symbiotic. MDR should use the SIEM’s detection layer where it works, but also audit it, monitor it, and improve it. Are the right logs arriving? Are detections still firing correctly? Are parsers broken? Are detections duplicated, stale, or missing context? Which investigation outcomes should feed back into detection logic?

In that model, the SIEM becomes less of the SOC’s user interface and more of a data and detection layer inside a broader SecOps operating system. It’s also feasible to have the SIEM be the data backend for the AI SOC, but only if it’s under the uninhibited control of the MDR.

AI Changes The Architecture, Not Just The Interface

The visible change in the near future is that analysts and customers will interact with the system(s) through AI. They will ask questions, start investigations, summarize cases, generate response plans, even design their own dashboards, and check what changed.

But the harder shift is underneath. The backend has to be built so AI can interact with it safely and efficiently. That means the platform needs clean APIs, stable entity models, permission-aware access, auditable actions, reusable investigation workflows, and compact context that does not require dumping endless raw logs into a model. And last but not least, the backend has to be designed for AI workloads and in turn, for token efficiency and for the types of (probably very suboptimal) queries that the AIs will send down.

This is why an AI-native SecOps platform is not the same as a chatbot on top of a SIEM. The architecture has to support the way AI investigates, acts, remembers, and learns.

Detection Has To Move Into Automated Response

The current MDR model still assumes a human-centered response loop: a detection fires, an analyst investigates, and someone decides whether to isolate, disable, block, remove, patch, ticket, or escalate. That loop is too slow for many modern attacks.

The future MDR platform has to move toward detection-to-response automation, but not reckless automation. Customers will push back, and rightly so. They do not want an opaque AI system taking production-impacting actions on its own. The answer is to be precise about what “AI” means.

Not every workflow needs an LLM. Much of response should become deterministic rules, policy engines, and pre-approved playbooks. GenAI should be reserved for the places where it helps: summarization, investigation planning, evidence interpretation, query generation, and edge-case reasoning. For most alerts, the system should be predictable, auditable, and constrained.

The second answer is supervision. Some actions can be fully automated. Some should require analyst approval. Some should require customer approval. The platform has to know the difference between removing a malicious email, disabling a privileged identity, isolating a production server, and changing access policy for a sensitive application.

The third answer is guardrails. We are entering the era of validation loops for AI: agents and control layers that check what the system proposes, understand disruption risk, enforce policy boundaries, and monitor whether the action worked. Formal guardrail frameworks, policy-as-code, approval gates, rollback paths, evals, and audit trails become part of the SecOps architecture.

This is where risk becomes the control signal. A suspicious event on a low-value test asset should not trigger the same response as the same event on a privileged identity accessing sensitive data. Risk should influence not only the analyst queue, but also resource access flows: step-up authentication, zero trust enforcement, restricted data access, endpoint isolation, email removal, identity reset, or escalation to a human.

That is the important shift. Detection should not only create an investigation. It should drive protection and exposure reduction.

The Market Implication

Next-gen MDR, AI SOC, and the MSP/MSSP security platform may look like separate markets today. Architecturally, they are converging. The packaging changes by segment, but the platform direction is increasingly the same.

Enterprise buyers will usually want to retain ownership of security operations. They may use managed expertise, but they are more likely to buy an AI-native SecOps platform that compresses L1/L2 investigation, improves consistency, and accelerates response while their internal team keeps control of higher-risk decisions. There is an opportunity for AI SOC players to provide the new sec ops platform for these enterprises as the central command – AI first, SIEM symbiotic.

Mid-market buyers are the most interesting and the most difficult. They often have enough security maturity to know they need help, but not enough staff or process maturity to run a pure platform themselves. This is where productized MDR can become the managed SecOps control plane: part platform, part expert service, part automation layer. The provider has to help operate the loop, not just forward alerts. The lesson is not to bolt on every adjacent service. Exposure management, asset visibility, identity posture, vulnerability prioritization, and response orchestration all matter, but they have to reinforce the MDR operating loop. If the provider adds too much service scope without product leverage, it becomes broad, expensive, and hard to deliver. This is also where we need the vendors to educate the market. Mid-market companies need these capabilities whether they ask for them or not. If they are buying separate tools for exposure management, asset inventory, vulnerability management, identity posture, and reporting, it is reasonable to ask why the MDR provider should not help operate those workflows. The customer can still supervise decisions, set policy, and approve sensitive actions. But the MDR should increasingly coordinate the operating loop. Ideally MDR players will open up their platforms for end customers to co-deliver security results.

SMB buyers may never experience this as an AI SOC platform. They may experience it through an MSP or MSSP security platform that bundles endpoint, email, identity, compliance, patching, response, and reporting all within one simple, per user license. But underneath, the same direction applies: more product, more automation, more risk context, more proof.

The future MDR is not an AI layer on top of alerts. It is not a cheaper SOC. It is not a duplicate SIEM. And it is not a service desk with better automation. The future MDR is a productized SecOps control plane: symbiotic with the SIEM, directly integrated with the customer’s enforcement tools, risk-aware in how it prioritizes and responds, deterministic where safety matters, AI-native where reasoning helps, and measured by proof of risk reduction. The companies that win will be the ones that turn service experience into compounding product advantage. The companies that lose will still have analysts, alerts, dashboards, and AI summaries, but no real moat.

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.

During my engagements with various Private Equity and Venture Capital outlets, I see a clear shift. The questions that is showing up more and more in due diligence is no longer, “What is your AI strategy?”

It is: “How far along are you in rebuilding the company around AI?”

That is a different question.

It applies to startups and incumbents alike. It applies to security companies, SaaS vendors, MSPs, and a lot of businesses outside those markets too. The point is no longer to add a few AI features, automate one workflow, or give employees access to a chatbot. The point is to rethink how the company actually operates.

AI Should Sit Under Every Corporate Function

The companies that will look strongest over the next few years are the ones treating AI as an operating system layer across the business.

That means product development, service delivery, sales and marketing, customer success, and finance and operations are all being reworked with AI in mind. Not as separate experiments, but as connected systems.

The important shift is not “where can we use AI?” It is “how should this function work if AI is built into the process from the start?”

That usually leads to a broader redesign. Workflows get compressed. Handoffs change. Data gets linked across teams. Software that used to just record tasks between humans starts becoming an orchestration layer between people and AI agents.

AI on Top Is Not Enough

Most companies are still treating AI like a feature layer. They add a copilot. They automate a few tasks. They run a few pilots in sales or support. Then they talk as if they have become an AI company. They have not.

If AI is going to matter as much as people claim, then it cannot live in isolated tools and side projects. It has to sit underneath the company as an operating layer. Product, service delivery, sales, marketing, customer success, finance, and operations all need to be rethought with AI built in from the start.

That is the real shift. Not AI as garnish. AI as infrastructure.

In practice, this means a company’s core operating logic can no longer live in forgotten decks, static docs, and tribal memory. Vision, mission, strategic priorities, ICP, and go-to-market motions need to be embedded into the AI layer itself so teams can interact with them in daily work (literally let them chat with these pieces of information via Slack!). The system should be able to explain the strategy, test whether execution matches it, and keep the company aligned as it changes. If that layer does not exist, most companies are still operating on fragments.

This Is Now a Capital Question

This is also why the conversation is changing in private equity and VC diligence.

We are not just looking for AI messaging anymore. We are looking for evidence that the operating model is changing. Is the company shipping faster? Is service delivery getting more leverage? Are teams linked better? Is software being used to orchestrate work between humans and AI agents rather than just record tasks? Is management actually rebuilding the business, or are they still presenting AI as an add-on?

Those questions now matter directly to competitiveness.

A company that keeps the old operating model and bolts AI on top will lose to one that rebuilds around it properly. The latter will move faster, learn faster, and eventually operate at a different level of efficiency.

The Companies That Wait Will Pay For It

I think this is becoming a funding imperative.

Before raising capital, before pursuing a sale, and before the board forces the discussion, management teams need to be doing the hard work of redesigning the company around AI.

Because the market is not going to wait for slow adopters to get comfortable. The companies that embrace AI as a true operating layer will look more scalable, more durable, and more investable. The ones that do not will increasingly look like they are running yesterday’s model in a market that has already moved on.

“AI lowers execution cost, not accountability. SMBs outsource accountability.”

It will affect SMB customers, the MSPs serving them, and the software vendors selling into the channel. Those are three different layers, and the impact on each one is different.

SMBs Still Do Not Want To Own the Problem

One concern is that AI makes knowledge cheaper and tooling easier, so SMBs may decide to manage more of their own IT.

I do not think that is the main outcome.

Most SMBs do not hire an MSP because they cannot access software or information. They hire an MSP because they do not want to own the problem. They want someone else to choose the tools, deploy them, keep them running, support users, stay current, and deal with issues when something breaks.

AI may make parts of IT easier. It does not remove the need for responsibility. That is why I think AI is unlikely to reduce the need for MSPs in any dramatic way.

MSPs Get More Leverage

Inside the MSP, the impact is more direct.

A lot of the work is repetitive: triage, ticket handling, investigation, internal knowledge lookup, and workflow coordination across too many systems. AI can improve all of that.

That does not mean the MSP becomes irrelevant. It means the MSP becomes more efficient.

A smaller team may be able to support more customers, resolve more issues, and operate with fewer manual steps. In security especially, where talent is scarce, that matters a lot. The near-term effect of AI on MSPs is not disintermediation. It is better leverage, better scale, and a different labor model.

MSP Software Vendors Face the Real Reset

The most interesting pressure may land on the MSP software vendors.

The issue is not whether they can add AI features. They all will. The real issue is whether they can get on the AI coding wagon fast enough and turn that into much faster product development.

AI-native development practices will increase the amount of software the market can produce. More gets built. Iteration cycles get shorter. Focused startups can come in faster. And incumbents lose some of the advantage that came from simply being large, embedded platforms.

That is where the moving-fast disadvantage shows up.

Big vendors carry legacy code, older architectures, complex customer requirements, and years of accumulated product sprawl. It is much harder for them to become truly AI-first development organizations than it is for a newer company starting fresh. There is a big difference between developers occasionally using AI and a company rebuilding product, engineering, testing, and delivery around AI-assisted speed.

If incumbents make that shift well, they will benefit enormously. If they do not, AI will not just improve their products. It will make newer competitors much more dangerous.

What Changes From Here

My current view is simple.

AI is probably a tailwind for MSP demand. It is clearly a lever for MSP efficiency. But it may be most disruptive to the software vendors serving the market, because it changes the speed of product development and lowers the barrier for new entrants.

MSPs are not going away. But the basis of competition is changing.

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.

Security has always moved in waves. Not because we suddenly get smarter, but because we learn from past mistakes, identify gaps, hit limits, need to protect new technologies, and then go and do our best to solve those new security challenges with the technologies at hand.

The era of AI (let’s be clear, we have had AI for a long time; what I mean specifically is the advent of Large Language Models) has shifted many industries, but specifically security in a particularly revealing way. AI did not just give us new tools to solve security problems. It invited innovators and entrepreneurs to revisit pretty much every security technology to see if LLMs could be useful to address some of the existing challenges. But that’s not where things stopped. More interestingly, some teams used this moment to question whether the underlying approaches themselves still made sense at all. Not just whether LLMs could help, but whether modern data architectures, different telemetry choices, and different enforcement models could fundamentally change outcomes.

That is what has triggered a real wave of new companies in cyber, including across markets that many considered mature, or even stagnant, like SIEM.

The Five Phases We Just Lived Through

Let’s take a non-scientific look at how major security approaches evolved over the past 25 years. This is not exhaustive, but it helps explain where we are today.

1. Network-Centric Prevention

Back, many moons ago, we started with firewalls, IDS, and later IPS. The model was simple. Look at packets. Stop bad things. It worked until attackers learned to look normal.

2. More Data, Centralized, Higher-Level Insights

When network telemetry created too many false positives, we added vulnerability data and authentication events and fed them into a SIEM to correlate. The results were “mixed”. Fortunately for the SIEM market, compliance and audit requirements emerged, mandating long-term log retention. This gave SIEM a durable justification, even when its security value was debated. SIEM became indispensable for visibility and forensics, but increasingly disconnected from real-time decision making.

3. Back to Prevention and Response

As SIEM alert volumes exploded and analysts could not keep up, the industry pivoted. EDR. NDR. SOAR. We all know how that played out. NDR never truly broke out. EDR became a major category. SOAR largely collapsed back into SIEM. And eventually, most large EDR vendors added a SIEM to their portfolio.

This was not convergence by design. It was convergence driven by operational gravity.

4. AI Triggers a Reality Check

LLMs made many believe they could simply layer AI on top of broken architectures. Some startups did exactly that. They will likely not be the long-term winners.

The more interesting group of companies used AI as a forcing function to re-examine first principles. What data actually matters? What can realistically be prevented at the edge? What must still be correlated centrally? What is structurally broken in SOC workflows? Where have we been compensating for bad architecture with human labor? Crucially, many of these answers have little to do with LLMs themselves, and much more to do with data fidelity, placement of control, and modern system design.
This is where the real innovation is happening.

5. The Convergence

We are now in a phase where prevention is moving back to the edge, while analytics and orchestration remain central. Endpoints are smarter. Browsers are instrumented. Networks are being re-observed. Context is finally treated as a first-class input.

But there is still a SOC. There is still a central nervous system that correlates, reconstructs, explains, orchestrates, and proves what happened. Call it SIEM, security analytics, XDR, or AI SOC. The name is irrelevant. The function is not.

In parallel, we are realizing that we can push enforcement / prevention back to the edge. Wherever we have enough information, execute at the edge. Where we don’t, call out to your central nervous system. To your brain. The brain (your SIEM) that understands at any moment in time, what the risk and function is of every entity in your network. And use that information for decision making.

Why AI SOC Will Collapse Back Into SIEM

Many startups brand themselves as “AI SOC”. What do they actually do?

They primarily ingest alerts from EDR, NDR, SIEMs, and cloud platforms, then attempt to determine which ones matter. They add context, apply behavioral analysis, and suppress false positives.

In other words, they attempt to do what SIEM, UEBA, and SOAR were always supposed to do, just with better math and more compute. However, there is one problem. Many of the AI SOC contenders operate on alert streams. That means they start from already lossy, opinionated data. Real behavioral analysis does not on top of alert streams. It lives in raw telemetry. Email flows. Network sessions. Browser actions. Endpoint system behavior.

Once an AI SOC platform decides to ingest that raw data directly, it immediately recreates the ingestion, normalization, storage, and correlation problems that SIEM already exists to solve. At that point, the separation no longer makes sense. This is exactly why UEBA and SOAR collapsed back into SIEM. And it is why AI SOC will do the same.

There will be one place where data is reconciled, correlated, and turned into decisions. That place will increasingly run on federated, near-real-time architectures rather than twenty-year-old indexing engines. But their function remains the same. Call it whatever you want. It needs to be one system, not many and it doesn’t care what you call it.

The Shift Is Not Just Technical. It Is Organizational.

What is interesting to note about these new entrants in the SIEM or security analytics space is not just their security architecture. It is the company architecture. Modern security startups are being built on AI-native operating systems: Sales calls are captured and analyzed, not just by sales, but product teams mine them for competitive signals, marketing uses them to refine messaging, engineering uses them to prioritize roadmaps. This is not a tooling upgrade. It is a fundamentally different operating model.

Imagine a system where the vision, mission, strategy, and priorities are centrally maintained, updated and codified. Every function consumes that shared intelligence to drive decisions, messaging, and execution. This does not just improve alignment. It dramatically compresses learning cycles and execution speed. And that, more than any individual feature, may be the hardest thing for incumbents to replicate.