Pick the tool by the moment it occupies. Every data security product answers one question: when do you find out your data moved?
There are three places to stand. Before the move, with a guess. During the move, while it happens. After the move, when it is gone and you are drafting the disclosure letter. A product can only sit in one of them, and where it sits tells you what it can and cannot catch better than any feature list.
That matters because of how data actually leaves now. Not through a hole in the wall. It leaves on access you granted on purpose, through channels you approved, by a job that is supposed to touch it. Each move is permitted. The pattern across moves is the breach. So the question is not whether a tool can block a bad action. It is at which moment the tool can watch a permitted pattern become a loss. Predictive, forensic, and runtime each pick a different moment, and the moment decides the rest.
Predictive: guess before the move
Predictive tools are the DLP world: Microsoft Purview, Forcepoint, the classic data loss prevention stack. They decide in advance what a dangerous move looks like, write that as policy, then watch for actions that match. Classify the data, set the rule, flag or stop whatever trips it.
Some of this works, and it works honestly. Give a predictive control a hard rule, "credit card numbers never leave the finance OU," and it enforces that rule the same way every time, fast. Where your risk is genuinely rule-shaped, that is the right tool. Runtime does not replace it.
The limit is baked into the architecture. A prediction is only as good as the guess, and the guess gets written before the system has watched a single move. So predictive fails in two directions at once. It fails loud, firing on the thousand benign actions that happen to match a pattern, which is where DLP earned its reputation for alert fatigue. And it fails quiet, missing the move that breaks no rule. A two-week, off-hours, small-chunk copy through an approved channel violates no policy. The predictive tool, working exactly as designed, lets it through and says nothing. The pattern only exists across moves. Predictive grades each move against a rule it wrote before the moves began, so the pattern is invisible to it by construction.
Forensic: tell you after the move
Forensic tools are detection and response, the "DDR" market category as most vendors say it. They rebuild what happened from logs, audit trails, and telemetry, after the fact. Something goes wrong, and they tell you the scope.
This is where forensics earn their keep. After an incident you need a defensible timeline, and a good forensic stack hands you one: the sequence, the identity, the volume. For breach response and regulatory reporting, indispensable. Runtime does not replace this either.
The limit lives in the word "after." Forensics tell the truth, and they tell it once the data is already gone. The pattern reads perfectly in hindsight, because hindsight is where forensics work. You reconstruct the researcher's two weeks of off-hours copies, the shape is obvious, you write it up. The shape was there the whole time. Nobody saw it while there was still a move to make. Forensic answers what happened. It cannot answer what is happening, in time to act.
Runtime: watch the move itself
The category mostly skips the third moment because it is the hardest to hold. Not guessing ahead. Not reconstructing after. Watching the movement itself as it forms.
This is what Hilt does. One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud. It reads no content to do this, and it does not need to read your data to tell that a pattern is wrong. Each move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits what that identity normally does. When the deviation forms, it shows across layers at once. The job is unusual for that identity. The access is a bulk read of high-value paths in a short window. The destination volume runs high through an approved channel. One signal is noise. Together they are a pattern, and a pattern is a case, not an alert.
Runtime sees what the other two cannot because it stands in the one place the pattern is visible while it still matters: the movement, live. Predictive grades the action against a guess. Forensic grades the trail against history. Runtime grades the move against how that identity's data normally moves, as the move happens. That is why it catches the permitted pattern. It was built to watch the exact thing the other two architectures cannot watch in time.
Watching every move at runtime sounds expensive. It is not, because the collector observes instead of intercepts. It stays off the path, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline. It never blocks, drops, or alters traffic. When it does find the dangerous pattern, it responds with host-level network isolation, quarantine from the control plane, not by filtering packets in the data path. Seeing the move does not mean standing in front of it.
The frame, as a buyer
These three are not really competitors. They are three moments, and a serious posture usually wants more than one. Map what you own onto the timeline and find the gap.
Predictive covers the rule-shaped risk. If a category of move should never happen, a predictive control enforces that. Keep it. Its blind spot is the move that breaks no rule.
Forensic covers the after. When you have to reconstruct an incident or prove what happened, forensics are how. Keep them. Their blind spot is the present tense.
Runtime covers the live pattern. The permitted move, by a legitimate identity, through an approved channel, where only the shape across moves is wrong, is visible at one moment: while it moves. Predictive is too early for it. Forensic is too late. That gap sits in most stacks, not from negligence, but because nothing they own was built to stand there.
So the buying question gets concrete. Take the loss you actually fear, the slow, permitted, legitimate-looking one, and name which tool sees it in time to act. If the answer is "the predictive tool stayed quiet because no rule broke, and the forensic tool will explain it beautifully next quarter," the loss you fear lives in the runtime gap. That is the layer to add.
Nothing gets ripped out for this. Runtime data movement governance is additive. It leaves the predictive control that enforces your hard rules in place, and the forensic stack that reconstructs your incidents in place. It fills the one moment those two leave open: the move itself, as it happens, resolved to the job behind it and scored against how your data normally moves.
To see where that gap sits in your own environment, the fastest path is a 30-minute technical call, engineer to engineer, walking through how your data actually moves and where the permitted pattern would surface.