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.

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.