A researcher copies proprietary code to an approved cloud bucket, in small chunks, off-hours, over two weeks. The host is healthy. No malware ran. The credentials are valid, the channel is sanctioned, the user is who they say they are. Your EDR sees all of this and reports a clean endpoint. It is right. By its own question, the endpoint is clean.
That is the gap between the two letters. EDR asks whether an endpoint is compromised. DDR asks whether data is moving wrong. One machine can answer the first question yes and the second question no at the same moment, and most teams that own EDR assume it covers both. It does not.
What EDR sees, and where its edge falls
Endpoint Detection and Response watches the host. Process trees, memory, registry changes, persistence mechanisms, command-line arguments, known-bad behavior. When malware lands, when a process spawns a suspicious child, when an attacker escalates privilege or pivots to another machine, EDR is the tool that catches it. CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint are mature products, and any serious endpoint program runs one. Hilt does not replace that. If the threat is malware or an active intrusion, EDR is the answer and a data movement layer is not.
The frame is host integrity, and that frame has a hard edge. Go back to the researcher. Nothing about the machine changed. No rule fired, because integrity is intact and integrity is all an EDR rule reads. The danger was never the endpoint's state. It was the shape the moves made together: a bulk read of high-value paths, in a short window, to a volume the destination does not usually receive. Each move was permitted. The pattern is the breach, and a tool whose vantage is host integrity cannot see a pattern that lives in the data.
This is not an EDR miss. It is a category boundary. "Is the machine compromised" and "is data moving wrong" are two questions, and EDR was built to answer one.
What the data movement layer reads instead
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read content to do this. It does not have to read your data to see that a pattern is wrong. Each move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, scored against months of how data actually moves in your environment.
When the researcher copies the code, the deviation surfaces across layers at once. The job is unusual for that identity. The access is a bulk read of sensitive paths in a tight window. The destination volume runs high even though the channel is approved. One signal alone is noise. Together they are a pattern, and a pattern is a case, not an alert. The endpoint stays clean and the data still leaves wrong. The data movement layer reads the second thing, and it sits next to your EDR rather than on top of it.
The split is clean once you say it plainly. EDR's signal is the host's behavior. DDR's signal is the data's behavior. The same endpoint produces both, and one tool was not designed to read the other. An attacker who breaks into a machine trips EDR. An insider, a contractor, or a third party operating entirely inside granted permission trips nothing, because the machine is fine. That case lives in the data movement layer or it lives nowhere.
The agent on the host
Endpoint teams are wary of another agent, and they have earned the right to be. Overhead is the veto that kills most additions to the host, and on latency-sensitive infrastructure the security team does not get to override it.
A collector that stays off the path changes the math. Hilt runs at roughly 0.1% of one core and 4 to 8 MB of memory per host, single-tenant inside your own cloud, never inline. It does not sit between your data and where it goes. It does not block, drop, or alter traffic. When it finds a dangerous pattern, it responds with host-level network isolation, quarantine, from the control plane. It observes the move instead of standing in its way, so the cost of adding the data movement layer to a machine already carrying an EDR agent is close to nothing. That is usually the real reason teams tolerate partial coverage here: they fear stacking a second heavy agent. An off-the-path collector does not stack that cost.
Questions that cut to it
If you are deciding whether your EDR already covers the data movement question, a few questions settle it fast.
Does the tool evaluate host integrity, or the data's behavior? If the answer is integrity, it is doing EDR's job, and the permitted-pattern case sits outside its frame by design.
What fires when a legitimate user moves data wrong? Walk the slow, sanctioned-channel exfiltration. If nothing about the host changes, name the tool in your stack that would catch it.
Where does the data movement tool sit relative to your traffic? Off the path, observing, is a different architecture from inline. It changes your latency exposure and your single-point-of-failure profile. Ask how it responds: quarantine from the control plane, or inline filtering.
Does it read your data? Metadata only by default means the system flags the wrong pattern without inspecting content. Content-aware inspection is there when you want it, not the price of admission.
Where does the data stay? Kernel event to written case should run single-tenant inside your own cloud: AWS, GCP, Azure, or Ali Cloud. Events should never leave your account.
Where this leaves you
EDR and DDR are not competitors and not redundant. EDR asks whether the endpoint is compromised and answers it well. DDR asks whether data is moving wrong, on access you granted on purpose, and answers a question EDR's frame cannot reach. Your most valuable data rarely leaves on a compromised host. It leaves on a healthy one, through a permitted channel, in a pattern no permission check would stop.
Ask your EDR what a user's data actually did between 11pm and 2am on three specific dates, resolved to the job behind it and scored against how that data normally moves. If it cannot answer, that is not a flaw in the EDR. It is the data movement layer, and it runs beside what you already have.
If you want to see where the collector sits and what it surfaces beside an existing endpoint stack, the fastest path is an engineer-to-engineer call, about 30 minutes.