An 800 MB read leaves a host at 2 a.m. Routine for a backup job. Alarming for a workstation that has never touched that path. Same bytes, same destination, opposite verdicts. The only thing that separates them is who made the move and why, and the raw event does not tell you that.
This is the wedge in your data security. A service account reads a bucket it is allowed to read. A researcher pulls from a repository she works in every day. A pipeline copies a table to a warehouse it has copied to for a year. Each move is permitted, so every tool you own waves it through. The danger lives in the pattern across the moves, and you cannot read a pattern until you know whose pattern it is. A move with no identity attached is a fact with no subject. Bytes left here, bytes arrived there, nothing to act on. Naming who and why is the job of identity resolution, and it is harder and more honest than most tooling admits.
Who is the hard part
The operating system knows who did something, in a narrow sense. A kernel event carries a process, a user, a session. That is the actor at the instant of the move. It is not the identity that matters for governance, and the gap between the two is where attribution goes wrong.
Take a single read. The event names a process and the account it runs under. To turn that into something you can reason about, you walk a chain. Which program is that process running, and is it the one that normally runs under that account? What job is it part of: an interactive session, a scheduled task, a container an orchestrator started, an agent acting for someone? Who is ultimately accountable for it? The process is a pointer. The identity is what it points to, and the link is rarely one to one.
Ordinary environments break this in ordinary ways. Service accounts are shared across many workloads. Containers are ephemeral, so an account means one thing this hour and another the next. Assumed roles and elevated sessions detach the acting identity from the logged-in one. An agent runs under a service principal but acts for a person who never touched the host. Resolve naively and you pin a researcher's exfiltration on a generic pipeline account, or you blame a person for a scheduled job they never wrote.
Resolution follows the source
Hilt watches data movement at the kernel, metadata only by default, off the path. The kernel is the one vantage where every move shows up no matter which application made it, which is the same reason identity has to be assembled rather than read off a label.
Different sources offer different things, so the identity is built from whatever the move's own source actually carries. An interactive session carries a logged-in user and a session lineage. A container carries an image, a workload name, and an orchestration context that ties back to a deployment. A managed cloud service carries a role and a principal, not a host account at all. An agent carries the service identity it runs as and, where the source exposes it, the human it acts for.
Hilt resolves each move with the signals its source genuinely provides. It does not force a workstation event and a container event through one identity template, because they are not the same kind of thing. Name the identity and the job as precisely as that move's context allows. No more precisely than that.
Probabilistic, and it says so
Here is the part most vendors round up on. Identity resolution is probabilistic. It has to be.
The path from a raw kernel event to "researcher jsmith's interactive session, running an approved transfer job" is an inference, not a lookup. Each link carries its own confidence. The program is almost certainly the one we think. The session attribution is strong. The human behind a shared service account is a reasonable but weaker guess. A system that claims certainty at every link is either reading your data to brute-force the answer or hiding how unsure it actually is. Both are worse than saying so.
So the probability is load-bearing. A high-confidence identity on an anomalous move is a strong case. A low-confidence identity is itself a signal, because identity that should be clean and is not tends to mark the exact moves an attacker wants blurred: the assumed role, the shared account, the lineage that does not add up. The confidence does not sit behind a green checkmark. It is part of what the case reports, so an analyst weighs it instead of trusting it blind.
"Every move resolves to a verified user" would be a tell, not a feature. Admitting the uncertainty is what makes the certain cases worth trusting.
Identity makes the pattern legible
Identity is not the goal. It is what makes the dangerous pattern visible, because an anomaly is only anomalous against a baseline, and a baseline exists per identity or not at all.
Resolve a move to who and why, and one question becomes answerable: does this fit what this identity normally does? A bulk read of high-value paths is routine for one job and a deviation for another. An off-hours transfer through an approved channel is normal for a pipeline and odd for a person. A destination volume is expected for a backup identity and out of character for a researcher's session. None of these comparisons works without naming the identity first. With it, a move every permission check waves through can still stand out, because it does not match the history of the identity that made it.
A log says the read happened and was allowed. A case says this identity, in this job, moved this class of data to this destination, in a way that does not fit how it has moved data for months, and here is the confidence behind each claim. One is a record. The other you can act on.
Where it does not pretend
Resolution does not turn metadata into content, and it is not meant to. Hilt does not read your data to resolve a move, and it does not need to. The privacy default is metadata only, with content-aware inspection available when you want it, never as the price of admission. It does not replace your identity provider, your CMDB, or your access controls either. It consumes the truth those systems hold and grounds each move against it. It adds the layer they were never built for: not who is allowed to move data, but who actually moved it, in which job, and whether that movement fits.
When a resolved move does not fit, Hilt writes the case and can respond with host-level network isolation from the control plane, quarantining the host at the network. It never sits inline and never alters your traffic. The identity is what made that move worth isolating at all. Without the who and the why, you have bytes in motion and no way to tell a breach from a Tuesday.
To see how resolution behaves on your own moves, across the workstations, the service accounts, the agents, that is an engineer-to-engineer conversation. Thirty minutes is usually enough to walk through what gets resolved, how confidence is reported, and where it says plainly that it is not sure.