Falcon catches the dropped binary, the odd process tree, the stolen credential. It is a strong EDR and it answers one question well: is the thing running on this machine malicious? Ask it a second question and it goes quiet. Is my customer table leaving on a login I issued last quarter? Falcon has no opinion. The login is valid. The process is signed. Nothing on the host looks wrong, because nothing on the host is wrong.
That silence is not a misconfiguration. It is the boundary of what EDR was built to see. A CISO who treats Falcon as full coverage over how data leaves the building is reading a map that ends before the exit.
The intruder Falcon hunts, and the move that walks out the door
EDR hunts intruders. Dropped binaries, credential theft, known-bad signatures, the process tree that does not belong. Bring foreign tools onto a host and Falcon finds them. Keep that. Hilt does not touch it.
The exfiltration that hurts you brings no tools. Your most sensitive data leaves on access you granted on purpose. The service account reads the customer table it was scoped to read. The engineer pulls the config he is paid to pull. The AI agent queries the store you handed it. Each move is permitted, so every tool that asks "is this allowed?" says yes and steps aside. No malware. No signature. The breach is not one event. It is the shape of many permitted ones, lined up.
Falcon watches the process behave normally and concludes the process is normal. It is right. The theft is riding inside the access you already approved.
Permitted moves slip past tools built for bad actors
Most of your stack renders a binary verdict. Known-bad stops, everything else passes. EDR matches behavior to malicious patterns. The firewall enforces allow and deny. Zero-trust checks whether the identity is authorized. Every one of these calls is correct, and every one waves the dangerous move through, because someone authorized it.
Picture moves no malicious-pattern engine will ever flag. A service account pulls an export ten times larger than last month, and it has the right to pull it. A user copies a sensitive dataset to a destination that sits, technically, in scope. A vendor with valid credentials reads more in one night than it read all year. None of it is malware, so the malware engine stays silent. The access is real, the identity valid, the action permitted. What moved is the behavior underneath: the volume, the destination, the hour, the gap between this and everything that identity has done before.
EDR is not looking in the wrong place. It is looking for the wrong kind of thing. It recognizes a bad actor. Data movement governance recognizes a bad pattern stitched from moves that are each fine on their own.
Encryption hides the pattern on the wire
Once a move rides modern application-layer encryption, network tooling sees a handshake and ciphertext. Not meaning. EDR and network monitors clock that a connection happened and roughly how much crossed it, but the request, the intent of the destination, the relationship to normal stay opaque. Exfiltration through a legitimate encrypted API call looks exactly like every other legitimate encrypted API call.
So the wire is the wrong place to look. The export of a sensitive table over an ordinary HTTPS request is indistinguishable from a routine export if all you watch is the packet. It separates the moment you watch the move itself: which identity, against which data, how much of it, to where, set against what that identity did yesterday.
Hilt watches data movement at the kernel, the vantage that sees a move form rather than reads about it after it lands in a log. It reads metadata by default and resolves the shape of a move without reading your data. Content-aware inspection is there when a case demands it. The default and the lead is metadata. Governing how data moves does not require opening every file that moves.
Behavior across identities, not one host at a time
EDR baselines a host. It learns what normal looks like for that machine and flags what deviates on that machine. Correct for catching an intruder sitting on an endpoint. Useless for catching theft that spans identities, jobs, and systems.
The dangerous pattern rarely sits on one host. An identity reads data it is cleared to read. The same identity pushes that data toward a destination it is permitted to reach. The volume runs high, the timing runs late against that identity's own history. Step by step, every move is normal for the host it touches. The pattern surfaces only when you resolve each move to who or what is behind it and the job it serves, then weigh it against how that identity usually moves data.
This is the work. Data movement governance does not ask whether one machine looks compromised. It resolves each move to a probabilistic, source-dependent identity, sets it against prior behavior, and surfaces the anomalous pattern while it is still forming. The blind spot lives here, in the space between identities, across moves no single-host baseline will ever connect.
Runtime is the only window that helps
A data move has three windows. Two of them lie to you.
Predictive tools, the old DLP world, guess in advance which moves will turn dangerous. They guess wrong often, bury the team in false alarms, and still miss the permitted move, because in advance it looked allowed. Forensics and after-the-fact detection read it back to you from logs once the data is already gone. That is the disclosure letter, not the save.
Runtime is the third window. Watching the move as it happens, on the movement itself, is the only place the pattern is legible in time to do something. Your bank already runs this logic on your card. It does not pre-block every purchase, and it does not mail you a letter a month later. It flags the charge that does not fit, in the moment, without knowing what you bought. Hilt does that for your data.
Where this sits in your stack
You probably have intruders covered. CrowdStrike handles malware, suspicious processes, endpoint threats. The SIEM correlates logs. Zero-trust segments access. Scanners find misconfigurations. Keep every layer.
None of them governs the permitted move: the moment your most valuable data leaves on access you granted on purpose, in a pattern no allow-or-deny tool will stop because every step is allowed. That is not an edge case. It is the route data takes when it actually leaves, chosen precisely because it slips around tools built for bad actors instead of bad patterns.
Data movement governance does not replace EDR. It runs beside it. Falcon answers "is there an intruder on this host?" Hilt answers "is my data leaving on a move I should be looking at?" One lightweight collector watches data movement at the kernel, off the path, metadata only by default, single-tenant in your own cloud. It runs on the order of 0.1% of a core and 4 to 8 MB of memory, and the events never leave your account. When it resolves a move to an anomalous pattern, it writes the case and isolates the host at the network from the control plane. It never sits inline and never touches your traffic.
So the question is not whether CrowdStrike is good at its job. It is whether anything in your stack governs how data moves, while it moves, without reading your data. If you want to see where that line falls against your own environment, the next step is a 30-minute technical call.