Zscaler excels at network control. It enforces policies at the edge, inspects traffic, and prevents users from reaching prohibited resources. For external threats and network-layer protection, it's excellent at what it does.
But network control has a fundamental limitation: it assumes that blocking or allowing traffic is sufficient to prevent data loss. A legitimate user with appropriate permissions moving data through an approved channel is invisible. The traffic is permitted, so there's nothing to inspect. The user has access, so there's nothing to block.
This is where insider risk lives. Not in the blocked connection, but in the allowed one executed at the wrong time, in the wrong pattern, or in the wrong combination with other behaviors.
The Coverage Gap in Network Security
Zscaler operates at the network boundary. It sees encrypted traffic headers, destination IPs, and can decrypt and inspect payloads when configured for SSL inspection. It blocks connections to known malicious domains and enforces data loss prevention policies on traffic it can inspect.
This works when the threat is external or when the insider uses an obviously prohibited channel. It doesn't work when:
- A developer with GitHub access clones repositories they've never accessed before at 2 AM
- A finance employee exports customer data through an approved SaaS application just before giving notice
- A contractor accesses production databases through a VPN they're authorized to use, but executes queries they've never run before
- An admin uses legitimate remote access tools to move files through encrypted channels that Zscaler is configured to trust
The traffic itself is clean. The destination is approved. The user has permission. Network-layer inspection sees nothing wrong because at that layer, nothing is wrong.
Why Behavioral Baselines Require Kernel Visibility
Detecting anomalies in permitted behavior requires seeing what happens inside the system, not just what crosses the network boundary. This means observing at the syscall layer where every process execution, file operation, and network connection is visible before any encryption or containerization obscures it.
When a user executes a process, the kernel sees the exact binary, the parent process that spawned it, the user context, the working directory, and the command-line arguments. When they open a file, the kernel sees the full path, the inode, the access mode, and the timing.
A kernel-level agent using eBPF captures this data at the boundary between user space and kernel space. This is where all activity, regardless of how it's encrypted or tunneled at higher layers, is visible in plaintext. It's the only place where you can build a behavioral baseline that includes both network activity and local system behavior.
Over time, this creates a profile: this user typically accesses these files, runs these processes, connects to these internal services, and does so during these hours with these patterns. Deviations become detectable. A developer who suddenly starts accessing HR databases or running network scanning tools stands out, even if every individual action is technically permitted.
When You Need a Zscaler Alternative Approach
You don't need an alternative to Zscaler for network control. You need complementary visibility that Zscaler can't provide.
Consider a scenario: a sales engineer has access to customer repositories. They use an approved remote desktop tool to connect to a jump box. From there, they access internal systems through a VPN that Zscaler secures. They execute a script that archives customer data and uploads it to a personal cloud storage account that's not on any blocklist because it's a standard consumer service.
Zscaler sees approved connections: the remote desktop session is permitted, the VPN traffic is encrypted and trusted, the cloud storage upload uses standard HTTPS to a known provider. There's no malicious domain, no prohibited protocol, no obvious policy violation.
At the kernel layer, the anomaly is clear: this user has never run archival scripts before, has never accessed this particular set of customer directories, has never uploaded this volume of data to external storage, and is doing all of it at an unusual time. The pattern is inconsistent with their historical behavior across process execution, file access, and network activity.
This is not a replacement for Zscaler. The network controls are still valuable. The kernel-level detection adds a layer that operates on behavioral patterns rather than network policy.
Correlating Risk Across Users, Roles, and Infrastructure
Most insider incidents involve multiple anomalies across different dimensions. A single unusual action might be legitimate. Three simultaneous deviations across different behavioral axes is worth investigating.
A kernel agent that builds baselines across users, roles, and infrastructure clusters can correlate these signals. When a database administrator accesses the payment processing cluster, that might be normal for some DBAs but not others. When they do it during maintenance windows, it's expected. When they do it at 3 AM outside any scheduled maintenance, run queries they've never executed before, and export data to a local file, the combination becomes significant.
This correlation happens at 0.098 seconds average detection latency. By 30 days of baseline learning, false positive rates drop to 0.42%. The system learns what normal looks like for each user in each role across each infrastructure cluster, then flags deviations that cross multiple baselines simultaneously.
The overhead is minimal: 0.1% CPU at 1 million queries per second, 30.9MB average RAM consumption, and actually reduces latency by 5.26% on average due to optimized syscall handling.
Deployment Alongside Existing Security Infrastructure
eBPF-based kernel agents deploy as a DaemonSet on Kubernetes clusters or as a systemd service on virtual machines. They require no kernel modules, no system reboots, and no modification to existing applications.
They operate independently of network security tools. Zscaler continues enforcing network policy. The kernel agent continues capturing syscall-level events. They serve different purposes at different layers.
This is the 5% of coverage that network security can't provide. Not the 95% that handles external threats, malicious domains, and network policy enforcement. The specific slice where permitted activity needs behavioral analysis to detect insider risk.
When you have network control locked down but still need visibility into what legitimate users are doing with their legitimate access, that's when kernel-level detection becomes necessary. Not as a Zscaler alternative for network security, but as a complement that sees what happens inside the systems Zscaler protects.