A researcher pulls proprietary code in small chunks, off-hours, over an approved channel, across two weeks. Your DLP sees each pull. None of them match a policy. None of them are large enough to flag. The code leaves, and the violation report stays empty the whole time. DLP did exactly what it was built to do.
That is the move worth talking about. DLP does real work, and firms running it well catch a lot. But the question is not which tool wins. It is which moves each one can see, and which it cannot.
What DLP catches
Data Loss Prevention enforces content policy. You define what sensitive data looks like: a credit card number, a Social Security number, a document tagged confidential, a regular expression that matches your source code. DLP watches the channels where that content tends to leave. Email. Web uploads. USB drives. Cloud sync clients. Print.
On a match it acts. It warns the user, encrypts the file, blocks the send, files a violation. Good deployments tune this to a specific catalog of regulated data with real consequences attached, across endpoints, egress, and SaaS.
That catches a class of mistakes you cannot afford to miss. An employee attaches a spreadsheet of customer records to a personal email. A contractor drops a tagged document into a personal cloud folder. Someone pastes a key into a public form. Common, costly, and caught. If you handle regulated data, run DLP. Hilt does not replace it.
What its design cannot reach
DLP answers one question: does this content, on this channel, match a policy I wrote. Three things sit outside that question by construction.
It has to recognize the data to govern the move. DLP inspects in user space and leans on classification, fingerprints, tags, regular expressions. Transform the data, compress it, rename it, split it, and the match slips. Source code, model weights, and proprietary research resist being written as a content rule. Those are often the most valuable things you hold.
It watches the egress paths it knows. The approved transfer job, the sanctioned database connection, the developer tool with legitimate network reach, the cloud API the business runs on: a DLP policy does not police these, because the business needs them open.
The third edge is not a tuning problem, and it does not go away with a better catalog. DLP scores each move on its own. Was this content, on this channel, allowed. The dangerous case is the one where every answer is yes. Go back to the researcher. No single transfer matches a policy. No single transfer is unusual enough to flag. Every move is permitted, so DLP correctly lets each one through. The pattern across the moves is the breach, and a tool that scores moves one at a time cannot see a pattern.
What a runtime layer adds
Hilt is runtime Data Movement Governance. It does not enforce a content catalog and it does not sit on the channel. It watches data movement at the kernel, metadata only by default, off the path. One lightweight collector runs single-tenant inside your own cloud, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline, and it does not block, drop, or alter traffic.
The unit of analysis is the difference. Instead of grading one move against one rule, Hilt resolves each move to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits what that identity normally does. It learns how your data actually moves over months and scores deviations against that, not against a rule you had to write in advance.
So when the researcher copies the code, the deviation shows up on several layers at once. The job is unusual for her identity. The access is a bulk read of high-value paths in a short window. The destination volume is unusual despite the approved channel. Any one signal alone is noise. Read together they form a case, not an alert. Hilt writes the case and responds with host-level network isolation, quarantine from the control plane.
And it does this without reading your data. Metadata only is the default. Hilt can see that a pattern is wrong without inspecting content, the way a bank flags the charge that does not fit without knowing what you bought. Content-aware inspection is there when you want it. It is never the price of admission.
Where Hilt does not replace DLP
Hilt does not enforce content policy. If your requirement is that a document tagged confidential cannot be emailed externally, that a regulated record stays encrypted at rest, or that a copy-paste of a known pattern gets warned at the moment of action, that is DLP's job, in user space, on the channel. Keep it.
Hilt also does not stop a single move at the moment it happens. It is off the path by design. It observes the move, resolves it to an identity, and isolates the host when the pattern is wrong. The two layers answer different questions. DLP asks whether a known move of known content on a known channel was allowed. Hilt asks whether the pattern of movement across permitted moves, by a real identity, fits how that data normally behaves.
Running both
A sane end state keeps both. DLP holds the line on classified content over known channels: the obvious mistakes, the regulated catalog. Hilt holds the line DLP was never built to hold: the permitted move, through the approved channel, by the legitimate user, where the only thing wrong is the pattern. One enforces policy. The other governs behavior at runtime, between the predictive tools that guess in advance and the forensics that tell you after the data is already gone.
Here is the test. Ask your DLP what a given user's data actually did between 11pm and 2am on three specific dates, resolved to the job behind it and scored against how it normally moves. If it cannot answer, the most dangerous class of move is outside your coverage, however well the content policies are tuned.
If that is the gap in front of you, the quickest way to find out whether it matters for your environment is a 30-minute call, engineer to engineer, about where your data moves and what a runtime layer would catch that your current stack does not.