AI is breaking the case for detection-first security

COMMENTARY: No customer wants to buy security to see the logs – or for their security providers to show them the details of an attack after it has happened. What customers want to see is how equipped they are to avert one. While AI has changed the conversation because no one is certain how the attacks will evolve, or if they are already in the company’s systems, waiting for the right window.  This is where security providers can make a real difference. Security providers do not need to tell them that they are detecting, but reframe the conversation to “this is what an attack looks like, this is what we are able to do for you,” and sell services accordingly.

For twenty years, the security industry sold a comforting story. Buy better detection, feed it better intelligence, staff a sharper SOC, and you will catch the attack in time. AI did not break that story. It turned up the volume until the cracks became impossible to ignore.

Service providers feel this first because detection is what most of them sell. When a client asks why the alert arrived after the damage, the honest answer is uncomfortable: the model was always reactive. AI simply removed the margin that let 'reactive' look like enough.

This is not an argument to throw out your stack. It is a practical guide to where the model fails, what to change in your operation, and how to talk about it with buyers who are starting to ask harder questions.

Why detection-led security was always a step behind

Detection-led security is structurally reactive. It waits for an attack to appear, matches it against known patterns or behavior, then alerts a human to respond. Every step assumes time you increasingly do not have, plus the recognition of something the tools have met before. Novel, fast attacks defeat both assumptions.

The treadmill shows up in the data. Google's Threat Intelligence Group began tracking 714 new malware families in 2025 alone, part of a catalog now past 6,000. Every new family is something signatures and trained models have not seen. Mandiant's M-Trends 2026 report, drawn from more than 500,000 hours of incident response, also flags AI and agentic systems as a threat impossible to ignore. Recognition-based defense is running to stand still, and the attackers set the pace.

What AI actually changed for your SOC

AI changed the economics of novelty and the speed of attacks. Producing a fresh variant, a convincing lure, or a working exploit used to take skill and time. Now it takes a prompt. The barrier that quietly protected defenders, the effort it took to be original, has mostly collapsed, and volume scales without limit.

Speed is the sharper edge. Mandiant found that the median time between initial access and handing the victim to a second attacker fell to 22 seconds in 2025, down from more than eight hours in 2022, often through automation. No alert queue answers in 22 seconds. At the same time, global median dwell time rose to 14 days from 11, and roughly half of organizations still learn about a breach from someone outside. Faster attacks, slower discovery, a widening gap.

The operational point for a provider is blunt. If your playbook still assumes a human reads the alert, decides, and acts inside the window where damage happens, the math no longer works for a meaningful share of attacks.

What to do about it: A practitioner's playbook

Reduce what can be executed before you try to catch what does. Detection tuning still matters, but the durable gains come from shrinking the attack surface so there is less to detect and from containing actions automatically when an alert cannot arrive in time. Three moves carry most of the weight.

First, make default-deny the baseline, not the aspiration. Roll out application control so only approved code runs, strip local administrator rights from standard users, block Office macros from the internet by policy, and constrain the living-off-the-land tools attackers reuse: PowerShell in constrained language mode, restricted WMI and scripting hosts, and disabled or logged use of common binaries like mshta and regsvr32. Every item you remove is an attack you no longer have to recognize.

Second, add containment that does not wait for a verdict. Identity-driven segmentation, just-in-time privilege, ringfencing that stops one application from launching another or reaching the network it never needs, and isolation that triggers on behavior rather than on a confirmed signature. The goal is simple: when something does execute, it cannot spread while a human catches up. This is where you close the 22-second gap, because the control acts at machine speed.

Third, attack your own surface on a schedule. Prioritize patching by exploitability rather than raw CVE count, kill stale accounts and exposed remote access, enforce phishing-resistant multifactor everywhere, and run a tabletop built on the 22-second scenario: assume initial access happened and the operator handed off before anyone read an alert. If your only honest answer is to escalate and hope, you have found the gap to close.

Change what you measure, then change the contract

Measure containment, not noise. Alert volume and mean time to detect tell a client how busy you are, not how safe they are. Track time to contain, the percentage of incidents stopped before they spread, the reduction in executable surface per client, and the share of endpoints under default-deny. These are the numbers a board and an underwriter actually want.

Then put those outcomes in the agreement. Most managed-security contracts describe monitoring and escalation in detail and go quiet on what happens between detection and damage. Define it. State which controls are enforced, what is contained automatically, the response commitments you stand behind, and where shared responsibility sits. A provider that can only watch and escalate is exposed the moment a client suffers a loss it saw coming but could not stop. A provider that contracts around contained outcomes has a defensible story when something goes wrong.

How to sell this without selling fear

Stop selling speed as if it were safety, and show buyers the outcome instead. Buyers are already asking what actually happens in the window between an alert and an impact. Walk them through it honestly: here is what we prevent from running, here is what we contain without waiting, here is how we measure it, and here is what we commit to in writing.

Clients do not buy security because they want logs. They buy it because they want nothing bad to happen. Reframe the conversation from how fast you see attacks to how little gets to act, and you are selling the thing they actually wanted all along.

The gap was always there

AI is not the villain in this story. It is the stress test. It took a model that looked healthy under slow conditions and ran it at full speed until the weakness showed.

The gap between seeing an attack and stopping it was always there. For years, it stayed small enough to ignore. It is not small anymore, and the providers who keep selling faster detection are selling a smaller version of the same gap. The ones who shrink what can run, contain it without waiting, and prove it in their metrics and their contracts are selling something better: fewer bad things happening at all.

Key takeaways

AI did not invent the weakness in detection-led security. It removed the slack that hid it. Here is what MSSPs and MSPs can actually do about it.

MSSP Alert Perspectives columns are written by trusted members of the managed security services, value-added reseller and solution provider channels or MSSP Alert's staff. Do you have a unique perspective you want to share? Check out our guidelines here and send a pitch to [email protected].