Technical

CSPM Limits: Why Posture Management Misses Data Movement

June 8, 2026 Hilt 7 min

Your most valuable data leaves on access you granted on purpose, and cloud security posture management cannot see it. CSPM finds misconfigurations; it misses the dangerous pattern across permitted data movement at runtime.

CSPM Limits: Why Posture Management Misses Data Movement cover image

A compute instance can pass every CSPM check and still drain your customer database to an account you have never seen. The bucket is private. The security group is tight. Encryption is on. IAM follows least privilege. And the data leaves anyway, on credentials that were issued on purpose and worked exactly as designed.

CSPM checks the door. It does not watch what walks through it.

That is not a flaw in the tool. Configuration assessment is real work, and misconfiguration still drives a large share of cloud breaches. CSPM connects to your cloud provider APIs, enumerates resources, and grades current state against CIS benchmarks or your own policies. It flags the unencrypted RDS instance, the IAM policy that is too broad, the security group that left 0.0.0.0/0 open on port 22, the audit logging somebody disabled. It inventories what you own across accounts and regions, which is how you find the shadow estate nobody documented. Wire it into CI/CD and it catches the bad config before the deploy ships. Keep doing all of that.

None of it tells you where your data went.

Correct configuration is not the same as safe data

Your most valuable data leaves on access you granted on purpose. Every individual move is permitted, so every posture check correctly lets it through. The danger lives in the pattern across moves, and a static snapshot of resource state cannot hold a pattern.

A developer laptop gets compromised. The attacker reads cloud credentials out of environment variables. Those credentials open production databases and object storage, because that is their job. CSPM sees a clean estate the entire time: groups configured, policies scoped, encryption on. Meanwhile customer data leaves the account in a sequence that stopped looking like the workload weeks ago.

The audit log catches it, technically. The log shows authorized API calls from a legitimate identity, thousands of them, indistinguishable from normal until someone reads the whole trail by hand. By then the data is gone and the read is forensic.

Insiders never trip a posture check

An insider already holds approved access. The credentials work because they are supposed to work, so posture management has nothing to grade. This is structural, not a tuning problem.

It covers the malicious case and the careless one. The engineer who copies a production table to a personal bucket to test something. The contractor pulling more than the role needs. The admin moving a dataset somewhere it was never meant to sit. Every action runs on legitimate access against correct configuration.

Picture a quant shop. An engineer pulls trade data over months on their own database credentials, runs ordinary queries, exports results, stages them in company object storage, then ships them out. CSPM flags nothing across the whole arc, because nothing is misconfigured and nothing is unauthorized. The only signal is the shape of the movement: same identity, same access, moving more than it ever has, to a place it has never gone.

A snapshot cannot see an execution

CSPM polls. It grades configuration every few minutes to a few hours, and the gaps between scans are blind. An attacker who modifies a policy, acts, and reverts before the next pass leaves a clean snapshot on both sides of the window.

The deeper problem is not timing. CSPM reads resource state. It can confirm an instance is patched and network-isolated. It cannot say that data on that instance just started flowing to a destination the workload has never used. Staging for exfiltration, fanning out to a new external endpoint, draining a table in slow reads to stay quiet: as long as the instance stays compliant, posture management has nothing to report about any of it.

Watch the data while it moves

The blind spot closes only if something watches the one thing CSPM never reads: your data, in motion. Not the resource configuration. Not a log written after the fact. The move itself, as it happens.

Hilt calls this Data Movement Governance. One lightweight collector watches data movement at the kernel, the vantage where a move becomes visible no matter which workload, identity, or destination is behind it. It runs metadata only by default, so you govern the movement without reading your data. Content-aware inspection is there when you want it, never as the default and never required. The collector sits off the path. It does not sit inline, and it does not block, drop, or alter traffic. The overhead is checkable: roughly 0.1% of one core and 4 to 8 MB of memory.

From that vantage Hilt resolves each move to a probabilistic, source-dependent identity: which workload, which job, which path, where the data is going. Then it reads the pattern instead of the rule. A service that normally moves a small, steady volume to a few internal destinations starts moving far more to a place it has never sent data, and that is the anomaly, even though every credential and every permission is exactly as issued.

When the pattern is dangerous, Hilt isolates the host at the network from the control plane, quarantine. It catches the move as it forms, so you act while the data is still inside the account instead of reading the disclosure letter later. CSPM cannot reach this layer, because the attack runs entirely inside boundaries it already graded correct.

Run both

CSPM and Data Movement Governance answer different questions, and they sit well together. Hilt does not replace your CSPM.

CSPM closes the easy wins. It catches misconfiguration before exploitation, holds baseline hygiene, and produces compliance evidence. It shrinks the surface everything else has to defend. That is worth doing on its own.

Data Movement Governance picks up where correct configuration ends: the data still has to move, and the dangerous move looks identical to the permitted one. It surfaces stolen credentials being used to move data they should not. It surfaces insider patterns. It surfaces correct configuration being abused in ways no posture check is built to question.

They feed each other. CSPM flags a configuration change; the movement Hilt watches shows whether that change actually opened a new data flow. Hilt surfaces an anomalous move; the CSPM context shows whether the host was weakly configured to begin with. One reduces the surface. The other governs the data crossing whatever surface remains.

Perfect configuration does not keep your data put. The valuable moves run on access you granted on purpose, in the gap between how a system is configured and how its data actually behaves. CSPM lights up the configuration. Seeing the rest takes thirty minutes on a call with our team, where we walk through what watching data movement at runtime looks like in your own cloud.