What Are You Actually Set Up to Detect?

Ask a security leader how many alerts they got last week, and they can tell you. Ask them what their program is actually set up to detect, across every security tool, every SIEM rule, and every detection their MDR runs on their behalf, and the room goes quiet.

That silence isn't a knowledge gap. It's a visibility gap, and it's structural.

Detections don't live in one place. They accumulate across different sources, each managed differently and almost never viewed together. There are the alerts produced by the security tools already in your environment, like your EDR, cloud, and identity products. There are the rules your team has written in your SIEM over the years, from out-of-the-box content to deeply customized logic. And there are the detections your MDR provider operates for you, which for most providers sit behind a curtain you never get to look behind.

Because these three sources are never mapped to a common framework, no one can answer the most basic question about coverage. Across everything, what are we even set up to detect, and where are the gaps? You can't tell what's well tuned and what's noisy, where two systems are detecting the same thing, or where there's simply no coverage at all. So decisions about what to keep, tune, or retire get made blind, one tool at a time.

This is how detection engineering quietly becomes a poor use of time. Teams write a lot of detections. Nobody reviews whether they fire usefully. Many end up noisy, dormant, or forgotten. The work continues, but its effectiveness is never measured, and effort you can't measure is effort you can't prove.

We built Detection Program Visibility to close that gap. This post goes a little deeper into how it works.

One operational view, not three silos

Detection Program Visibility gives you one place to see every detection protecting you, from your security tools, from your SIEM, and from Daylight, and it maps all of them into a single shared model.

<add full Detections page screenshot here (Connected tab showing the detection list plus the Severity Distribution and Top Detectors widgets)>

Third-party and Daylight detections are already modeled that way, so every detection shows up with its description, source, author, severity, MITRE ATT&CK mapping, status, alert volume, and the cases it has generated. SIEM detections get pulled into the same model. Daylight reviews the rules that exist in your SIEM, maps them into the taxonomy, and shows them alongside everything else. The Library view goes one step further and shows detections for integrations you haven't connected yet, so you can see exactly what coverage you'd gain by turning one on.

The point isn't a prettier inventory. It's that coverage stops being a static list and becomes an operational program you can actually reason about.

How Daylight detections actually work

Here's a detail that matters technically. Daylight detections don't run on the narrow logic of any single point solution. They run on top of ingested telemetry, the raw logs from across your environment, which means they can catch behavior an individual tool would never see on its own. They come in three forms:

• Single-event detection, where one log event meets the criteria on its own. Cloudflare Access Policy Deletion is a good example. The deletion of a Zero Trust access policy is a single, high-consequence event worth catching the moment it happens.
• Correlation detection, where events from different sources or signal types are combined to reveal something no single event shows, like identity activity correlated with endpoint behavior.
• Multi-event signal detection, where a pattern emerges across many events of the same kind over time. Claude SSO Login Brute Force is exactly this. No single failed login means anything, but repeated failures for the same user inside a short window is a signal.

That range is why cross-domain telemetry beats point-solution logic. A single tool sees its own slice. Detections that operate on the underlying data can see the pattern.

The feedback loop is the whole point

This is where Detection Program Visibility becomes something a standalone dashboard can't be.

Because Daylight doesn't just show detections, it operates them and investigates the cases they generate, every investigation produces a verdict. Benign, false positive, suspicious, or true positive. Roll those verdicts up per detection, and detection quality stops being an opinion and becomes a measurement.

Take three real detections. Claude MCP Server Created, which fires when a new MCP server is added to a Claude Enterprise organization, a genuinely new AI attack surface, has generated 38 cases, 37 of them benign. Claude SSO Login Brute Force has 2 cases, both benign. Cloudflare Access Policy Deletion has 2 cases, both benign. None has produced a confirmed true positive yet.

Read that the wrong way and it looks like noise. Read it the right way and it's the first time you can actually see how a detection is performing. The MCP detection is giving you full visibility into every new tool connection in your AI environment, and its verdict breakdown tells you, honestly, that so far those connections have been legitimate. Now you get to make an informed call. Is watching every MCP addition worth the case volume? For most teams adopting AI, that answer is an easy yes. The difference is that it's now a decision backed by data, not a guess.

That's the loop. Detections fire, Daylight investigates, verdicts flow back, and the program gets measurably better over time.

MITRE, done honestly

We map every detection, third-party, SIEM, and our own, to MITRE ATT&CK, because it's the common language security teams, boards, and auditors actually recognize. Cloudflare Access Policy Deletion maps to Modify Authentication Process (T1556.009) and Disable or Modify Tools (T1685) across Credential Access, Defense Impairment, and Persistence. SSO Login Brute Force maps to Brute Force (T1110). MCP Server Created maps to Software Extensions (T1176).

But we're deliberate about what a MITRE map is for. Coverage isn't about how much of the matrix lights up. Not every technique matters equally, and a "covered" technique isn't the same as an effective detection for it. The value is knowing you have effective coverage on the techniques that matter to your environment, and seeing clearly where you don't.

From visibility to operation

Every detection also carries a status, Enabled, Tuning, or Disabled, so the view reflects what's genuinely running, not a periodic audit. A detection in Tuning is one Daylight is validating for accuracy and noise before it ever generates a case for your team. That lifecycle is visible to you, which is the whole idea.

Traditional MDRs hide the detection program behind a portal. You see escalations, never the machinery. Daylight takes the opposite approach. The same platform that operates your detections exposes them to you. What we run, what your SIEM contributes, where tools overlap, and where the program still needs work. That's our glass-box model. Transparent operations, measurable outcomes, and a clear view of what good looks like.

Where this is going

Detection Program Visibility is the foundation. We're building on it. Plain-language explanations of each detection, and a co-pilot, so anyone, not just detection engineers, can understand what a detection looks for and what it deliberately doesn't. Evidence-based tuning recommendations drawn from verdict statistics. And SOC-approved markers showing which detections our security team has reviewed and stands behind.

For years, managed detection asked you to trust what happened behind the curtain. We think you should be able to see the program protecting you, understand how it's performing, and improve it with us. That's the difference between a pile of rules and an actual program, and it starts with being able to answer one honest question. What are you actually set up to detect?

Detection Program Visibility is available now for Daylight Managed Agentic MDR customers.