Why Even Faster Alert Handling Does Not Always Improve Security
Published
Key Takeaways
- Shapira notes that many MDR services keep processing alerts without improving underlying detection quality.
- At Daylight Security, every alert triggers a complete investigation instead of selective triage.
- Standardized MDR playbooks struggle during incident response because they lack environmental and behavioral context.
- Many organizations stay with MSSPs because replacing operational dependency feels harder than tolerating service gaps.
- The follow-the-sun operations remove the need for traditional analyst night shifts.
Hagai Shapira, CEO and Co-Founder of Daylight Security, says most MDR and MSSP teams are designed for throughput, not improvement. Analysts repeatedly handle the same alerts without fixing the underlying issues.
Shapira previously worked at Torq and Israeli Military Intelligence, where he focused on product development, security research, and operational cybersecurity systems.
He maintains that investigations stay manual, while quality remains inconsistent. Replacing deeply embedded operational services feels difficult and resource-heavy. Standardized playbooks help with triage, but often fail during complex incident response requiring environmental context.
Organizations evaluating detection and response providers should examine accountability, visibility into AI decisions, and whether systems improve over time.
Vishwa: You’ve said that managed security services struggle to improve. What happens in an MDR or MSSP team that leads to that?
Hagai: Most MDR and MSSP teams are built around handling volume, not improving outcomes. They’re structured like production lines:
- alerts come in,
- analysts triage them,
- escalate if needed, and
- move on to the next.
The problem is that this model doesn’t help companies continuously improve their security posture or even learn over time. The same alerts repeat, the same investigations get done over and over, and very little of that work turns into better detections or stronger systems. Analysts don’t have the time or mandate to fix root causes; they’re measured on throughput.
Over time, you end up with a system that’s busy but not getting meaningfully better. The work stays manual, the quality stays inconsistent, and improvement depends on adding more people rather than building a better way to operate.
Vishwa: Organizations have used MDR and MSSPs for years. What might keep them relying on services they might not be fully satisfied with?
Hagai: Many security teams today are lean, and they depend on their MSSP for a wide range of responsibilities: managing their SIEM, operating the security stack, handling detection and response, and even threat hunting. Over time, that creates deep operational dependency.
The more a provider owns, the harder it becomes to replace. And most alternatives in the market are more focused point solutions, not full replacements, so switching feels like taking on more work internally.
There’s also a tradeoff between breadth and quality. If you rely on a single provider to do everything, you’re unlikely to get best-in-class outcomes across all areas. It’s similar to any system designed for coverage - it works, but it rarely excels everywhere.
So even when teams see the gaps, they often stay because the cost and complexity of change feels higher than the benefit.
Vishwa: MDR and MSSP services often standardize processes to handle volume. How does that show up in incident response?
Hagai: Standardization works for triage, but it breaks down when it comes to real incident response.
Incident response requires a deep understanding of the environment, from how systems are connected, what normal behavior looks like, to how to reconstruct events across multiple data sources. That level of context is hard to capture in a generic playbook.
That’s why, in many MSSPs, incident response is effectively treated as a separate function, often sold and staffed independently from MDR. The standardized layer can identify something suspicious, but the deeper investigation requires a different level of expertise and context.
Vishwa: At Daylight Security, you’re introducing Managed Agentic Security Services as an alternative to traditional MDR and MSSP models. What does it improve?
Hagai: The biggest shift is that you no longer have to choose between AI and human expertise. Most organizations today feel like they need to pick:
- either adopt an AI SOC tool or
- rely on a traditional MDR service. We combine both.
Our platform uses AI agents to execute investigations and threat hunting end-to-end, correlating data, building context, and determining outcomes. On top of that, we have a team of security experts with backgrounds in incident response and threat hunting.
As AI handles execution, the ‘human’ layer is focused on judgment, decision-making, and novel situations. That’s why the talent bar matters. We don’t have analysts in the traditional sense, but highly talented, experienced people who work in the follow-the-sun model, so there are no night shifts.
The result is a system that not only responds faster, but improves over time and adjusts to your ever-changing environment. Every investigation feeds back into better detections, better context, and better coverage.
It also changes how internal teams operate. Instead of being stuck in reactive triage, they gain visibility, reduce operational burden, and can focus more on higher-value work like forensics and detection engineering.
Vishwa: If an alert comes in, could you walk through what happens next step by step, and how your setup handles it differently from a typical MDR process?
Hagai: In a typical MDR model
- Alerts are first triaged, often automatically, and then assigned to an analyst.
- The analyst checks a few data sources, some of those are defined as ‘agentic’.
- Then they make a determination, and escalate if they can’t fully resolve it or if it looks suspicious.
In our model, every alert and detection rule violation triggers a full investigation from the start.
- AI agents pull the relevant telemetry and business context,
- correlate activity across systems, and
- reconstruct the sequence of events.
- They then execute a complete investigation workflow, enriching data, testing hypotheses, and determining scope, until they reach a verdict.
That verdict could be benign, a false positive, or a true positive. Based on the scenario and customer agreement, results may be reviewed by our security experts, and the response might also be automated.
If it’s a true positive, we immediately engage, reaching out to the customer and leading response actions, including automated containment where appropriate.
If it’s a false positive, we use it to improve the system so similar alerts are handled better in the future.
Every step is recorded and fully transparent to the customer.
Vishwa: Where does a typical MDR investigation stop, and what happens beyond that point in your model?
Hagai: In most MDR services, investigations are limited by two constraints:
- they can’t deeply investigate every alert, and
- they typically don’t operate across all systems
That leads to triage, deciding which alerts to prioritize, and investigations that are often confined to a narrow set of data sources. If something looks suspicious, it gets escalated to the internal team for deeper analysis.
In our model, we remove those constraints. We investigate every alert, not just a subset, and we do it across systems, pulling data from different environments to build a complete picture. We can also validate activity directly, including interacting with employees when needed.
Because of that, we don’t need to escalate just to get more context. We escalate when action is required. If a true positive is identified, we engage immediately and work with the customer to contain and resolve it. The difference is that we don’t just flag issues, we take an active role in driving the response.
Vishwa: If a security leader is evaluating a managed detection and response service, what should they look for to know it will actually improve detection and response?
Hagai:
The starting point is that AI is no longer optional. It’s the only way to meaningfully improve detection and response at scale. The real decision is how you adopt it. Either you build the capability in-house with an AI SOC, or you rely on a service that brings and operates that AI for you.
From there, leaders should look at three things:
- First, who owns decisions when AI is involved, and who is accountable for the outcome.
- Second, whether the system gives you visibility into how decisions are made, including what’s being suppressed or prioritized.
- Third, whether it actually improves over time, building context, reducing manual work, and increasing coverage instead of just processing alerts.
That’s what separates a system that operates from one that actually gets better.
Related
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular