Count Your Agents. I'll Wait.
Go ahead. Pull up your endpoint and count every agent running on it. I'll give you a minute. You've probably got your EDR — let's say CrowdStrike Falcon — sitting there at the kernel level doing its thing. Then there's the vulnerability scanner, maybe Qualys Cloud Agent chewing through CPU every time it decides to do an assessment. Your IT team dropped Tanium on there for asset inventory and patch management because "it's different from the EDR, it does different things." Your compliance team mandated a DLP agent. Someone in cloud security added a CSPM lightweight collector. And if you're in a Microsoft shop, Microsoft Defender for Endpoint might be running alongside your third-party EDR because somebody forgot to properly offboard it.
That's six agents. On one machine. Potentially all touching ring 0.
This is the endpoint security tax, and we've collectively agreed to just pay it without asking questions.
The Kernel Is Not a Timeshare
Let's talk about what actually happens when you stack multiple security tools that operate at the kernel level. Each agent that runs a kernel driver is inserting itself into the OS execution path. They're hooking system calls, filtering I/O, intercepting process creation events. This isn't abstracted away — it's happening at the layer where a bug doesn't give you a blue screen on one machine. It gives you a blue screen on every machine in your fleet simultaneously.
You already know where this is going. On July 19, 2024, a faulty content configuration update pushed to CrowdStrike Falcon's Channel File 291 triggered a logic error in the sensor's kernel driver. The result was an out-of-bounds memory read, a kernel panic, and 8.5 million Windows machines going down in a cascading global outage. Airlines grounded. Hospitals reverting to paper. Banks offline. It wasn't a cyberattack. It was a content update file that the sensor's kernel driver mishandled, and because the driver was operating at the highest privilege level on the OS, there was no recovery path short of booting into Safe Mode and manually deleting a file.
Now here's the part the post-incident reviews glossed over: what happens when you have two kernel-level security agents running simultaneously and one of them behaves unexpectedly? Agent conflicts are real, documented, and wildly underreported. I've personally watched a Carbon Black deployment on endpoints that already had Defender for Endpoint active cause intermittent process launch failures because both products were racing to evaluate the same process creation event. The apps looked like they were crashing randomly. It took two weeks and a packet capture of kernel callbacks to figure out what was happening.
And that's a relatively benign conflict. The catastrophic version is a kernel panic loop — two drivers with incompatible filter manager altitudes, both trying to intercept the same I/O stack operation, deadlocking the system. Microsoft's documentation on the Filter Manager explicitly warns about this. Most vendors have compatibility matrices buried in their support portals that most organizations never read before deployment.
EDR vs. XDR: Marketing Ate My Consolidation Strategy
The pivot to XDR was supposed to fix this. Remember the pitch? "Extended Detection and Response — one platform, unified telemetry, fewer agents, better correlation." And honestly, the underlying idea is sound. The problem is that every vendor redefined XDR to mean whatever their current product portfolio happened to cover.
CrowdStrike's XDR story is essentially Falcon platform plus third-party integrations through their Fusion SOAR. SentinelOne's Singularity XDR pulls in identity, cloud, and network data, but you're still deploying their endpoint agent plus potentially their Ranger network discovery module. Palo Alto's Cortex XDR requires their Cortex Data Lake and works best if you're already deep in their ecosystem. None of these are wrong, exactly. But none of them are the "deploy one thing and cover everything" promise that got budget approved.
What actually happened in most enterprises: the XDR platform got added on top of the existing agent stack rather than replacing it. Because ripping out a deployed EDR mid-contract is a procurement nightmare. Because the network team owns the firewall telemetry and isn't letting some endpoint security platform ingest it without a six-month procurement cycle. So now you have your original EDR, the new XDR agent that's "different," and a SIEM that's also trying to correlate everything. Three overlapping telemetry pipelines. Great.
The Resource Math Nobody Does Honestly
Here's a number that should bother you: Qualys Cloud Agent CPU usage during an on-demand scan can spike to 15-20% on a single core, and that's a scanner, not an EDR. CrowdStrike Falcon's sensor is generally well-optimized — typically under 3% CPU in steady state on a modern endpoint — but "steady state" isn't the interesting measurement. It's the CPU spike during an aggressive threat hunt query, or during an IOC sweep across the fleet when your threat intel team just dropped 400 new hashes.
Stack four agents and you're not stacking four steady-state resource footprints. You're stacking four spike profiles that can all trigger simultaneously. A vulnerability scan kicks off at 2 AM, the EDR decides to do a retrospective detection sweep, Tanium executes a sensor update, and suddenly your VDI pool is degraded and users are calling the helpdesk at 8 AM wondering why their virtual desktops are unusable.
On servers, this is worse. A database server running SentinelOne alongside a legacy antivirus agent that the compliance team refuses to remove, plus a Qualys scanner, plus a Tanium endpoint — I've seen this configuration consume enough I/O bandwidth that SQL query latency doubled during scans. The security team said "not our problem." The DBA team filed a P1. Management wanted both teams in a room. Nobody won.
The Evasion Reality Check
I want to talk about something that doesn't come up enough in the "more agents = more security" conversation: attackers have adapted. The assumption underneath agent stacking is that each additional tool adds a detection layer. But the adversarial response to endpoint security maturity hasn't been to give up — it's been to specifically target the gaps and characteristics of specific products.
AMSI bypass is a perfect example. The Antimalware Scan Interface is a Windows mechanism that allows scripts and applications to request scanning of content before execution. PowerShell, VBScript, and other scripting engines call into AMSI before running content. The theory is that even if a malicious script is obfuscated, AMSI hooks it before execution. The practice is that AMSI bypasses are extensively documented, regularly updated, and trivially implemented. Patching the AmsiScanBuffer function in memory to always return a clean result has been a stable technique since 2016. Reflective loading of .NET assemblies that avoid AMSI-aware script hosts is another. The security community publishes these techniques openly, which is how defenders know about them — but it means the defenders need to be looking for AMSI bypass behavior, not just trusting AMSI to catch the payload.
EDR evasion specifically has become a discipline. Techniques like direct syscalls — bypassing the standard Win32 API layer that most EDRs hook, and invoking NT kernel system calls directly using syscall stubs — are now standard red team tradecraft. Tools like SysWhispers and its variants automate syscall stub generation for common API calls. The implication is that an EDR that relies heavily on userspace API hooking rather than kernel-level telemetry is much weaker against this class of evasion. And some commercial EDRs, particularly older ones or those running in compatibility modes, do exactly this.
So when someone argues for deploying both Carbon Black and a second EDR "for coverage," the question worth asking is: are they actually detecting different things, or are they both blind to the same kernel-level evasion techniques? Because if it's the latter, you've doubled your operational complexity for no meaningful improvement in detection against a competent adversary.
A Consolidation Strategy That Doesn't Suck
I'm not going to tell you to rip everything out and go all-in on one vendor. That's vendor sales advice, not security advice. But there's a rational path to reducing agent sprawl without creating coverage gaps, and it starts with being honest about what each agent is actually doing versus what you think it's doing.
Start with a kernel driver audit. On Windows, sc query type= kernel will list running kernel-mode drivers. Cross-reference that against your deployed security tools and ask hard questions about which ones are actually necessary at that privilege level. Qualys doesn't need a kernel driver — it can run as a user-mode service. If it somehow ended up with one, that's a configuration problem. Your EDR probably needs kernel access. Your DLP agent might not.
The second thing worth doing is a genuine overlap analysis between your EDR and your vulnerability scanner. Modern EDRs like Falcon and SentinelOne have vulnerability assessment capabilities built in — they're reading installed software inventory as part of their telemetry anyway. If Falcon Spotlight is already giving you CVE data from endpoint telemetry, running a separate Qualys scan on the same endpoints is giving you incrementally more data at a significant resource and licensing cost. That's a business decision, but at least make it consciously.
Third: if you're running Microsoft Defender for Endpoint in a Microsoft 365 E5 shop, you have a surprisingly capable platform that a lot of organizations are underutilizing while paying for a second EDR. MDE's attack surface reduction rules, tamper protection, and network protection are genuinely good. The telemetry feeds into Sentinel reasonably well. I'm not saying it replaces CrowdStrike for every organization — threat detection fidelity and response capabilities differ — but if you're paying for E5 and running a second EDR without a specific, documented reason, that's worth revisiting.
The consolidation conversation is uncomfortable because it usually means telling a vendor their product is getting removed, and vendors push back hard. But "we have more agents than a CIA field office" is not a security posture. It's technical debt that happens to have a security label on it.
What the CrowdStrike Incident Actually Taught Us
Most organizations drew the wrong lesson from July 2024. The common response was "we need more redundancy" — meaning, some places actually added a second AV layer as a fallback in case their EDR went down again. That is exactly backwards.
The real lesson is that any software running at kernel privilege level is a single point of catastrophic failure, and the appropriate response is to treat kernel-level security agents as critical infrastructure with the same change management rigor you'd apply to a production database schema migration. CrowdStrike pushed a content update — not a sensor update, a configuration file — through a mechanism that bypassed normal change control timelines and went directly to production endpoints globally. The sensor's content interpreter had a vulnerability. The deployment pipeline had no staged rollout or canary validation for content configuration files at the time.
Microsoft's post-incident commentary, including their subsequent blog posts about the Windows Resilient Platform initiative, correctly identified that kernel access for security vendors is a legacy architectural decision that carries systemic risk. The European Commission's 2009 agreement with Microsoft that prevented Windows from blocking third-party kernel access for security tools was cited as a constraint. Whether kernel access for EDR sensors gets rearchitected through something like virtualization-based security or isolated driver containers is a real open question — but in the meantime, the risk is real and it scales with how many kernel-level agents you're running.
Every additional kernel driver is another Channel File 291 waiting for the wrong content update on a bad Tuesday morning.
