UEBA scores the user. It does not watch the data. That single gap is why both end up on the same shortlist, and why the shortlist is wrong: they are not substitutes. UEBA answers whether an account is behaving like itself. Hilt answers whether the data is moving like itself. A security team that runs one and skips the other has a hole shaped exactly like the modern leak.
What UEBA reads
User and Entity Behavior Analytics scores behavior from logs. Authentication events, VPN sessions, badge swipes, SaaS audit trails, endpoint telemetry, directory activity. It builds a statistical baseline per user and per entity, then raises the risk score when a user logs in from a new country, escalates a privilege they never use, or reaches a system outside their pattern.
That is real coverage, and it is the right tool for the threats it was built for. Account takeover surfaces as a login that does not fit the human behind it. Lateral movement surfaces as an entity reaching systems it has no business reaching. Privilege abuse surfaces as access that breaks the established pattern. UEBA correlates those signals across identities and time, and it answers its question well: is this account behaving like itself? A mature UEBA deployment wired into the SIEM is a strong source of identity-centric risk. Hilt does not replace it.
Where the log runs out
A log records that an action happened. A user authenticated. A file was opened. A session started. It tells you the event occurred and whether it fit the user's pattern of events.
It does not tell you what the data did. The volume that left, the destination it left for, the bulk read across high-value paths inside a short window, the approved channel carrying an amount it was never approved to carry, none of that lives cleanly in an authentication event or a SaaS audit trail. UEBA infers data risk from the activity around the data. It never observes the move.
Here is why that gap matters. Your most valuable data leaves on access you granted on purpose. Every move is permitted, so every tool you own correctly lets it through. The login was legitimate. The user was who they claimed to be. The channel was approved. The breach is the pattern across the moves, and that pattern is built from the data movement, not from the surrounding events that land in a log.
What Hilt watches instead
Hilt watches data movement at the kernel, metadata only by default, off the path. It runs single-tenant inside your own cloud and never sits inline. Rather than infer data risk from logs, it observes the move and resolves each one to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits how that identity has moved data across months of history.
Take the case UEBA waves through. A researcher copies proprietary code in small chunks, off-hours, through an FTP channel approved for legitimate transfers. The login fits. The account behaves like itself. The approved channel is approved. The user-behavior baseline holds, because nothing the user did, as an actor, was abnormal.
Hilt reads a different surface. The job is unusual for this identity. The access is a bulk read of high-value paths in a short window. The volume is unusual despite the approved channel. Any one signal alone is noise. Together they form a pattern, and a pattern is a case, not an alert. Hilt writes the case and responds with host-level network isolation, quarantine from the control plane. It never filters packets inline.
UEBA tells you the account is acting like itself. Hilt tells you the data is not.
Why you run both
The two baselines answer different questions, and a clean answer from one does not cover the other.
UEBA owns the identity question: is this user or entity behaving normally across authentication, access, and privilege? That catches account takeover and credential abuse, because those threats live in the activity around the data, which is what logs capture well.
Hilt owns the movement question: is this data moving the way it normally moves, resolved to the job behind it? That catches the permitted-pattern leak, the slow low-volume exfiltration through an approved channel by a legitimate user, which never trips the user-behavior baseline because the user, as an actor, did nothing wrong.
Together the cross-check sharpens. A UEBA risk bump on an identity, next to a Hilt finding that the same identity is moving data in an unusual shape, is a far stronger case than either signal standing alone. And the more dangerous combination is the quiet one: a clean UEBA score sitting beside a Hilt movement anomaly. That is the permitted move every other tool let through, now visible. Hilt does not consume UEBA's logs or rebuild its identity baseline. It adds the layer logs cannot reconstruct.
Questions that separate the two
Four questions tell a movement layer apart from another log consumer.
What does it observe? Ask whether the system reads logs about data or watches the data move. UEBA reads logs, by design and well. A movement layer watches the move at the kernel, off the path, instead of inferring it from the activity around it.
Does it have to read your data? Metadata only by default means the system sees that a pattern is wrong without inspecting content. Content-aware inspection is there when you want it, not the cost of entry.
Where does it sit relative to your traffic? A collector off the path adds no latency and no single point of failure. Hilt watches the move rather than standing in it, on the order of 0.1% of one core and 4 to 8 MB of memory per host, and responds with host-level network isolation, never inline.
Where does the data stay? Kernel event to written case runs single-tenant inside your own cloud: AWS, GCP, Azure, or Ali Cloud. Events never leave your account.
A baseline built on logins, access, and privilege misses the move that was permitted on purpose. A system that resolves each move to an identity and scores it against how that data normally travels is a different architecture, and it is the one that catches the permitted-pattern leak.
UEBA scores the user. Hilt scores the move. The account that stops behaving like itself is real and worth catching, and UEBA catches it. The data that stops moving like itself, while the account behind it never breaks pattern, is the leak the rest of the stack waves through. That is the gap between the two baselines, and it is where your most valuable data quietly leaves.
If you want to see how the kernel vantage lines up against the UEBA baseline you already run, the fastest path is an engineer-to-engineer call, about thirty minutes, to walk through where the two layers meet on your own environment.