A matter resolves on terms that read like the other side already had your playbook. You pull the access log. Every entry says permitted. A paralegal with legitimate access exported documents from that matter over four days, small batches, inside business hours, through the path the platform offers for normal case work. No policy broke. Nothing in the log is wrong. The log just cannot tell you the export happened to the wrong place at the wrong volume by the one person who had a reason to leak it.
Privileged data does not leave a legal platform through a hole. It leaves through a door someone unlocked on purpose. So the question your stack keeps asking, was this move permitted, returns yes on the breach and on the routine export alike. Same answer. Different pattern. The pattern is the part nothing in the stack is watching.
The access is supposed to be loose
A practice-management or e-discovery platform hands out access by role and by matter because it has to. The paralegal needs the documents for the cases she supports. Outside counsel needs the production set. The litigation support vendor needs a slice of the corpus to process it. Those grants are correct. They map to work real people do every day, and tightening them past a point breaks the practice.
Legal raises the cost of getting this wrong. The value of a privileged document often is its confidentiality. A witness list, a settlement term, a memo that surfaces on the other side: the harm is the disclosure, and there is no undo. You do not patch "opposing counsel has read it." So you are running a permissive access model over data whose only protection is that the wrong eyes never see it, where one quiet leak is final. That is the exact condition the permitted-pattern blind spot exploits.
What the log cannot say
Go back to the paralegal. Each pull is authorized. Each is logged as a successful, sanctioned action against a matter she is staffed on. Read the entries one at a time and every one checks out.
Read them as a shape and a different fact appears. This identity, pulling this concentration of high-value paths, from this matter, across these four days, into this destination, does not move data the way she has moved it for the past six months. The grant was right the whole time. The pattern across the grants was the breach.
Application-layer logging and DLP rules score the single action. Is this file allowed to leave, does it match a sensitive pattern, is this user permitted. They catch the loud mistakes: unredacted PII in an outbound email, a production set sent to the wrong address. They were never built to score the shape of movement across many permitted actions by a legitimate user. That is not a tuning gap you can close with better rules. It is the layer those tools live at.
See the move, not the permission
The pattern only exists while the data moves, so that is the only place to catch it. Predictive tools guess in advance who might be a risk and bury the team in false alarms. The audit log and the disclosure letter arrive after, when the documents are already gone. Hilt sits on the movement itself, as the pattern forms.
It watches data movement at the kernel, metadata only by default, off the path. It does not read the privileged document, and it does not need to. It resolves each move to a probabilistic, source-dependent identity: which user, which job, which matter, which destination, and whether that fits how the identity normally behaves. The content stays unread. The pattern stays visible.
When the paralegal pulls the matter, the deviation lands across layers at once. The job is unusual for her identity. The access reads a tight cluster of high-value paths inside a short window. The destination volume runs high even though the channel is approved. Any one signal alone is noise. Together they are a case, written for a human, not an alert dropped on a queue.
If the pattern warrants action, Hilt responds with host-level network isolation, quarantine from the control plane. It never sits inline, never blocks or alters a packet, never stands between a lawyer and a document she is allowed to open. It isolates the host instead of slowing the door for everyone using it correctly.
What this does not replace
Run a legaltech platform and you already have controls doing real work. Access models and matter walls keep the wrong people out of the wrong cases. DLP catches the obvious outbound mistakes. The audit log gives you the record clients and regulators expect. Endpoint and email tooling covers the known attack patterns. Runtime data movement governance can stand in for your endpoint sensor, and many teams retire their EDR once it is in place. It does not replace your access model, your matter walls, your DLP, or your audit log, and pretending otherwise would be a lie a CISO catches in the first meeting. Keep an EDR alongside it only if you also want the malware and live intrusion layer, which is the one job data movement governance does not do.
What it adds is the read those layers were never built to give: how privileged data actually moves, resolved to the identity and the job behind it, scored against months of normal, surfaced as a written case while there is still time to act. The gap is not negligence. It opens because the access was granted on purpose, which is the one condition none of your other controls treat as a threat.
Questions worth asking any vendor
Evaluating how to cover the class-of-move problem on a legal platform, a handful of questions cut through the pitch:
Where does it sit relative to your traffic? A control that sits inline can interrupt a move and also adds latency to legitimate work and becomes a single point of failure on a platform your clients depend on. Ask whether the collector is off the path, observing movement instead of standing in it.
Does it have to read the privileged document? For a legal platform this is the whole game. Ask whether the default vantage is metadata only, so the system can tell a pattern is wrong without opening privileged content. Content-aware inspection should be there when you choose it, never the price of admission.
Does it correlate movement, or just log actions? An audit trail records that each move happened. A system that resolves each move to an identity and the matter behind it, then scores it against normal, sees what the trail cannot.
Where does the data stay? Privilege and client confidentiality make residency the first question, not the last. The path from kernel event to written case should run single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, with events that never leave your account or route through a vendor's SaaS.
The platforms that close this gap are not the ones with the strictest access rules. They are the ones that can answer a harder question: what did this privileged matter's data actually do, resolved to the identity and the job behind it, scored against how it normally moves, across the few days when no policy ever broke.
If that question lands, the way to test it against your own platform is a 30-minute technical call, engineer to engineer, on how the collector watches movement without reading your clients' documents.