Varonis can tell you the researcher has access to the repository, that the access is correct, and that nobody granted it by mistake. It cannot tell you she has been copying the repository out in small chunks for two weeks. Those are different facts, read from different vantage points, and a buyer comparing the two is really asking which fact they need.
Put plainly: Varonis governs who can reach the data. Hilt governs what the data does once they do. Both are real. They do not compete for the same job.
The map Varonis draws
Varonis is built around access governance. It draws the static picture of your estate: where sensitive data sits across file shares, SharePoint, Microsoft 365, Salesforce, cloud storage, and databases, who can reach it, and how that reach was granted.
Then it interrogates the map. Which permissions are excessive. Which folders are open to "everyone." Where stale accounts still hold access nobody remembers granting. Where one over-broad group quietly exposes a finance share to half the company. It classifies the data, scores risk against the access surface, and gives you a route to least privilege at a scale no one audits by hand.
Most exposure starts as misconfigured access, so this is the floor under everything else. You cannot reason about movement until you know what data you hold and who can touch it. If the open question in the room is "we do not actually know who can reach our most sensitive data," that question is the one Varonis was built to close.
Varonis also runs user behavior analytics on top of the map, flagging access events that deviate from the baseline it built. That catches a real class of threat. It is also where the access vantage point runs out of road.
Where the map goes clean and the breach does not
Access governance reasons about the permission. Was the move allowed, who was allowed to make it, was the allowance a mistake. It does not resolve the move itself, at the layer where data leaves, scored against how that data normally moves.
Take a permission that is correct. A quantitative researcher has legitimate access to a proprietary code repository. She opens it every day. The access is not excessive, not stale, not misconfigured. By every measure an access tool cares about, this permission should exist, and it does.
Over two weeks she copies that repository out in small chunks, off-hours, through an approved transfer channel built for legitimate jobs. No permission breaks. No access rule trips. The map stays clean, because the map was always clean. The breach never touches the permission. It lives in the shape of movement across permitted actions, and a permission-centric tool has no native vantage on that shape.
This is the structural ceiling, not a tuning problem. "Should this person reach this data" and "is what this person's data is doing right now, resolved to the job behind it, consistent with how it normally moves" are different questions. The second one is answered at runtime or not at all.
What Hilt reads instead
Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud. It does not read your files to see that a pattern is wrong.
Every move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, and whether the move fits what that identity normally does. When the researcher copies the repository out, the deviation surfaces on several layers at once. The job is unusual for her identity. The reads are a bulk pull of high-value paths in a tight window. The volume to that destination is unusual even through an approved channel. One signal is noise. The signals together are a pattern, and a pattern is a case, not an alert.
When the pattern crosses the line, Hilt isolates the host at the network, quarantine from the control plane. The collector never sits inline, never blocks or alters traffic, never stands between your data and where it is headed. It watches the move instead of gating it, which is why the overhead stays near 0.1% of one core and 4 to 8 MB of memory per host. Events never leave your account.
Varonis says the permission exists and is correct. Hilt says what the data did under that permission, in time to act, without reading the data.
What Hilt will not do for you
Hilt does not build the permission map, and it does not pretend to. It will not name the SharePoint folder open to everyone, the service account holding stale credentials, or the place your least-privilege program should start. It does not do the classification and access inventory that has to happen before any of the rest is tractable.
So if you have not done access governance, do that. A runtime read of movement is far sharper when the access surface beneath it is already clean. Varonis does that foundational work; Hilt reads movement against an estate someone has already brought under control. The exposure from permissions you should not have granted is one half. The exposure from permissions you granted on purpose is the other, and the harder half, because nothing in the access map ever looks wrong.
Start with whichever half is bleeding. Permission sprawl, unknown data locations, an access surface nobody has audited: that is the access governance work, and it is the prerequisite. The move permitted on purpose, the slow low-volume exfiltration through approved channels by legitimate users that never trips a check: that lives at runtime, on the movement itself, and the access map is structurally blind to it. Mature programs run both, the clean map underneath and the runtime read on top.
If you want to see how runtime movement reads against an estate you have already brought under access control, a 30-minute technical call is the fastest way to find out. We walk through where the collector sits, what it resolves, and where the layer lands on top of what you already run.