A stolen credential breaks nothing. It walks through the door you propped open for your own automation. CI tokens, service-account keys, OAuth refresh tokens, personal access tokens: each one exists to move data without a human in the loop. That is the job. Leak one, and the attacker inherits a key every tool you own has been told to honor. The access is clean. The pattern of moves the key makes is the breach.
The whole stack waves it past
Your identity provider checks that the token is valid and unexpired. It is. Your secrets manager confirms the key is using scopes it was granted. It is. Cloud IAM evaluates the request against the policy on that service account, and the policy permits it, because you wrote that policy for the legitimate pipeline. DLP scans for content signatures and known-bad destinations, but the attacker is reading a bucket the token reads every day and shipping to a destination that looks like ordinary egress.
Nothing here is broken. Every layer answers the one question it was built to answer: was this request permitted? For a stolen-but-valid token the answer is yes, every time. That is the trap. A control that gates on permission cannot see a problem when there is no permission problem. The problem is behavior, and behavior is a different signal.
A leaked credential is the sharpest case of the universal blind spot. Every move is permitted. The pattern is the breach.
The token stays. The job changes.
A CI token tied to a build pipeline has a shape. It fires from known runner ranges, on a cadence set by commits and merges, reading a predictable set of paths, pushing artifacts to a predictable set of destinations, moving volume inside a stable band. No policy writes that shape down. It is just what the pipeline does, every day.
Steal the token and you keep the credential, not the shape. The same key reads paths the pipeline never touches, at hours it never runs, toward a destination it never pushed to, in a volume it never moved. Each request is authorized. Together they describe a job the token does not exist to do.
To catch that, you resolve the move back to the identity and the job behind it, then ask whether this move fits how that identity actually moves. That question lives at runtime, on the movement itself. The IAM policy only knows what is allowed. The forensic timeline only knows what already left.
At the kernel, the pattern is legible
Hilt watches data movement at the kernel, metadata only by default, off the path. From there it sees the move as it happens, whatever token signed it. The attacker controls the credential. He does not control the kernel's account of what the credential did.
Each move resolves to a probabilistic, source-dependent identity: which workload or service account, which job, which source paths, which destination, what volume, at what hour. That resolution turns a stream of individually authorized requests into a pattern you can read. No content inspection required. Hilt does not have to read your data to see that a token is behaving unlike itself. Content-aware inspection is there when you want it, never the price of admission.
So a leaked CI token pulling outside its lane deviates on several axes at once. The source is the build service account, but the access is a broad read of paths that account has never read. The destination is new. The volume sits well outside the band this token held for months. Take any one signal alone and a tuned environment shrugs it off as noise. Take them together and you have a pattern, and a pattern is a case, not an alert.
Isolate the host, not the request
When the case is real, Hilt responds with host-level network isolation, quarantine, from the control plane. The compromised workload is cut off at the network so the move cannot continue, and the written case hands your team the identity, the job, the paths, and the destination in one place.
This is the right answer for credential misuse, because you cannot gate the request inline. The collector never sits inline and never blocks, drops, or alters traffic. Drop a filter into the request path of a build pipeline and you have added latency and built a single point of failure on infrastructure that has to keep moving, which is exactly the control teams refuse, and rightly. Off the path, the collector watches the move without standing in it, then isolates the host once the pattern is a case. You stop the bleed by pulling the host off the network, not by inspecting every request the token makes.
That is why it can live on a production pipeline: on the order of 0.1% of one core and 4 to 8 MB of memory per host, single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud. Events never leave your account.
Ask your stack one question
Pick a CI token or service-account key that moves real data. Now ask your current stack: in the last 30 days, did this credential read a path it has never read, push to a destination it has never used, or move a volume outside its normal band, and if so, when, resolved to which job? If the only way to answer is to hand-reconstruct it from scattered logs after something has already gone wrong, the answer is forensic. It arrives after the data is gone.
Runtime data movement governance answers while the move is forming. It does not replace your identity provider, your secrets manager, or your cloud IAM. Those layers grant and scope access, and they do it well. Hilt covers the layer none of them was built for: the behavior of a valid key across permitted moves, scored against how that key actually moves, surfaced as a case in time to act.
A stolen credential is the right key in the wrong hands. You catch it when you stop checking the key and start watching what the key does.
If you have a service account or CI token you could not explain after the fact, that is thirty minutes worth spending, engineer to engineer.