A compromised process can lie to the tool watching it. They run at the same privilege level, so a process that has been tampered with can edit the logs it writes, hide from the API hooks, and feed a user-space agent a clean story while it ships data out the back. That is the reason security vendors moved their vantage point down toward the kernel, where the raw activity is harder to forge. eBPF is what made that move practical at fleet scale.
Kernel visibility is worth having. It is also where most of the conversation stops, and the harder problem starts one layer up: your most valuable data leaves on access you granted on purpose. A service account reads a customer table because that is its job. An analyst pulls a report because that is their job. A connected AI agent fans out across systems because you wired it to. Every one of those moves is permitted. eBPF sees each move clearly and flags none of them, because none of them is wrong. The breach is the pattern across moves, and a clean view of a single event does not surface it.
What eBPF sees
eBPF (extended Berkeley Packet Filter) is a kernel subsystem that runs sandboxed programs inside the kernel without a traditional kernel module. It started as packet filtering and grew into a general execution framework for observability, networking, and security. It is a technology, not a product. Security and observability vendors build on top of it.
The programs attach to kernel events: file operations, network sockets, process executions. When an event fires, the code runs in kernel context and inspects activity that user-space tools never touch directly. The kernel verifies each program before it loads, proving the code terminates, does not crash, and cannot corrupt kernel memory. Verification fails, the load is rejected. A buggy kernel module can panic a production host. A buggy eBPF program just refuses to load.
What that vantage point captures, the kernel observes rather than takes a process's word for:
Execution context. Command line, environment, parent process tree, user and group identity, the privileges a process holds. Not what the process claims about itself.
File access. A process reads a config file, opens a database file, writes to a log directory. The kernel resolves the operation, the path, and the access mode without trusting the application to log it honestly.
Network activity. Socket creation, bind and connect, where a connection is headed. The destination resolves before higher-layer encryption obscures the connection metadata.
What user space never gets to see. Policy denials, privilege escalations, boundary escapes. Much of this happens inside the kernel and emits no user-space event at all.
That is real coverage. The harder questions are not what the kernel can see. They are how much of it you keep, how you make sense of it, and what you do when a pattern crosses the line.
Why the no-module property carries over
For years, kernel-level security meant a kernel module. Modules hold full kernel privilege and direct memory access. One bug crashes production. Updates need careful testing and often a reboot. Different kernel builds need different modules. Managing those builds across a large estate is expensive and breaks in ways that are hard to predict.
eBPF removes that class of risk. One deployment runs across a fleet of varied hosts with no per-host recompile, and the kernel enforces the sandbox: a program cannot write arbitrary memory, call arbitrary kernel functions, or loop forever. The verifier proves those properties before the program runs. A bug fails at load time instead of corrupting kernel state.
In practice that is one lightweight agent per host, shipped the way you already manage your fleet, no module compilation and no reboot. That operational profile is exactly what a runtime data movement collector depends on. It has to be safe enough and light enough to run everywhere your valuable data actually lives, which is everywhere.
Where Hilt sits
Most teams already run endpoint agents, network monitoring, SIEM correlation, and application-layer security. CrowdStrike watches endpoints. Zscaler inspects egress. Proofpoint scans email. A SIEM ties it together. eBPF tooling pushes that visibility into the kernel. Hilt replaces none of it. Each of those tools catches what it is built to catch: known techniques, suspicious traffic, signatures that fire.
The gap they share is the permitted move. When data leaves on access granted on purpose, nothing is technically wrong. The credential is valid. The connection is allowed. The query is one the service account is supposed to run. EDR hunts the compromise of the endpoint, not the slow drift of a legitimate identity doing a little more each day. DLP guesses in advance, fires on the wrong things, and still misses the move that matters. Forensics arrives after the data is gone. This blind spot is universal, not a finance problem or an AI problem: every company moving valuable data across cloud, SaaS, endpoints, and AI agents has it.
Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, the one place the full picture sits, and it watches metadata by default, so it does not have to read your data to do its job. Content-aware inspection is there when you want it; you do not need it for the common case. The collector runs off the path, on the order of 0.1% of a core and roughly 4 to 8 MB of memory. It never sits inline. It never blocks, drops, or alters traffic.
The work is in what happens next. Hilt resolves each move to a probabilistic, source-dependent identity: which workload or which person, and the job behind it. Then it reasons across moves instead of scoring one event at a time. A move that is individually permissible can sit inside a sequence that is collectively a breach. That is the signal predictive tools cannot guess and forensics can only confirm too late.
Your bank does not block every charge or read your receipts. It flags the charge that does not fit your pattern, in time to stop the loss, without ever seeing what you bought. Hilt does the same for your data. When the pattern crosses the line, Hilt writes the case and responds with host-level network isolation from the control plane, quarantining the host at the network rather than filtering anything in line. The events stay inside your own account.
So the relationship is plain. eBPF is a vantage point, and a strong one. Seeing raw activity and governing where data goes are different jobs. Your existing stack tells you when something is broken. Hilt tells you when your own permitted access is being used against you, while it is happening, in time to act.
If you run kernel-level monitoring already and want to see where the permitted-move gap sits in your own stack, we can walk through it on a 30-minute technical call.