A developer pulls 50,000 customer records at 2 AM. The same developer pulls the same records on Tuesday afternoon to build a report. Same query, same approved tool, same credentials, same regex match. Your DLP grades both identical. One is the quarterly report. One is the developer leaving for a competitor on Friday.
DLP reads the content. It cannot read the circumstance. That is not a tuning problem you fix with one more policy. It is where the architecture stops.
What DLP is built to catch
DLP inspects content and decides allow or block. It matches regex, fingerprints, and classification labels at the points data crosses a boundary: the network egress, the endpoint, the email client, the browser, the SaaS app. The policy pairs a data class (PII, PHI, PCI) with a channel rule (this destination yes, that one no). Tune it well and it earns its place.
So the intern who tries to mail 100,000 card numbers to Gmail gets stopped. The contractor copying source to a USB stick trips an alert. The phishing victim uploading to a fake SharePoint gets caught. These are real saves, and DLP makes them every day.
Every one of those has a tell in the content or the destination. The match is the case. DLP wins exactly when the bad thing carries a visible marker.
The moves with no marker
Now look at the moves that carry none. Most data leaves through channels you approved on purpose: GitHub, Slack, corporate email, cloud storage, the CI/CD pipeline. DLP lets them through by design, because blocking them stops the business. An engineer with production access queries customer data, exports it to CSV, pushes it to an S3 bucket for analysis. Every step is in the policy. Every step is somebody's job most days.
Then the engineer signs an offer from a competitor. Three days out, they pull six months of customer interaction data, the sales pipeline, the roadmap. Same tools. Same credentials. Same buckets. The content still matches the labels you wrote, but the labels were never the question. If this person exports for analysis most months, the match tells you nothing about this export.
The violation lives in the behavior, not the bytes. DLP does not read behavior.
This cuts deeper than the departing engineer. A rule only knows the patterns you already named: SSNs, card numbers, API keys. The product strategy written in plain prose carries no trigger string, so it walks out clean. Volume and timing fall outside content entirely. Five hundred leads a week is the sales rep's normal; ten thousand the week before they quit is not, and to a content engine both look like the same rows through the same channel. Zip the files, base64 the strings, hide the payload in a JPEG, and the engine sees a ZIP or an image, never the customer database inside it. The content was the only thing it watched, so anything that hides from content hides from DLP.
Watch the movement, not the file
The gap is not a missing rule. It is a missing vantage. Closing it does not mean reading more content. It means watching the move itself while it happens and tying it to who made it and the job they were doing.
That is the layer Hilt works at: runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path. It does not sit inline and does not read your data to do its work. It records the shape of each move: which workload reached for which store, when, how much, how often, where it went. None of that depends on a regex or a label, which is why it sees what content inspection structurally cannot.
The baseline learns normal across three grains: the individual, the role, and the infrastructure cluster. A database admin running scheduled ETL has one movement shape. An engineer running integration tests has another. When a workload moves data in a shape it has never moved, reaches for a store it never touched, or pushes volume to a destination it never used, that break is the signal. Each move resolves to a probabilistic, source-dependent identity, so the answer is not just that data moved but who or what moved it and against which baseline.
Because it runs on the movement as the movement happens, the pattern surfaces while you can still act on it, not in the disclosure letter you read three months later. What lands is a case, not a raw alert: the pattern, the identity behind it, and the context that makes it dangerous. When a move earns it, the response is host-level network isolation, quarantine from the control plane. The collector never sits inline, never blocks, drops, or alters traffic, and never reads your data to act. It runs single-tenant in your own cloud, on the order of 0.1% of a core and 4 to 8 MB of memory. The events never leave your account.
Keep your DLP
Hilt does not replace DLP, and a stack is stronger with both. DLP enforces content and channel rules and stops the obvious violations: the mailed credentials, the USB copy, the fake SharePoint upload. That is the half of the problem where the bad thing shows a marker, and DLP owns it.
Hilt covers the other half: the dangerous pattern across moves that are each, one at a time, permitted. The two reinforce each other instead of overlapping. A move that trips a content match and breaks its movement baseline jumps the queue. A move that breaks the baseline with no content flag, the exfiltration riding inside an approved workflow, finally gets a look it would never have drawn on its own. One DLP alert might be a sanctioned exception. One odd move might be an unusual but real workflow. Together they say far more than either says alone.
The limits of DLP are not a defect in the technology. DLP inspects content, and it does that well. It cannot see the pattern across moves you permitted, because each move was supposed to be allowed. That is the one gap runtime Data Movement Governance is built to close.
If you want to see how this maps onto your own approved channels, we can walk through it on a 30-minute technical call.