A contractor opens the VPN you provisioned for them. The session is encrypted. The destination is a cloud storage account that sits on no blocklist, because it is a consumer service half your company already uses. Zscaler watches the connection form, checks it against policy, and waves it through. Every decision is correct. The contractor still walks out with a year of customer records.
Zscaler decides whether a connection is allowed. That is the job, and it does it well: policy at the edge, inspection of traffic it can see, users kept off domains they have no business reaching. The question it answers is whether the door opens.
It does not answer what walks through. Your most valuable data leaves on access you granted on purpose, through doors you told Zscaler to keep open. The user has permission. The channel is approved. The connection is correct. The breach rides inside all three.
Where the network boundary stops seeing
Zscaler reads headers, destination IPs, and payloads when you turn on SSL inspection. It blocks known-malicious domains. It enforces loss-prevention rules on traffic it can read. That catches the external attacker and the employee who reaches for an obviously banned channel.
It does not catch these:
- A developer clones a repository he has never touched, at 2 a.m., from an account that has never worked nights
- A finance analyst exports customer data through your sanctioned SaaS tool the week before she gives notice
- A contractor pulls a volume from a production database he is authorized to reach, ten times anything he has pulled before
- A service account moves files through encrypted channels you configured Zscaler to trust
The traffic is clean. The destination is approved. The permission checks out. At the network layer, nothing is wrong, because at the network layer nothing is wrong. What changed is the shape of the movement, and that shape is invisible from the edge.
The move resolves at the kernel, not the boundary
To see an anomalous move buried inside permitted activity, you have to watch the data move, not just count what crosses the wire. The kernel is where that happens. A file read, a copy, an upload, a database pull: each resolves there into an actual movement of bytes, before tunneling or higher-layer encryption hides where it is headed.
One lightweight collector sits at that vantage. It watches data movement at the kernel, metadata only by default, off the path. Each move resolves to a probabilistic, source-dependent identity: which workload moved what kind of data, to where, as part of which job. Reading the contents is not required. Content-aware inspection is there when you want it, but metadata is the default, so the collector does not have to read your data to do the work.
Run that for a while and a baseline forms. This workload moves this kind of data, to these destinations, in these volumes, on these jobs. Then a workload starts pushing sensitive data toward a destination it has never used, in a volume it has never moved. Every single move is permitted. It still stands out.
What this looks like next to Zscaler, not instead of it
You do not need to rip out Zscaler. Its network controls keep doing what they do. You need a second reading of the same activity, taken from the data instead of the connection.
Walk the contractor scenario forward. The workload reaches internal systems through the VPN Zscaler secures. A job archives a set of customer records and uploads them to a personal cloud storage account, standard HTTPS, known provider, no blocklist hit. Zscaler sees a permitted session, trusted encrypted traffic, an ordinary upload. No malicious domain, no banned protocol, no policy break.
In the data movement, the anomaly is plain. This workload has never moved this set of records, has never sent this volume outside, and is doing it under a job that does not fit its history. Hilt surfaces the pattern, writes the case, and responds with host-level network isolation (quarantine) from the control plane. The collector stays off the path and never sits inline. It does not block, drop, or alter traffic. It isolates the host once the dangerous pattern resolves.
One anomaly is noise; several at once is a case
A single odd move is usually nothing. Stack a few deviations on top of each other, across different axes of the same movement, and the picture changes.
A baseline built across workloads, roles, and infrastructure lets those signals line up. A workload tied to database administration reaching the payment cluster is routine for some roles, expected inside a maintenance window, and a problem when it happens outside one while moving data it has never moved toward a destination it has never used. The collector resolves each move to an identity, then surfaces the pattern that trips several of those expectations together. You get one case, not an alert per move: the dangerous pattern, the moves inside it, the identity behind them. Events never leave your account, because the collector runs single-tenant in your own cloud.
The cost of running it is checkable. Roughly 0.1% of one core and 4 to 8 MB of memory per collector, off the path, out of the way of the traffic it reads.
Deploying it
One collector covers your cloud workloads and your macOS-compatible user endpoints, single-tenant in your own cloud: AWS, GCP, Azure, Ali Cloud. No reboots, no application changes. Zscaler keeps enforcing network policy. The collector keeps reading data movement and resolving each move to an identity. Two layers, two jobs.
This is the slice network control was never positioned to cover. Not the malicious domains and edge policy Zscaler already handles, but the permitted moves that only read as exposure once you watch them as data movement.
If your network controls are locked down and you still want to know what your most valuable data is doing with the access you granted on purpose, a 30-minute technical call is the fastest way to see where this fits.