6 Questions to Ask Your Current MDR Provider

Most security providers can describe what they should be able to do. Fewer can demonstrate what they actually see, track, and respond to in live environments.

That distinction matters more now than it did even a year ago. Attack surfaces have expanded beyond users and endpoints into machine identities, autonomous systems, and internet-facing infrastructure rapidly. At the same time, detection claims have become broader (often without a corresponding increase in observable capability). If the trends shaping modern environments are real, your managed detection and response (MDR) provider should be able to answer the following questions.

1. Can you show me non-human identity activity?

Most security programs were built around users: who logged in, where they logged in from, and what they accessed. But that model no longer reflects reality. In many environments today, the majority of activity is driven not by people, but by machine identities: service accounts, API keys, integration tokens, AI agents, and OAuth applications operating continuously in the background.

The problem isn’t that this activity is invisible; it’s that it’s rarely treated as a primary detection surface. It often exists in separate logs, different tools, or low-priority telemetry streams that may not be actively monitored.

When you ask your provider this question, you’re not just asking whether they collect that data. You’re asking whether they understand it as behavior. Can they show you how a machine identity interacts with your environment over time? Can they identify abnormal usage, scope changes, or privilege drift? And importantly, can they place that activity in the same investigative context as a user session?

If they can’t, then a significant - and growing - portion of your attack surface is operating without meaningful scrutiny.

2. Can you distinguish agentic AI from human behavior?

A new layer of complexity is emerging with the rise of autonomous and semi-autonomous systems. AI agents are increasingly capable of interacting directly with SaaS platforms and internal applications; issuing requests, pulling data, and triggering workflows at a scale and speed no human could match.

From a detection standpoint, this creates a subtle but important question: does your provider recognize the difference between human intent and automated execution?

It’s not enough to see activity. What matters is whether it is interpreted correctly. An AI-driven interaction may look valid at a protocol or authentication level but still represent unexpected or risky behavior in context. Without that distinction, detection logic can become either too permissive or overly noisy.

There’s also a structural challenge. Many monitoring strategies still assume that traffic will pass through defined control points such as SASE layers. But autonomous systems don’t always follow those paths. If activity bypasses those controls, does visibility disappear with it? Or does your provider still retain the ability to observe and analyze what’s happening?

This question is less about AI hype and more about whether detection models have evolved to account for non-human decision-making systems.

3. How do you cover what SASE wasn’t designed for?

SASE has become a foundational component of modern security architecture, but its strengths are tied to a specific design center: users, devices, and branch connectivity. The challenge arises when organizations assume that coverage naturally extends beyond those domains.

In reality, entire segments of the environment fall outside of SASE’s original scope. Operational technology and industrial control systems, for example, often operate on different protocols, different lifecycles, and different risk tolerances. Similarly, unmanaged or ephemeral cloud workloads can appear and disappear in ways that don’t align neatly with user-centric policies.

When you pose this question to your provider, you’re testing whether they recognize those boundaries or unintentionally blur them.

A mature answer should reflect the use of fit-for-purpose controls: monitoring approaches and detection strategies that are adapted to the environment being protected, rather than extending a single policy model across fundamentally different systems. Because when security controls are stretched beyond their intended use, gaps don’t just appear...they become normalized.

4. How do you handle cross-stack correlation?

Very few organizations operate within a single-vendor ecosystem. Over time, security stacks grow into a mix of overlapping capabilities: multiple endpoint tools, different firewall vendors, varied identity platforms, and a growing set of cloud-native controls.

In theory, MDR is meant to unify that complexity. In practice, many providers approach the problem by ingesting data into a single platform. While that can improve visibility, it also introduces a new dependency: the need to continuously ingest, normalize, and store large volumes of data, often duplicating systems you already maintain.

So, the more revealing question is this: How much data is enough data and does correlation depend on large data consolidation, or on analytical capability?

A provider operating at a higher level of maturity should be able to demonstrate how signals are connected across systems without requiring you to rebuild your architecture around their platform. Correlation should reflect an ability to interpret relationships between events, not just to aggregate them in one place.

Because ultimately, attackers don’t operate within tool boundaries, and detection shouldn’t either.

5. What’s your response model for edge device exploitation?

Much of the industry’s detection logic has been shaped by credential-based attacks: phishing, account takeover, and identity misuse. While those remain important, recent intrusion patterns have highlighted a different reality. Exploited vulnerabilities (particularly in internet-facing devices) have become a primary entry point.

These aren’t always clean, well-signaled events. They often involve subtle indicators across network behavior, device logs, and external scanning activity. And in many cases, there is limited or no endpoint visibility to rely on.

This changes the nature of response.

When you ask about edge device exploitation, you’re probing for specificity.

• What signals trigger investigation?

• How quickly are those signals evaluated?

• How does response differ when the initial access vector is a compromised device rather than a compromised user?

The answer should reveal whether your provider has adapted to where intrusions actually begin today, rather than where detection capabilities have historically been strongest.

6. Can you prove it with a real incident?

This is the question that brings all the others into focus. It removes abstraction and replaces it with evidence.

Any provider can describe how their detection model works in theory. They can outline playbooks, reference integrations, and highlight coverage areas. But a real incident tells a different story; one grounded in timing, uncertainty, and decision-making under pressure.

When you ask for a walkthrough, you’re looking for more than a success case. You’re looking for how signals evolved over time, which data points mattered, and how different sources of telemetry contributed to the outcome. In particular, asking for an example where the decisive signal came from network or cloud telemetry - not just the endpoint - tests whether visibility truly spans the environment.

Clarity here is difficult to fabricate. It reflects operational reality.

And it often reveals the difference between a provider who can act on emerging attack patterns and one who can only describe them after the fact.

The difference between coverage and confidence

Modern MDR isn’t defined by how many signals it collects, or how many integrations it supports. Don't get us wrong: those are necessary, just not sufficient. What ultimately matters is whether those signals are:

• Visible across the parts of the environment where risk is actually increasing

• Interpreted in context, not isolation

• And consistently translated into informed, timely response

Your provider may already claim these capabilities, but these questions are designed to validate them. If your provider can answer each of these questions clearly - and support those answers with evidence - you likely have a partner aligned to how threats actually operate today.