Teams pit CSPM against CWPP as if the budget forces a choice. It doesn't. They answer different questions about the same cloud, and a mature program runs both, often inside one CNAPP. The useful question is where the line between them sits, and what falls past it on both sides.
There is a class of risk neither category was built to catch: the move you permitted on purpose, where the access is right and only the pattern is wrong.
CSPM reads the blueprint
Cloud Security Posture Management evaluates configuration. It reads the state of your cloud control plane, AWS, GCP, Azure, Ali Cloud, and checks it against a baseline you chose: a benchmark, a framework, your own policy.
CSPM catches the misconfigurations that turn into headlines. A storage bucket open to the public internet. A security group with port 22 exposed to the world. An IAM role carrying a wildcard it never needed. An encryption flag that drifted off after a hurried deploy. These are real and common, and CSPM is strong at them. Ask it whether the cloud is configured the way you intended, and it answers.
It does not watch the running workload. It reads the blueprint, not the building in use. A bucket can be configured perfectly and still get read by an identity with every right to read it, at a volume and cadence that should never happen. Nothing about the configuration is wrong, so CSPM stays quiet.
CWPP watches the building
Cloud Workload Protection Platform operates one layer down, inside the workload: the VM, the container, the host running your code. It hunts the things that compromise a running process. Vulnerable packages. Malware on disk. A process spawning a shell it should not. A container drifting from its image. Runtime behavior that matches a known attack technique.
CWPP catches the compromise of the machine. An attacker lands on a host and tries to escalate, install a tool, run something that does not belong, and this is the layer that sees it. Ask it whether the workload is behaving safely, and it answers.
It is built on one assumption: an attacker is doing something the legitimate user would not. That assumption is its strength against intrusion and its blind spot against the legitimate identity moving data it is fully entitled to move. Nothing about the process is broken, so CWPP stays quiet too.
What falls between the lines
Set the two side by side and the split is clean. CSPM checks the static state of the cloud. CWPP checks the dynamic state of the workload. Configuration and compromise. Both questions matter. Neither is the data question.
Your most valuable data leaves on access you granted on purpose. A researcher pulls proprietary code through an approved channel. A service account reads a customer table it reads every day, except this time it reads all of it. A contractor with standing access to a document store copies it in small off-hours chunks across two weeks. Every move is permitted. The configuration is correct, so CSPM is quiet. The host is clean, so CWPP is quiet. Every tool you own lets the data through, because every move was allowed.
No single move is the breach. The pattern across moves is the breach. The only place to see that pattern is at runtime, while the data moves: not in the configuration beforehand, not in the disclosure letter after.
The layer that watches movement
Hilt adds that layer, and it adds it. CSPM keeps posture. CWPP keeps workload integrity. Hilt watches the third thing: the data movement itself, resolved to who and what is behind it.
One lightweight collector watches data movement at the kernel, metadata only by default, off the path. It runs single-tenant inside your own cloud and never sits inline. The footprint stays small enough to live on latency-sensitive workloads, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It does not block, drop, or alter traffic, and it does not have to read your data to see that a pattern is wrong. Content-aware inspection is there when you want it. It is not the price of admission.
Each move resolves to a probabilistic, source-dependent identity: which workload, which job, which destination, and whether this fits what that identity normally does. The service account that reads a thousand rows a day reads the whole table at 2am toward an unfamiliar destination, and the deviation shows up across layers at once. The job is unusual for that identity. The read is a bulk pull of high-value paths in a short window. The volume is wrong despite the approved path. One signal alone is noise. Together they are a case, not an alert.
When the pattern crosses the line, the response is host-level network isolation, quarantine driven from the control plane. The collector watches the move and isolates the host. It never stands between your data and where it is going.
How the three fit
CSPM answers whether the cloud is configured correctly. It hardens the surface before anything runs. Run it. Hilt does not replace it.
CWPP answers whether the workload is compromised. It defends the running machine against intrusion. Run it. Hilt does not replace it.
Data movement governance answers whether the data is moving the way it should, given who is moving it and the job behind it. It catches the permitted move that forms into the wrong pattern, the thing invisible to a posture check and a workload check alike.
Posture and workload protection keep bad actors out and machines clean. Data movement governance starts from the opposite premise: the access was granted, the identity is real, the configuration is fine. Then it asks whether the movement makes sense. That is the question that decides whether your most sensitive data walks out a door you built and left open on purpose.
CSPM versus CWPP is not a versus. It is two layers of one defense, configuration and compromise, and a serious cloud program runs both. What both leave on the table is the data layer, not because either is weak, but because neither was designed to score the pattern of movement across permitted actions. That gap is structural, and it is where the expensive insider and third-party events live.
Put the test to your own stack. Can your posture and workload tools answer what this identity's data actually did, resolved to the job behind it and scored against how it normally moves, in this window? If not, that is the gap, and it is the one data movement governance closes.
If you want to see how the kernel-level collector sits alongside the CSPM and CWPP you already run, the next step is a 30-minute technical call, engineer to engineer, walking the architecture against your own cloud.