A container passes every scan. Zero CVEs, current OpenSSL, a green CI pipeline. At 3am it ships a customer database to a destination no one has seen before, because a token that was scoped to read one table now reads the whole estate. The image was clean. The data still left.
Scanning answers one question: what could be exploited before this runs. It says nothing about what a workload does once it is live. That is the question that decides whether you lose data in Kubernetes, and the image scanner never gets to it.
The valuable data in a cluster leaves on access someone granted on purpose. Each move is permitted, so every scanner, every policy gate, and every CVE feed lets it through. The breach is not any one move. It is the pattern across them. You can only see that pattern at runtime, while the data is moving.
What container scanning cannot see
Container scanners parse manifests, check package databases, and match against CVE feeds. They are static tools. They never watch a running workload, and they never watch data move.
Code execution does not require a vulnerable binary. An attacker who lands through a deserialization bug uses the application's own interpreter: a Java pickle through java, a Python payload through python3. Both binaries are legitimate. The scanner has no opinion about what they read and where they send it once the container starts.
Supply chain attacks defeat scanning the same way. The package version matches upstream. The checksum validates. The scanner compares against the compromised upstream and sees nothing, because the malicious code is already what upstream ships.
Configuration is no better. A container running as root with privileged: true and host networking is a different animal than an unprivileged one with a read-only filesystem. A scanner may flag the capability. It does not watch whether that capability gets used to read node secrets and carry them off the node.
None of this is specific to a vulnerability class or a clever attacker. Any company moving valuable data across cloud workloads, SaaS, user endpoints, and AI agents carries the same exposure. The move that hurts is the one that was allowed.
Three places runtime tools watch, and what each one loses
Runtime security observes containers while they run instead of before they ship. Where a tool sits decides what it can see and what it costs you.
Application instrumentation hooks the language runtime: JVM, .NET CLR, Node.js. It sees application events and misses everything in native libraries and spawned processes. It also wants a separate agent per language, and the compatibility tax compounds.
Network taps read traffic at the CNI layer. They see connections and protocol data and cannot tie any of it to the job that caused it. A suspicious DNS query does not tell you which workload made it, which identity stood behind it, or what data left.
The kernel sees all of it. Every file a container reads, every connection it opens, every process it spawns becomes visible at the lowest common layer in the stack, before application-layer encryption or obfuscation, for every container on the node, with no per-language agent.
That vantage is necessary, not sufficient. Raw activity is the easy half. The hard half is making it act-on-able: resolving each move to the identity and the job behind it, and catching the moment a run of individually permitted moves adds up to exfiltration.
Where Hilt fits
Hilt is runtime Data Movement Governance. Not a scanner. Not another behavioral alerter that adds to the queue. It is the layer that watches your data move and tells you, while the move is still in flight, when the pattern is wrong.
One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant in your own cloud. Off the path means it never sits inline and never blocks, drops, or alters traffic. Metadata only means it reads how your data moves without reading the data, the way your bank flags a charge that does not fit without knowing what you bought. Content-aware inspection is there when an investigation calls for it. The default stays metadata, because the shape of a move is enough.
You can check the footprint yourself. The collector runs at roughly 0.1% of one core and 4 to 8 MB of memory per host. It reads the same cluster metadata your other tools read, so a move resolves to "the payments service in prod-web-1, acting as this identity, reading this class of data," not "process 1847 in an opaque cgroup."
Resolution is probabilistic and source-dependent. Hilt does not claim certainty it cannot have. It resolves each move to the most likely identity and job the host can support, and it sharpens as the picture fills in. The honesty is the point. A case you can defend beats an alert you cannot.
When a pattern crosses from unusual into dangerous, Hilt isolates the host at the network from the control plane, and the move stops. No inline seat. No packet filtering. It quarantines the host and writes the case, so a human sees what happened and why it was unusual.
What runtime governance catches
Watching at the kernel means seeing the mechanism of a move, not the artifact it leaves. The cases below are about data movement, not signatures.
A reverse shell matters to Hilt for what moves after it, not because /bin/bash spawned. A web service that opens an outbound channel and starts streaming a data store has changed the shape of its movement. Which bug opened the shell does not matter. The move does.
Credential theft reads as a shift in what an identity touches and where it sends it. A workload that normally hits one table starts pulling service-account tokens and connection strings and moving them off-cluster. Every access is permitted. The pattern is not.
Lateral movement and staging read as data converging where it should not. A database container that begins reaching across the internal network, or a job that pulls from many sources into one and then opens a path out, has broken from how it normally moves data. Hilt watches the convergence form before the final move out.
Slow exfiltration is the case both scanners and after-the-fact forensics miss. Data leaves in small, dull moves over hours or days, and no single move breaks a rule. The aggregate is visible only across moves, at runtime, while you can still act.
Runtime data movement governance does not replace container scanning. Scanning keeps known vulnerabilities out of production. Governance watches what live workloads do with the data you trusted them to handle, and catches the move that was permitted and wrong. You want both. They cover different ground. Only one of them sees your data move.
Want to see it against your own cluster? We walk through it in a 30-minute technical call.