A misconfiguration is not an exploit. Teams that treat it like one watch the wrong half of the problem.
An exploit breaks a rule. A misconfiguration is a rule you wrote, by accident, that says this is allowed. A bucket policy with a wildcard principal. An IAM role whose trust relationship runs one boundary too wide. A service account that kept a read permission long after the project that needed it shipped. None of these is broken. They do exactly what they say. What they say is wrong.
So data leaving through one of them trips nothing. It cannot. Every transfer rides access you granted, on purpose, in a policy your tools read as permitted because it is. The move is permitted. The pattern is the breach.
What a posture scan tells you, and when
Cloud security posture management owns the first half of this cleanly. A CSPM tool reads your configuration and tells you the bucket is public, the role is over-broad, the key has not rotated. It runs continuously, maps the blast radius, and on a large estate it is the only sane way to keep the surface from drifting. If you do not run posture scanning, start there. Hilt does not replace it.
But look at what a posture scan actually is. A prediction. It says: if data moved through this path, that movement could be dangerous. It speaks about a possibility, before anything has moved. It ranks thousands of findings by theoretical severity, your team works the list from the top, and the list never empties.
The gap sits at the join between the prediction and the event. A scan tells you a door is unlocked. It does not tell you someone walked through it carrying what you most needed to keep. By the time a scan flags the misconfiguration, the question that mattered has already been answered, one way or the other, by whether anything moved through the door while it stood open.
The window nobody watches
Misconfigurations have a lifespan. Someone ships one in a deploy. It lives for hours, or weeks, until a scan catches it or a cleanup sweep closes it. All of the risk sits inside that window, and the window is exactly where posture tooling goes quiet. Posture tooling describes the door, not the traffic through it.
Here is the shape of it. A batch job's service account gets read on a data store. The grant is scoped too wide in the template, a copy-paste from an older role. For most of its life the account reads what the job needs and nothing more. Then, one week, the same account starts pulling whole prefixes it has never touched, at a volume it has never reached, toward an egress it has never used. Every one of those reads is permitted. The policy says yes to all of them. A posture scan that runs that day reports last month's finding word for word: role is over-broad. It cannot see that the role is now being used.
A possibility and an event are not the same thing. The whole problem lives in the distance between them.
Watching the movement, not the policy
Runtime data movement governance closes the join. It watches the half a posture scan cannot reach: the data actually moving, while it moves.
Hilt runs one lightweight collector at the kernel, metadata only by default, off the path. It does not sit inline. It does not read your data to do this. It costs about 0.1% of one core and 4 to 8 MB of memory per host. It resolves each move to a probabilistic, source-dependent identity: which workload, which service account, which job behind it, which destination, and whether this fits what that identity normally does. The misconfiguration set what is allowed. The collector records what happened.
So when the over-broad service account starts pulling prefixes it has never read, the deviation shows up across layers at once. The job is out of character for that identity. The access is a bulk read across high-value paths in a tight window. The egress volume looks like nothing in months of that account's history. Alone, each signal is noise inside a permitted grant. Stacked, they are a pattern, and a pattern is a case, not an alert. Hilt writes the case, and when the move warrants it, isolates the host at the network, quarantine from the control plane, never by touching the traffic itself.
The posture scan said the role was dangerous. The runtime layer says the role is being abused, this minute, by this identity, toward that destination, at this rate. One is a hypothesis. The other is what you act on.
Where this leaves your stack
Two halves of one problem, and no single tool was built to span both.
Posture management owns the configuration. It finds the misconfiguration before anyone touches it, keeps the surface from drifting, and tells you what to fix. That work sits upstream of everything here. Hilt adds to it. It does not stand in for it.
Runtime data movement governance owns the event. It watches whether data moved through the gap while the gap was open, resolves that movement to an identity and the job behind it, and catches the abuse as a forming pattern instead of reconstructing it later from logs. This is the half that turns a list of theoretical doors into the one someone actually walked through.
You want both. The misconfiguration you have not fixed yet is the one most likely to get used, and the only place to watch it being used is at runtime, on the movement. A scan can predict it. An audit can confirm it afterward. Neither catches it in the one moment you can still act.
If your stack can tell you a bucket is over-permissioned but cannot tell you what actually read from it last Tuesday between 1am and 4am, resolved to the service account and the job behind it and scored against how that identity normally moves, that is your gap. Bring the misconfiguration that has sat near the top of your list the longest, and we will walk through how the runtime layer fills it, engineer to engineer, in about thirty minutes.