Zscaler decides who reaches what. It cannot tell you what the data did once the answer was yes. Those are two different questions, and teams blur them because both tools touch data movement and both sit between sensitive data and the world. Zscaler owns the door. Hilt watches the room.
So this is not a replacement comparison. Most teams that run Hilt run a secure access edge alongside it. The question worth asking is narrower: what does each tool see, where do they overlap, and what falls in the seam.
What Zscaler does well
Zscaler built the Secure Access Service Edge category and is good at the job it defined. It proxies your traffic through its cloud, applies policy at the edge, and collapses a rack of VPN concentrators and regional firewalls into a service.
Four things it does well:
- Zero Trust access. A user or workload reaches an application only when policy says yes. Access is brokered per session, per identity, not granted by being on a trusted network.
- Inline traffic inspection at the edge. TLS terminates and decrypts in the Zscaler cloud, so malware, known exfiltration signatures, and policy violations get caught in the flow as traffic leaves toward the internet.
- Edge DLP. Zscaler matches content patterns on data in transit through its proxy and blocks a transfer that trips a rule.
- No appliance estate. No concentrators to size, no regional firewalls to patch. The edge is a service.
Ask "should this identity reach this destination, and does this transfer trip a known rule," and Zscaler answers it. Hilt does not do that job and does not try to.
The move you granted on purpose
Here is the structural limit. It belongs to every access control ever built, not to Zscaler.
Your most valuable data leaves on access you granted on purpose. The researcher is supposed to read the model repository. The integration service is supposed to pull from the customer database. The analyst is supposed to export to the reporting bucket. Every one of those moves is permitted. Zscaler, doing its job correctly, lets them through, because you told it to.
The danger is almost never a single forbidden transfer. The researcher who reads the repository every day starts reading it in small chunks, off-hours, down paths she has never touched, toward a destination that is approved but newly busy. No access rule breaks. No content signature fires, because the bytes are exactly the proprietary code she is cleared to see. The edge evaluates each crossing on its own terms, so it clears each crossing.
Every move is permitted. The pattern is the breach. An access edge cannot close that gap, because closing it would mean holding a memory of how this job normally behaves, and the edge holds no such memory by design.
Where the two tools sit
Read the relationship as vantage point.
Zscaler sits at the network edge, in the path. Traffic flows through it on the way out, which is what lets it block a transfer inline. The cost of that vantage: it sees a transfer when the transfer reaches the edge, framed as a flow between an identity and a destination. It carries no behavioral history of how this job, on this host, normally moves data before the flow ever leaves the machine.
Hilt sits at the kernel, off the path. It watches data movement at the kernel, metadata only by default, observing the move as it happens on the host instead of standing between the data and where it is going. The collector is single-tenant inside your own cloud. It runs at roughly 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline, and never blocks, drops, or alters traffic. When a pattern turns dangerous, Hilt isolates the host at the network, quarantine, from the control plane, not by filtering packets in the flow.
Watching at the kernel, Hilt resolves each move to a probabilistic, source-dependent identity: which user or service, which job behind it, which source, which destination, whether this fits what that identity normally does. Scored against history, that resolution surfaces the pattern no single edge decision could reveal.
The seam between them
Two failure modes live in the gap. Both are common.
Movement that never crosses the edge. A lot of dangerous data movement runs host-to-host, service-to-service, or to a staging location inside your own environment, and leaves only later. Traffic that never transits the access proxy is traffic the edge never sees. The kernel sees it, on the host where it happens.
The slow drain through an approved channel. Even when traffic does cross the edge, it crosses as a series of allowed transfers to an allowed destination. The edge clears each one. Only a system holding the behavioral baseline for that identity, across job, access pattern, and destination volume at once, recognizes that the series is anomalous. Any one signal is noise. Together they are a case, not an alert.
That is the layer Hilt adds. Not access decisions, which Zscaler owns, but a different question answered at runtime: given that access was granted, what did the data actually do, and did the pattern of movement fit how this identity normally behaves.
What Hilt does not do
State the boundary plainly so nobody buys the wrong thing.
Hilt is not a secure access edge. It does not broker Zero Trust access, terminate TLS, or proxy your internet traffic. It does not replace your VPN, your firewall policy, or the edge DLP rules that stop a known-bad transfer before it leaves. If your goal is to decide who reaches what, Zscaler and tools like it own that job, and Hilt is not a substitute.
Hilt also does not block inline. The collector is off the path on purpose. Its response is host-level network isolation from the control plane, the right tool for a pattern already forming across many permitted moves, not a packet filter for a single forbidden one. Different jobs. A team running both gets both.
How to think about running both
Together the two cover the lifecycle of a sensitive transfer. Zscaler governs whether the access happens and inspects the traffic that crosses its edge. Hilt governs what the movement looks like once access is granted, at the kernel, off the path, resolved to the job behind it and scored against how that data normally moves.
Try one test on any access-layer tool. Ask it to explain what a specific service account's data did over the last two weeks, resolved to the jobs behind the moves, scored against its own history, including the host-to-host movement that never reached the edge. If the honest answer is "we see the transfers that crossed our proxy, one at a time," that is the seam. The permitted-pattern breach lives there.
If your stack already secures access well and you want to see the data movement after access is granted, that is a short, specific conversation. Walk an engineer through how the kernel vantage resolves a move to an identity, about thirty minutes, engineer to engineer.