A service account reads a database it is allowed to read. Minutes later, the same account opens an outbound connection it has never opened before. Your SIEM logs both events as authorized. Your network tool sees encrypted bytes leaving. Your endpoint agent sees a process doing what its permissions allow. Every tool you own waves it through, because each move, taken alone, is permitted. The breach is the sequence, and nothing in the stack is positioned to watch the sequence form.
The kernel is. It sits between your applications and your hardware, and every file a process reads, every connection it opens, every child it spawns has to pass through it to happen at all. The data cannot leave without the move, and the move cannot happen without the kernel. That is the one place where what is actually moving stays legible.
Most security tools never look there. They run in user space, as programs like any other, holding whatever permissions you granted them. They see what the operating system chooses to surface and what the network stack hands them after processing. An endpoint agent reads the interfaces. A network tool reads encrypted traffic. A SIEM reads the logs applications decided to emit. None of them sees the move itself.
Three things user-space tools cannot see
Encrypted traffic is the first. A network tool watching two services talk sees connection patterns, certificate validity, timing. It does not see the plaintext, not without inserting itself as a man in the middle and becoming the thing it is supposed to detect. At the kernel, the move is visible before a process hands it to encryption and after the kernel hands it back decrypted. What moved where stays readable.
Identity drift is the second. An attacker on a stolen token, or an over-permissioned batch job, works through an account that is allowed to read what it reads. User-space detection often catches the first access and then loses the thread. It does not notice that this account, today, is doing something it has never done. At the kernel, the move resolves back to the job behind it, and that is where the new behavior shows up against the old.
Ephemeral processes are the third. Containers start and exit in seconds. Functions execute and vanish. A short-lived process can read sensitive data, open a connection, and be gone before polling-based monitoring takes its next sample. Watching at the kernel catches the read and the outbound connection as they happen, not reconstructed from logs after the host is already cold.
What the vantage actually surfaces
The kernel does not hand you more raw events to drown in. It hands you the move, tied to who made it and why.
A process did something. Something spawned it, and it spawned something else. A web server that suddenly reaches out and pulls a remote script reads as a clean request in the application log and as a normal connection in the network tool. As a process lineage at the kernel, it reads as wrong.
A file was opened, read, written, or had its permissions changed. A service touches configuration it has never touched. A workload reaches data outside its lane. User-space tools see this only if filesystem auditing is enabled and parsed correctly. The kernel sees the operation either way.
A connection carried data out, and the same workload that opened it had, moments earlier, read a database secret. The application logs none of that unless someone wrote code to. The network sees encrypted bytes with no memory of what produced them. The kernel sees the read and the send as one chain, one account, one job.
What Hilt does with it
Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, single-tenant inside your own cloud, and resolves each move to an identity and the job behind it. That resolution is probabilistic and depends on the sources available, not a claim to label everything. The collector watches metadata by default, so it does not have to read your data to see the pattern. Content-aware inspection is there when you want it and never required to do the work.
The collector sits off the path. It is not inline. It does not drop, alter, or filter traffic, and it cannot, by design. Its footprint is small and checkable: on the order of 0.1% of one core and roughly 4 to 8 MB of memory. The work runs at full speed while the collector watches from the side. An observation point, not a chokepoint.
When a run of individually permitted moves adds up to a dangerous pattern, Hilt writes it up as a case, not another line in the alert queue: what moved, from where, by which job, in what order. If the case warrants a response, it isolates the host at the network from the control plane, a quarantine. It never reaches into the traffic to do so. The events never leave your account.
This is the third position between two bad ones. Predictive tools guess ahead of the move, fire on the wrong things, and still let the permitted one pass. Detection-and-response tools tell you after, when the data is already somewhere else. Watching the move itself, at runtime, catches the anomalous one while it is still forming.
Where it sits in your stack
Hilt can stand in for your endpoint sensor, and many clients retire their EDR once it is in place. Keep an EDR alongside only if you want the malware and intrusion layer too, since Hilt does not do malware, exploit, or live-intrusion detection. Your SIEM still correlates across systems. Your posture and network tools still do their jobs. Hilt covers the one move the rest let through on purpose, because the access was real.
The difference is what it depends on. User-space tools depend on applications behaving, logging honestly, emitting what they should. They parse those logs, inspect memory, read packets. The kernel vantage depends on none of that. It watches the operation that has to occur for data to leave, whether or not anything above it cooperates.
It also correlates across hosts that each look fine alone. When one account moves data in a shape it never has across a fleet, no single host raises a flag, but the fleet-wide pattern does. When a role reads data it never read across months of baseline, the application shows authorized access and the behavior shows the anomaly. Every move is permitted. The pattern is the breach.
Most stacks cover the application and network layers well. What they miss is a runtime view of the move, at the kernel, resolved to identity, at the moment a permitted action turns into the data you did not want to lose. Bring what you saw here to a 30-minute technical call, and we will walk through where that gap sits in your own environment.