Alice logs into GitHub at 10am EST, the way she does every weekday. Her UEBA tool sees nothing to flag. The login fits her baseline, the role fits the login, and the session is real. What the tool does not see is what happens next: under that session, a pull of configuration and credentials, then an outbound push to a host Alice has never touched. Every step was permitted. The exfiltration rode the permission out the front door.
UEBA watches the front door. It baselines logins, application usage, and access requests, so when someone in finance opens HR systems at 3am, it raises a hand. That catches account compromise that announces itself in application behavior. It does not catch the move that uses access you granted on purpose, because nothing about that move looks unauthorized.
UEBA reads the log, not the move
UEBA ingests from the surfaces that emit logs: identity providers, SaaS apps, VPNs, cloud APIs. Okta records the login. Salesforce records which records were viewed. CloudTrail records which buckets were touched. Each source describes an event at the application layer and stops there.
The data itself moves below that layer. A process reads files the user is entitled to read. A workload calls an API it is authorized to call. An agent moves records it was provisioned to move. The session stays valid, the permission stays real, and the SaaS stack logs nothing strange, because nothing strange happened at the front door. The strange thing happened underneath, in the sequence of reads and writes the log never captured.
So UEBA sees the bracket around the move and not the move. Login, then logout. Open, then close. The middle, where data actually travels, is dark to it.
Network telemetry is the wrong altitude
Many UEBA deployments bolt on network behavior analytics. They learn which internal systems a user reaches, which protocols, how much volume, and they alert on deviation. That sounds like visibility into movement. It is visibility into connections.
A connection record tells you a database admin's laptop sent a large volume to an external host. It does not tell you which process opened the file, which file it read, or which identity and job own the transfer. And the moves that matter rarely look like one large transfer. They spread across many small connections over days, ride protocols that pass for legitimate, and reuse tunnels that are already open. Read one packet at a time, each piece is ordinary.
Resolve it at the point where the data moves and the sequence reads cleanly. A workload that has never reached outside the environment starts sending out. A read of sensitive files lands immediately before an outbound write. A destination does not fit the identity behind the request. Working from NetFlow or firewall logs, UEBA cannot bind a file read to the network write that follows it, or tie either to a real identity. That gap, between "Alice downloaded a file" and "this identity read this data and moved it there as part of a job it has never run," is where the limitation turns into loss.
A baseline of two when the breach lives in the third
Behavioral baselines have three axes that matter: the user, the role, and the infrastructure. UEBA models the first two well. It knows what Alice does and what Alice's peers do. It does not model the third, because nothing in its log diet describes the infrastructure dimension: what normal data movement looks like on a production database server versus a developer workstation, which workloads normally move data on a payment cluster versus a static-content fleet.
Hide the move in the third dimension and it disappears. Compromise Alice's account and do something odd on her laptop, and you create a user-level anomaly that might surface. Use a service account to pull the same data off a fleet of application servers, and there is no user to baseline against. That move never enters the UEBA picture at all.
Watching data movement at the kernel lets the three axes correlate at once. The system resolves that Alice, in a developer role, moved data off a production database server in a way no developer has on that infrastructure before. One axis deviating is noise. Three deviating together is a case, and the case writes itself. Run on two axes and you catch the loud ones and wave through the ones that look permitted.
What runtime data movement governance adds
This is not a UEBA replacement. UEBA still tells you who logged in from where; keep it. Hilt sits under it and answers the question the logs cannot: which identity moved what, where it went, and the job behind it.
One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud across AWS, GCP, Azure, and Ali Cloud, alongside macOS-compatible user endpoints. Off the path means negligible overhead, on the order of 0.1% of one core and roughly 4 to 8 MB of memory. Metadata is the default, so Hilt does not have to read your data to see the move. Content-aware inspection is there when you want it, but it is not where you start. Each move resolves to a probabilistic, source-dependent identity and the job behind it, not an IP and a byte count. That is what turns a stream of permitted events into a pattern a human can read.
When the pattern is the dangerous one, Hilt writes the case and isolates the host at the network, quarantining it from the control plane after the move is resolved. The collector never sits inline and never blocks, drops, or alters traffic. Nothing legitimate has to route around it. The case lands in the same SIEM or security data lake that already consumes your application logs, and the events never leave your account. When UEBA flags an odd SharePoint session, the movement layer shows whether that identity also moved data somewhere it does not belong.
The limitation is not a defect in your UEBA. Application logs show what application logs show. The data moves a layer down, on permissions you issued yourself, and the only place to read that pattern while you can still act on it is at runtime, on the move itself.