For the last several months, I have been arguing that the boundaries between SIEM, AI SOC, security data infrastructure, and MDR are starting to collapse.

In March, I wrote that data pipelines had become the Trojan horse into the SIEM. In May, I argued that next-generation MDR had to become an AI-native SecOps control plane, not just a service wrapped around alerts.

The last two weeks have made those ideas look less theoretical. Vendors are now executing against them.

The Product Categories Are Converging

Microsoft announced ISOC in Defender, bringing SIEM and threat protection together around signals, context, agents, and response controls. This is more than another Copilot feature. Microsoft is trying to make the platform itself the integrated operating system for an agentic SOC.

Cribl launched Cribl Detect, moving directly from telemetry pipelines and data control into the SIEM market. This is exactly the progression I expected: first own the data path, then add search, detection, investigation, and response. Once a vendor controls how security data moves, it has a credible path toward owning more of the security brain.

Vega II combines a cyber-defense model, persistent memory, and access to data across lakes, object storage, SaaS tools, and legacy SIEMs. The important part is not the model alone. It is the harness around the model: context, memory, data access, human direction, and approval before consequential action.

Scanner is pushing federated indexing as an answer to the tradeoff between expensive SIEM ingestion and slow federated search. The idea is to leave raw data in its existing system of record while creating a compact index that can support fast investigation and continuous detection. Again, the direction is the same: cheaper access to more telemetry without forcing everything into one monolithic SIEM. I won’t go into the details of where federation won’t work, but it’s significant and this is not the solution to your storage problems.

TENEX is working with NVIDIA’s Open Agent Safety Platform to evaluate stronger runtime boundaries for security agents and to turn agent allow-and-deny activity into SOC evidence. That points to the next control layer. It is not enough for an agent to reach a conclusion. The system needs to govern what the agent is allowed to do, record what happened, and help operators understand why.

These are not five unrelated announcements. They are five versions of the same market movement. The new competitive surface is the full loop: data, context, detection, investigation, memory, policy, and action.

MDR Is Still Hard To Build And Hard To Value

The other important signal came from the services side. Quorum Cyber signed an agreement to acquire Ontinue, bringing together two Microsoft-focused security providers. Ontinue has more than 250 customers and had approximately doubled in scale under EQT, while building a strong story around an AI-powered MXDR platform. Financial terms were not disclosed.

My understanding is that the transaction valued Ontinue at roughly 2–2.5 times revenue. That is not necessarily a bad outcome, but it is also not a software multiple. It reflects how difficult MDR businesses can be to value.

MDR providers are normally valued more like managed services businesses, where EBITDA matters. The challenge is that many MDRs do not generate especially high EBITDA margins. Twenty-four-hour delivery, analyst staffing, customer-specific onboarding, detection tuning, incident escalation, and a growing number of exceptions all consume people. Recurring revenue helps, but revenue quality depends heavily on how much human effort is still required to deliver it.

This is where AI SOC capabilities and better operational software, products, and platforms become economically important. AI creates real value when investigations, customer context, detections, response policies, and operating knowledge become reusable product assets. If the platform lets the provider support more customers without proportional growth in analysts and exceptions, margins can expand and the valuation framework can begin to change. If not, the AI story is mostly positioning wrapped around the same services model. 80% margin is where the gold standard seems to calibrate.

The second opportunity is to expand what the customer is actually buying. I have argued in my previous MDR posts that the category has to move beyond alert triage and incident response into continuous risk reduction. That means helping customers understand what assets exist, where controls and telemetry are missing, which exposures matter, what should be remediated, whether the action happened, and whether risk actually went down.

That is not simply adding more services around MDR. It changes the role of the provider from outsourced alert handling to an operating control plane for security outcomes. It can increase wallet share, deepen the customer relationship, create more differentiated data and workflows, and make the platform harder to replace. More importantly, it gives the provider something more valuable to sell than analyst capacity. You’ll ask, isn’t that called an MSSP? Well, MDR’s might just have to deal with that.

Seen through that lens, a 2–2.5 times revenue outcome is an important market signal. The market is not going to award software-like value because an MDR provider uses AI or calls itself an agentic SOC. The provider has to prove two things: that its operating model gains real software leverage, and that its product can expand from processing alerts into reducing customer risk.

The Market Is Showing Us Where Value Will Accrue

The direction is becoming clearer.

Incumbents are pulling agentic workflows into integrated platforms. Data infrastructure vendors are moving upward into detection and SIEM. AI SOC startups are expanding downward into data access, memory, and control. MDR providers are consolidating and trying to turn delivery experience into product leverage and broader risk-reduction platforms.

The categories will keep their old names for a while, but the value is moving toward whoever can own the compounding control points: trusted data, operating context, detection quality, governed action, and the feedback loop that makes the system better after every investigation. And, again, a move to risk reduction and proactive security.

The market is no longer just talking about the agentic SOC. It is starting to build it.

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.

I have argued for a while that MDR has to move beyond alert triage and become a cyber risk reduction service. A recent conversation with an experienced MDR operator added another piece to that thesis. The future may not be one ever-expanding MDR bundle. We may be forcing three different jobs into one category:

1. managing the security data and detection foundation
2. operating the detection and response workflow; and
3. proactively reducing risk.

The second is the MDR service we know today. The third is where I believe MDR ultimately has to go. But the first may be a new service category of its own: the managed security data fabric.

TL;DR

These layers can be sold together, but they do not have to be. An enterprise may want to keep its own SOC while outsourcing the data and detection foundation underneath it. Another company may want a full MDR service. A third may need help driving remediation and proving that its exposure actually went down.

That creates a more flexible model than trying to sell every customer the same MDR bundle.

The Missing Service Under The SOC

Most security teams have a SIEM, data lake, EDR platform, or some combination of the three. Many also have an MDR provider. Yet it is often unclear who owns the quality of the security data layer end to end.

The SIEM vendor provides the product and does not manage the customer’s entire data environment. The MDR provider consumes the data it needs to deliver its service. Internal platform teams keep pipelines running. Detection engineers maintain content. Threat intelligence is purchased from several sources. Asset, identity, cloud, and business context live in still more systems. In smaller environments, an MSSP might own the entire chain, but at what quality and what depth? Do they really understand what assets are used for what purpose, understand infrastructure changes, escalation points, etc?

Everybody owns a piece. Nobody necessarily owns whether the complete foundation is accurate, current, cost-effective, and usable.

A managed security data fabric would take responsibility for that foundation. It could:

• onboard, route, store, and monitor security telemetry (logs)
• normalize schemas and reconcile duplicate or conflicting entities (by the way, ask your SIEM vendor about this)
• maintain asset, identity, cloud, control, and business context
• curate and operationalize threat intelligence
• build, test, tune, and update detection content
• identify missing telemetry and broken detection coverage
• optimize storage, query, and AI consumption costs
• expose trusted context to SIEMs, data lakes, internal applications, and AI agents

This is not just co-managed SIEM under another name. A co-managed SIEM service usually starts with the SIEM as the center of gravity. A managed security data fabric starts with the information and context the security operating model needs, then serves that foundation into whichever SIEM, analytics platform, workflow, or agent the customer chooses.

It also does not have to operate the SOC. It may generate detections, but it does not necessarily triage every alert. It can maintain detection quality without owning 24/7 monitoring, threat hunting, incident investigation, or response.

That boundary is what makes it a distinct service.

Why AI Makes The Data Layer More Important

AI SOC products initially focused on the visible labor problem: too many alerts and too much analyst time spent investigating them. That produced a clear economic pitch. If an agent can resolve a large percentage of alerts, an MDR provider or internal SOC can reduce cost.

But AI does not remove the underlying data problem. In some cases, it makes it more obvious. And that’s another reason supporting the introduction of a managed security data frabric.

An agent that has to query five systems, interpret five schemas, reconcile conflicting records, and determine which source is authoritative may be technically impressive, but it is also expensive and difficult to govern. Replacing telemetry parsers with agents does not eliminate complexity. It moves complexity into a less deterministic layer.

A well-managed security data fabric changes the economics. The expensive work of collection, normalization, deduplication, entity resolution, and context assembly happens before the agent starts reasoning. The agent receives a smaller, cleaner, better-structured set of information through a stable interface.

That should reduce tool calls and token consumption. More importantly, it should improve the quality and consistency of the result, ie the attacks prevented.

Context Has To Be Managed

The word “managed” matters here. Building a context graph once is not enough. Data sources change. Schemas drift. Assets appear and disappear. Identities move. Business owners change. Two systems disagree about the same endpoint. Detection logic decays as products and attacker behavior evolve.

Getting data into one place is not the hard part. Making it trustworthy over time is.

That requires ongoing operational work: resolving conflicts, validating relationships, monitoring source health, testing detections, updating intelligence, measuring coverage, and deciding which source should be authoritative for which field. Some of this can be automated. Some still requires human judgment and customer input.

This is exactly the kind of recurring, technical, difficult-to-staff function that tends to become a managed service. Are there opportunities for automation and AI? Of course, but we are far from having this all automated completely.

The Three-Service Model

Separating the layers makes the future security service stack easier to understand.

1. Managed Security Data Fabric

This service operates the substrate. Its job is to make security data complete enough, clean enough, contextual enough, and current enough for humans and machines to use.

The output is not an investigated alert. It is a trusted security operating layer that makes sure attacks don’t go undetected because of missing detections, threat intel, data sources, or configurations.

2. Managed Detection And Response

MDR consumes that substrate to operate continuous threat monitoring. It owns alert triage, investigation, threat hunting, escalation, containment, and response.

The output is not clean data. It is a threat that was detected, understood, and handled.

3. Managed Risk Reduction

The risk reduction service works further upstream. It connects asset criticality, identity, exposure, control gaps, threat activity, and remediation workflows to reduce the likelihood and/or impact of an incident.

It should identify what matters, route the required action, navigate ownership and change approvals, verify that remediation happened, and show what risk remains.

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.

In a previous post about the adjacencies to the MDR market, I laid out a framework for how MDR needs to evolve beyond alert triage. The basic idea was that future MDR should not just be “EDR alerts plus analysts.” It should become the control plane for cybersecurity operations and cyber risk reduction.

This post goes one level deeper. If MDR is going to become that control plane, what capabilities actually need to sit closest to the operating loop? The strongest extensions are the ones that help MDR understand what exists, what is exposed, what telemetry is missing, what response should happen, and whether risk actually went down.

Asset And Control Coverage

This is the starting point. MDR cannot protect an environment it does not understand, so the provider needs to know:

• What exists?
• What is unmanaged?
• What lacks EDR coverage?
• What lacks vulnerability scanning?
• What logs are missing?
• Which assets are business-critical?
• Which controls are present, absent, or failing?

Asset context turns MDR from generic alert review into prioritized operations. An alert on a test machine is not the same as an alert on a domain controller, cloud control-plane asset, payment system, build server, or executive endpoint. An exposed vulnerability on an internet-facing revenue system is not the same as the same CVE on a low-value internal host.

The future MDR has to understand this context automatically in a dynamic envirionment.

Exposure And CTEM

This is probably the most important adjacency. Classic MDR waits for something to fire. Exposure management asks what can be attacked before the alert exists.

The future MDR should know:

• What is exploitable?
• What is internet-facing?
• What is business-critical?
• What is currently being targeted?
• What attack paths exist?
• What should be fixed first?
• Which exposures actually got closed?

This is what moves MDR from reactive monitoring to proactive risk reduction. The important distinction is that this cannot just be scanner reporting. Vulnerability management becomes an MDR extension only when it is tied to exploitability, asset criticality, identity paths, observed threat activity, and actual remediation workflow.

SIEM And Data Quality

MDR is only as good as the data it can use. That makes SIEM operations and data quality core to the future model, even if the MDR provider does not own the SIEM product.

The provider should know:

• Are the right logs ingested?
• Are important sources missing?
• Are fields normalized?
• Are detections using the right data?
• Is retention sufficient?
• Is query performance good enough for investigation?
• Is SIEM cost being optimized?

This becomes more important as AI changes the interface to the SOC. If AI becomes the primary user of security data, the SIEM UI may matter less, but the quality, structure, accessibility, and completeness of the data matter more.

Cloud And Identity Posture

Modern attack paths increasingly run through identity, SaaS, cloud entitlements, workload permissions, and configuration mistakes. That means cloud and identity posture are not optional context for serious MDR.

The future MDR should understand:

• Who can access what?
• Which identities are overprivileged?
• Which accounts are risky or stale?
• Which cloud paths create attack chains?
• Which workloads are exposed?
• Which posture issues make detection or containment harder?

Without this context, MDR sees too little. It may detect a suspicious event, but miss the path that made the event possible.

Response Orchestration

The MDR has to respond faster than human-speed response, but safely. The system should be able to:

• Isolate an endpoint
• Disable or step-up an identity
• Block an indicator
• Remove malicious artifacts
• Open and route tickets
• Trigger patching or remediation workflows
• Escalate to IR
• Prove that the action happened

The word “safely” matters. MDR automation cannot become a blind SOAR playbook that breaks production. The provider needs policy, approvals, rollback paths, asset criticality, business context, and evidence that the response improved the situation.

What The Future MDR Should Prove

The old MDR output was an investigated alert. The future MDR output should be a safer environment. That changes the questions the service should answer:

• What percentage of critical assets are covered by EDR, vulnerability scanning, identity telemetry, cloud telemetry, and relevant logs?
• Which high-risk exposures were removed this month?
• Which attack paths were closed?
• Which detections improved because missing telemetry was fixed?
• Which response actions were automated safely?
• Which risks were accepted by the business?
• Which risks were remediated?
• Did measurable exposure go down?

This is the reporting layer that matters. Not activity reporting. Not “we reviewed this many alerts.” Not a dashboard that proves the provider was busy.

The stronger MDR report says: here is what exists, here is what is exposed, here is what we saw, here is what we did, here is what changed, and here is the risk that remains.

The Market Implication

The MDR market will split between alert-centric providers and control-plane providers. Alert-centric MDR can still be useful. Many buyers still need 24/7 investigation, escalation, and containment. But that model will be pressured by platform vendors, automation, and buyer expectations for more context.

The more defensible MDR provider will move upstream and downstream at the same time. Upstream, it owns asset context, control coverage, telemetry quality, exposure prioritization, cloud posture, and identity posture. Downstream, it owns containment, remediation orchestration, incident response, validation, and outcome reporting.

That is the future MDR control plane. The category may keep the same name, but the job changes from outsourced alert handling to command central for cyber risk reduction.

I will follow up on this with another MDR post to explore some topics a bit more, such as:

• The product aspect of the MDR service business
• The MDR symbiotic relationship with SIEM
• AI changing the MDR platform architecture
• Detection having to move into automated response

Stay tuned …

MDR started as a practical answer to a very real problem: customers had too many security alerts, too few security operators, and no realistic way to staff a strong 24/7 security operations center (SOC). That problem still exists. Fast investigation and response are still table stakes. But the category has to move beyond “EDR alerts plus analysts.” The MDR of the future is not just a better alert triage desk. It is the control plane for cybersecurity operations and cyber risk reduction. The winning MDR will own the loop from what assets exist, to what is exposed, to what telemetry is missing, to what detection fired, to what response should happen, to whether risk actually went down.

The Adjacency Test

In the following post I am exploring how MDR will need to evolve into the future. What adjacent markets are of importance and how can MDR solutions expand their services to help secure organizations?

The adjacency test to understand whether a use-case or product or service should be added to the original MDR service is simple: Does this capability make MDR better at preventing, detecting, prioritizing, responding, or proving risk reduction? If yes, it is a natural MDR extension. If not, it may still be a good product, but it is probably not core MDR.

With that, I’ll be using the following scale to rate various adjacent capabilities:

The Five Buckets

The future MDR stack can be organized into roughly seven buckets of use-cases that each contain multiple products or services themselves as I will outline below.

This is the shape of the future MDR control plane. The center of gravity is not just alert handling. The center is the operating loop that connects visibility, exposure, detection, response, and proof of improvement.

The Capability Map

Here is how I would expand the capabilities within each of the buckets and score them for MDR importance.

Detection & Response Core

Visibility & Data Control

Exposure & Posture

Messaging, Identity & Human Risk

Recovery & Resilience

Enforcement Surfaces

Broader Portfolio

I will let this sit here as just categories for now and will outline in a future post what questions are underlying these categories to make the MDR service more effective and what this all means for the MDR market at large.

One of the more interesting messages going into RSA was not just that AI is reshaping security. It was that the market is changing what it rewards. I had the pleasure of attending the Piper Sandler investment day on Monday at RSA, one of my favorite events where I get to catch up with many friends, meet new security leaders and get an update on the security market conditions.

The market for cyber security companies last year was easier: grow fast, expand inside the account, add modules, and let NRR do the talking. The new story looks different:

• ARR growth expectations have come down from 50% to 30%
• Gross margin expectations have moved up from 75% to 80%
• NRR expectations have come down from 120% to 115%
• GRR expectations have moved up from 88% to 92%
• Burn multiple expectations have tightened from 1.5x to <1.0x

That may sound like a generic software market shift. I do not think it is. I think it has very specific implications for AI SOC and SIEM. More about that later.

Capital markets changed first

The broader market backdrop matters. Security is still one of the more attractive areas in software, but it is being valued inside a much harder capital markets environment. The IPO window remains narrow. Liquidity for scaled assets is limited. Growth is decelerating across software. And AI is compressing valuations by making forward revenue less credible and product durability more important. That combination changes the conversation from upside to survivability.

Security is still attractive, but the bar is higher

That is why the security market now feels bifurcated. On one side, it still benefits from strong structural demand: geopolitical uncertainty, expanding attack surfaces, and AI itself creating new categories of spend. On the other side, investors are becoming much less willing to underwrite broad TAM stories, multi-year expansion narratives, or “we will grow into the model” margin profiles. Security remains attractive, but the bar is higher.

Private equity has a liquidity problem

Private equity is caught in that tension as well. Large assets are staying private longer because the public market is not offering a clean exit path. That creates pressure on hold periods, return profiles, and liquidity planning. More firms will need to create liquidity through secondaries, continuation vehicles, and other forms of fund-to-fund reshuffling rather than relying on traditional exits. That is not a theoretical issue. It shapes what kinds of assets still look financeable, what kinds of stories buyers will believe, and how aggressively firms can keep marking winners.

M&A gets more strategic from here

At the same time, strategic logic is getting stronger. Large-scale M&A should remain active because buyers still want growth, but they increasingly want growth that is accretive, platform-relevant, and commercially durable. The market is likely to reward scaled platforms, integrated environments, and assets that can either deepen data advantages or simplify the stack. It is likely to punish products that still depend on expensive customer education, loose positioning, or heroic expansion assumptions.

AI increases both risk and defensibility

AI only sharpens that divide. In security, AI is both a disruption risk and a source of defensibility. It creates fear around older architectures and weaker product moats, but it also increases the value of proprietary telemetry, embedded distribution, and control points across the enterprise. The winners are less likely to be those with the loudest AI messaging and more likely to be those with the strongest combination of data, workflow ownership, and commercial leverage.

Platformization is really about data gravity

That is also why platformization matters so much right now. This is not just a consolidation story. It is a data gravity story. The vendor that sees more telemetry, sits in more workflows, and becomes harder to dislodge can improve models faster, distribute new capabilities faster, and defend retention more effectively. In a market that now cares more about GRR, margins, and burn discipline, that matters a lot.

What this means for AI SOC and SIEM

This is where the implications for SIEM and AI SOC come into focus. The category is seeing real pressure from both sides: incumbent platforms facing pricing and architectural questions, and newer entrants offering better workflows, AI-native interfaces, and more agentic operating models. But the long-term winners may not be the vendors with the sharpest demo. They may be the ones that combine durable retention, meaningful use-cases, security outcomes, and enough platform surface area to remain central as the security stack becomes more automated and more agent-driven.

Source: Piper Sandler Keynote Deck

RSAC 2026 made one thing very clear to me: the market is moving fast, but it is still deeply confused. The big announcements from Google, Splunk, and Databricks all point in the same direction. Security operations are becoming more agentic, more API-driven, and more automated. But most of the category still looks crowded, early, and only lightly differentiated.

The interesting part is not that everybody now has an AI story. It is where the pressure is landing: attack speed, active response, and the possibility that AI itself becomes the primary user of the security stack.

TL;DR

• Attacks are now fast enough that human-speed response is no longer a sufficient default.
• That will push the market toward active response, which is useful but also dangerous if the control logic is not deterministic enough.
• Most AI SOC vendors still sound similar because many of them sit on top of existing SIEMs and alert streams rather than changing the underlying detection or data architecture.
• The big SIEM vendors are moving, and one major EDR/SIEM vendor is expanding AI security into on-prem and sovereign environments.
• If AI becomes the user of security products, the UI matters less, the API matters more, and the economics of expensive SIEM platforms get harder to defend.

Attacks are getting faster

This is the part of the market I think people are still underestimating. CrowdStrike’s 2026 threat report says the average eCrime breakout time dropped to 29 minutes in 2025, and the fastest case it observed was 27 seconds. Databricks used its Lakewatch announcement to make a related point from the vulnerability side, citing research that mean time to exploit has fallen from 23.2 days in 2025 to 1.6 days in 2026.

That changes what matters in the SOC. A lot of SIEM workflows still assume there is time to search, enrich, discuss, and decide. That model was already strained. It gets worse when attacks speed up and when the adversary is using AI to compress its own loop. Search still matters, but a search-centric operating model is not enough if the environment can be compromised end to end in under an hour.

The obvious answer is more active response. The problem is that this is where things get dangerous. If teams start handing more containment and remediation decisions to AI before the systems are ready, we are going to see more self-inflicted outages. The market is moving there anyway, because the alternative is to keep defending at human speed against machine-speed attacks. SOAR was supposed to close part of that gap and clearly did not.

AI SOC is still confusing and mostly sounds the same

That was probably my main emotional reaction leaving RSAC: confusion. There were simply too many vendors with very similar messaging. RSAC says the conference had more than 600 exhibitors this year. I could not independently validate an exact count of 36 AI SOC vendors from public RSAC data, but “roughly three dozen” felt directionally right from the floor, and many of them sounded remarkably similar.

The common pitch was familiar: reduce alerts, triage faster, investigate faster, give the analyst a copilot, automate parts of response. Some of that is clearly useful. But a lot of it still feels like a layer on top of the existing SIEM rather than a rethink of the detection stack itself. If the AI mostly sits on top of alert streams coming out of a legacy backend, then it may improve analyst productivity without materially fixing false negatives, brittle detections, or poor data design upstream.

That is also why I do not think most of this market is really using LLMs in a deep way yet. In most cases, the models are being used for triage, recommendations, summarization, and analyst assistance. That is very different from using LLMs for real detection, broader SOC operations, or meaningful changes to the underlying architecture.

For a more complete framework of where AI SOC and SIEM should be heading, see raffy.ch/SIEM.

That is why so much of the category feels undifferentiated. The interfaces are different, the branding is different, and the demo flows are different, but the center of gravity often looks the same. The latest platform announcements only reinforce that point. If the platform owner adds the agentic layer too, the vendors sitting on top of Chronicle, Splunk, or similar platforms have a much harder moat to defend.

The architecture is shifting

By this point, the vendor movement is established. The more interesting question now is what it does to architecture. SentinelOne adds another signal here by pushing more AI security capability into on-prem, sovereign, and air-gapped environments.

Put together, that points to a broader market shift. Storage matters more. Data routing matters more. Sovereignty and local control matter more. Cheap data lakes, strong analytics layers, and flexible orchestration matter more. Traditional SIEM UI matters less than it used to, and that matters not just for SIEM vendors but also for MDRs that differentiated by putting an AI layer on top of someone else’s backend.

That is also why Splunk’s cost model keeps coming back into the conversation. Splunk is powerful and mature, but if the agent becomes the main consumer of the system, customers start asking a different question: am I paying for the analytics engine, or am I paying for UI, workflow, and operating complexity that an agent increasingly does not care about?

If AI becomes the user, the stack changes

The most important implication may be economic, not just operational. Security products were built for human analysts. The value lived in the UI, the workflow, the search language, the dashboard, and the services needed to make all of that usable. But what happens if the real user becomes Claude Code, Codex, Gemini, or some internal agent instrumented across the entire security stack? Daniel Miessler has been arguing that companies and products increasingly become APIs. Security looks like one of the clearest versions of that shift.

In that world, every product starts to look more like an API than an application. That is exactly where the recent announcements are heading. LimaCharlie’s new lc-soc release is a concrete implementation of the same idea: an open-source “agentic SOC as code” where AI agents are coordinated through the cases system and D&R rules, then deployed and versioned like infrastructure.

If AI becomes the primary user, the UI does not disappear, but it stops being the center of gravity. The agent does not care about your console. It cares about whether the data is accessible, whether the schema is consistent, whether the analytics layer is fast, whether the permissions model is clean, and whether the actions are safe to orchestrate.

That creates real pressure on expensive SIEM economics. If the agent can query multiple tools directly, the premium attached to a deeply monetized UI gets harder to justify. The market may move toward something simpler: cheap storage, a strong analytics layer, and an orchestration layer on top. That does not mean incumbents disappear. It means their value proposition changes. If AI becomes the user, the winners may be the vendors with the best APIs, control points, and data access model.

Evals become part of the control layer

The next problem is trust and determinism. Once you push AI beyond triage and recommendations and let it make or recommend more consequential changes, you need a way to keep the system reliable. That is where eval loops come in.

I heard Josh Saxe make this point at RSAC in the context of AI-first infrastructure management: if agents are going to make changes in live systems, you need strong evaluation around them to keep behavior bounded and repeatable enough to trust. I think the same logic applies directly to security operations. The market is moving toward active response, but the models themselves were not built around strict determinism.

That means the answer is not blind autonomy. It is more likely a layered system where adaptive AI sits inside clearer control boundaries, with evals, policy, and deterministic automation around it. Evals stop being an AI engineering detail and become part of the security control layer itself.

“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.