Insider threat detection sounds solved. Every major security vendor has a product for it. CrowdStrike, Proofpoint, Microsoft Purview — they all claim coverage. Most security teams believe they have the problem handled.
They don't.
The gap isn't vendor dishonesty. It's architectural. These tools work at the wrong layer.
Where most tools look
Proofpoint Insider Risk Management and Microsoft Purview both operate primarily at the application layer. They watch what users do in SaaS apps, what files get uploaded to Dropbox, what gets emailed out via Outlook.
This catches the obvious cases. Someone screenshots a customer database and emails it to a personal Gmail account. Someone bulk-downloads from Salesforce before their last day. These are real threats. Application-layer tools catch them.
But they miss a specific class of threat that's becoming more common — and more valuable to attackers.
What they miss: kernel-level exfiltration
Here's a scenario. A quantitative researcher at a trading firm copies 25 megabytes of code over two weeks. She does it in small chunks, off-hours, through an approved FTP connection used for legitimate data transfers. Each individual action looks normal. No policy is violated. No alert fires.
The security stack cost $50 million annually. Nothing triggered.
The reason: application-layer tools check whether the action was permitted. They don't build a behavioral baseline. They don't correlate what this specific user does, at this specific hour, through this specific process, against what normal looks like across three months of history.
Kernel-level visibility does.
At the kernel, every system call is visible before any application-layer encryption or policy enforcement. Process execution, file access, network connections — all captured at the syscall boundary. The behavioral baseline isn't built from application logs. It's built from raw kernel events: PID/UID pairs, binary paths, network 5-tuples.
When that researcher copies those 25 megabytes, the deviation is visible at three layers simultaneously: process behavior (unusual for her UID), file access pattern (bulk read of high-value paths in a short window), and network pattern (unusual destination volume despite approved channel). Any one signal, alone, is noise. The three together are a flag.
This is what kernel-level insider threat detection finds that Proofpoint can't.
The latency objection
Trading firms have an additional constraint that rules out most security tooling: latency sensitivity. A security agent that adds microseconds to order processing is a hard no. The security team doesn't get to override the trading infrastructure team on this.
This is why most firms running latency-sensitive workloads have accepted partial coverage. The performance profile of typical endpoint agents is incompatible with their infrastructure requirements.
Kernel-level agents built on eBPF change this. eBPF operates in the kernel itself, without loadable kernel modules, with negligible overhead. Measured across 1 million queries per second on current hardware, the CPU overhead is 0.1%. Average detection latency is under 100 milliseconds. For trading infrastructure, the performance penalty is effectively zero.
This is the first time the latency constraint and the coverage requirement can both be satisfied by the same tool.
What "coverage" actually means in 2026
The frame that matters for security leaders: your existing stack covers roughly 95% of the threat surface. CrowdStrike handles known attack patterns and endpoint behavior in user space. Zscaler controls network-layer access. Proofpoint catches application-layer exfiltration paths.
The 5% isn't a gap from negligence. It's a structural limitation of where those tools operate.
The insider threat problem — behavioral anomalies that cross process, file, and network simultaneously, executed through permitted channels by legitimate users — lives in that 5%.
Kernel-level detection doesn't replace what you have. It closes the gap your existing stack was never designed to cover.
What to look for in a kernel-level solution
Not every "kernel-level" claim means the same thing. Questions worth asking any vendor:
Does it require a kernel module? Traditional kernel modules require matching each kernel version and carry stability risk. eBPF-based agents (CO-RE/BTF) run without kernel modules and are portable across kernel versions.
What's the actual performance overhead? Ask for benchmarks on comparable hardware. Specifically: CPU overhead at production QPS levels, and detection latency under heavy load. Round numbers are a red flag.
What are the three detection axes? A behavioral baseline built only on user activity misses process-level anomalies. A system that correlates user behavior, process behavior, and network behavior simultaneously is a meaningfully different architecture.
Where does the data stay? For regulated industries and trading firms, data residency matters. The enrichment pipeline — from kernel event to anomaly alert — should run inside your cloud environment, not route through a vendor's SaaS.
What does a false positive rate look like at 180 days? Detection accuracy improves significantly as the behavioral baseline matures. Ask for false positive rates at 7 days, 30 days, and 180 days. A system that doesn't improve over time isn't building a real baseline.
The bottom line
Insider threat detection has been a partially-solved problem for a decade. Application-layer tools gave security teams something to point to. They catch the obvious cases.
The harder cases — long-duration low-volume exfiltration through permitted channels by legitimate users — require visibility below the application layer.
That visibility exists now. The architectural constraint that made it incompatible with performance-sensitive environments is gone.
If your current stack can't answer "what did this user's processes do at the kernel level, correlated against their network behavior, between 11pm and 2am on these three dates" — you have the gap.