A finance analyst exports a revenue dataset to an approved cloud bucket. Your DLP watches the bytes go by and lets them through. It is right to. Nothing in that payload broke a rule. Three weeks and a dozen small exports later, the dataset is sitting somewhere it should not be, and you hear about it from outside the company.
DLP was tuned, deployed, reporting clean the whole time. It did exactly what you configured it to do. That is the problem, and it is not a tuning problem.
DLP answers one question well. Does this payload match a pattern I was told to look for. The move that hurt you asked a different question, and DLP has no way to ask it: across many permitted exports, none of which match anything, is this the wrong person moving the wrong data at the wrong time.
What DLP sees, and where it goes blind
DLP inspects data in motion against patterns you wrote in advance. Card numbers, SSN formats, file fingerprints, classification labels. Match the rule, it acts. Miss the rule, the move passes.
Keep it. DLP catches the careless. Someone pastes a sheet of customer PII into a personal webmail draft. Someone attaches a confidential-labeled doc to an outbound email. Someone uploads a file that fingerprints to a protected source tree. Those are real exits, and a tuned DLP closes them.
The limit is the word static. A DLP rule is a guess about what bad data looks like, frozen at the moment you wrote it. The rule does not know who is moving the data right now. It does not know what job is moving it, whether this destination is normal for this identity, or whether this volume at this hour fits months of history. It knows whether the bytes matched. That is the only thing it can know.
The exact move it was sold to stop
The analyst has standing, legitimate access to the revenue dataset. Pulling from it is her job. She exports slices through a sanctioned BI connector to an allow-listed bucket, in chunks small enough that no single export looks like anything. The data is not labeled in a way DLP enforces. The connector is approved. The destination is approved. Every export runs on access the company granted her on purpose.
DLP inspects each payload. Nothing matches. Every move passes, correctly, by the policy as written. Then the dataset gets reconstructed elsewhere.
Nothing failed. The policy did its job. DLP evaluates permission one payload at a time, and every payload was permitted. The breach lived in the shape of the exports, and that shape was never in DLP's field of view.
Every move is permitted. The pattern is the breach. DLP models the matter, never the mover, so the pattern is exactly the thing it cannot see.
Why prediction misses it by design
There are three moments you can try to catch a data movement. DLP works the hardest one.
Guess in advance. That is DLP's lane: write rules about bad data, enforce them on the wire. Fast, but a guess, and the guess cannot encode "wrong person, wrong job, wrong hour." So it waves the permitted move through and flags benign moves that happen to look like the pattern.
Look afterward. That is forensics. The review, the disclosure letter. Right about everything and too late about all of it, because the data already left.
Watch at runtime, while the data moves, on the move itself. The move resolved to a real identity and the job behind it, scored against how that identity normally moves data. The permitted-move pattern is visible here and almost nowhere else. DLP, by design, does not stand here. It reads the bytes. It does not resolve the mover.
Where the pattern shows up
You see the pattern from the one vantage that sits below the application and below the sanctioned connector, where every move surfaces no matter which app or channel carried it. That vantage is the kernel.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read your data to tell that a pattern is wrong, and it does not stand between your data and where it is going. The collector runs single-tenant inside your own cloud at negligible overhead, on the order of 0.1% of one core and 4 to 8 MB of memory per host. Content-aware inspection is there when you want it. It is not the price of seeing the move.
Each move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, and whether that fits what the identity normally does. Run the analyst through it and the deviation shows up on several layers at once. The job behind the export is off for her identity. The access is a slow read of high-value paths in narrow windows. The cumulative volume to that destination is high, approved connector notwithstanding. One signal alone is noise. Together they make a case, not an alert.
When the pattern crosses the line, the response is host-level network isolation, quarantine from the control plane. The collector never sits inline. It never blocks, drops, or alters traffic. It isolates the host at the network rather than standing in front of every packet, which is why it can run on latency-sensitive infrastructure a heavy inline control would never get near.
Keep DLP. Add the layer it never covered
None of this rips out DLP. DLP enforces content policy on payloads, catches the labeled and the obviously sensitive, and satisfies controls your auditors expect to find. That is real work and runtime governance should not try to do it.
Runtime data movement governance sits beside DLP and covers the case DLP was never built for: the slow, low-volume, fully permitted move, run by a legitimate identity through a sanctioned channel, where the breach is the pattern and the payload is clean. DLP asks whether this payload is allowed. Hilt asks whether this move, by this identity, at this moment, fits how your data actually travels. You want both answers, because the move that costs you most is the one your DLP policy was written to permit.
The test
Ask whether your DLP can tell you what this analyst's data did over the last three weeks, resolved to the job behind it and scored against how it normally moves, across the channels and destinations she is allowed to use. If it cannot, the move it was built to stop is going through it right now.
That is a short conversation to have, engineer to engineer. If this is the gap you are looking at, we will walk you through how the runtime layer sees the pattern. About thirty minutes.