A workload is permitted to read your customer table. At 2am it reads far more of that table than it ever has, then opens a connection to a host it has never talked to and pushes the data out of your account. Your cloud workload protection platform stays silent the whole time. The image passed its scan. The IAM role is exactly as scoped as you intended. No configuration drifted. By the checks a CWPP runs, nothing happened.
That is the gap. CWPP grades the workload before it runs and while it sits still. It does not watch what the workload does with your most valuable data once it is live.
A CWPP earns its place. It catches the public S3 bucket, the IAM role with * on it, the security group open to 0.0.0.0/0, the container shipping a vulnerable dependency. All of that closes real exposure. All of it happens before runtime or in a batch scan after the fact. None of it sees a running workload move a sensitive dataset somewhere it has never gone.
The blind spot is not a finance problem or a healthcare problem. It is universal. Across cloud, SaaS, endpoints, and AI agents, your most valuable data leaves on access you granted on purpose. Every single move is permitted, so every tool you own correctly lets it through. The danger lives in the pattern across moves, and the pattern is only visible at runtime, while the data moves.
Where CWPP stops
Configuration scanning reads your infrastructure as code and flags mistakes before they reach production. Vulnerability scanning checks images and disk snapshots against known CVEs and blocks the build. Compliance checks compare your settings to CIS benchmarks or PCI-DSS and emit a report. These are different jobs, and a CWPP does all three well.
Each one answers a question about state, not behavior. Is this configured correctly. Does this image carry a known flaw. Does this match the benchmark. Useful questions, all asked before the workload processes a single real request.
The question a CWPP never asks: this running workload just read a sensitive store at a volume it never touches and is sending it to a destination it has never used, is that fine. It cannot ask, because it is not watching the data move. It is watching the configuration that permits the move, and the configuration is correct.
The permission was right. Only the behavior changed.
Breaches do not live in your Terraform. They live in what running workloads do with the data they are allowed to read.
The hard case is not an outside attacker tripping a wire. A compromised credential, an integration reaching past its intended scope, an over-permissioned AI agent following a poisoned instruction: to a configuration scanner these are indistinguishable from normal work. Permitted access. Valid identity. Allowed path. The exploit changes nothing the scanner can see, because the scanner only sees what is allowed, and the move was allowed.
Containers make this sharper. The image is immutable; the running container is not. You scanned a known artifact. What is executing now can be steered into reading data far outside its normal pattern or pivoting deeper into your estate, and the data leaving it does not announce itself. A perfectly configured CWPP watches that sequence and reports a clean bill of health, because by its own definition of clean, the workload is.
What it takes to see the move
To catch a breach as it forms you have to watch the data while it moves, at runtime, at the one place every move is visible before it leaves the host. That place is the kernel. Every read, write, and outbound connection a workload makes passes through it, whatever language or framework produced the workload.
This is not more scanning. It is a different layer: runtime Data Movement Governance. CWPP governs configuration. DMG governs movement. One lightweight collector runs on the host and watches data movement at the kernel, metadata only by default, off the path. It never sits inline, never blocks or alters traffic, and never needs the contents of your data to do its job. Content-aware inspection is there when a case warrants it. Metadata is the default, so in normal operation you do not read your own data to watch it move.
Off the path is a measurement, not a slogan. The collector runs at roughly 0.1% of one core and 4 to 8 MB of memory, because it observes rather than intercepts. It adds nothing to the workload's request path.
What it observes is what makes the move legible. From the kernel, each move carries the process and its lineage, the dataset touched, the destination, and the identity and the job behind it. That context lets Hilt resolve a move to a probabilistic, source-dependent identity: a real actor and the work it claims to be doing.
Hilt baselines across overlapping frames. The individual workload. The role it plays, every web server, every database instance. The broader estate. A move that is routine for one role is an outlier for another. New moves get compared against the learned pattern, not against a static rule that a permitted move will always pass. A single move in isolation is usually nothing. A sequence that does not fit how this workload behaves is the signal. The compromised workload that reaches for a store it rarely touches and then pushes that data outward stands out against its own history, even though no step broke a rule.
Watching at the kernel, costing nothing
Runtime visibility for cloud workloads only matters if it stays cheap. Run thousands of containers across hundreds of nodes and any monitoring layer that taxes the request path is a layer your teams turn off the first time it shows up in a latency graph.
The collector is built to disappear into the host. It watches data movement at the kernel from off the path, on the order of 0.1% of one core and 4 to 8 MB of memory per host. No inline position, so no latency added to the traffic it observes. It is single-tenant and runs inside your own cloud, across AWS, GCP, Azure, or Ali Cloud, and the events it produces never leave your account.
When a sequence of moves does not fit the pattern, Hilt does not throw a raw alert over the wall. It resolves the move to an identity, writes the case (the what, the who, the job behind it), and, when the pattern warrants, responds with host-level network isolation, quarantining the host from the control plane. The collector never blocks, drops, or alters traffic. Isolation is a deliberate control-plane action on a written case, not an inline filter guessing in real time.
Pattern beats signature on attacks nobody has named yet. A technique no catalogue has seen still has to move data: read a sensitive store, send it somewhere. The exploit does not matter if the movement deviates from how the workload normally behaves. Hilt watches the shape of the data movement, not a list of known-bad signatures, so it does not have to have seen the attack before to notice the workload is behaving unlike itself.
It does not replace your CWPP
Runtime Data Movement Governance is additive. It fills the gap a CWPP leaves; it is not a rip-and-replace of anything in your stack.
A CWPP keeps misconfigurations out of production. Hilt watches how data moves on correctly configured systems, where every access is permitted and the only signal is the pattern. EDR covers malware, exploits, and live intrusion on endpoints. Hilt can stand in for an endpoint sensor on data movement, and many clients retire their EDR once Hilt is in place; keep one alongside only if you want that malware-and-intrusion layer too. CSPM and posture tools score configuration risk. Network and email controls inspect their own traffic. Each solves a real problem. None of them resolves a permitted data move to an identity and judges whether the move fits.
Your SIEM correlates all of it. The CWPP feeds it configuration events. The WAF feeds it request anomalies. Hilt feeds it the one thing none of the others produce: a case of anomalous data movement, already resolved to an actor and a job, written up instead of dumped as a raw alert. The overlap is small because each tool answers a different question at a different layer. Is the configuration sound. Is the endpoint compromised. Is the data moving the way it should. Hilt answers the last one, at runtime, on the movement itself.
The workload quietly moving your most sensitive data somewhere it should not go does not trip your image scanner and does not violate your configuration policy. It deviates from how that data normally moves. Cloud workloads scale up and down, shift between nodes, and live for minutes inside ephemeral containers. Static scans cannot follow that. A layer watching data movement at the kernel can, because it lives where the workload lives, and it turns the deviation into a case in time to act on instead of a disclosure letter after the fact.
If your CWPP is solid and you still cannot answer "where is this data going right now," that is the gap worth thirty minutes. Book a 30-minute technical call and we will walk through it on your workloads.