A supply-chain compromise does not break in. You invite it in. You add a package to a manifest, pin a version, ship it to production. From that moment the malicious code runs with the exact access of the process that imported it. It reads the files that process reads. It opens the connections that process is allowed to open. Every data move it makes is permitted, because the permission belongs to the host, not to the intent behind the code.
So the package is signed. The build is reproducible. The dependency passed review six months ago. Nothing about the artifact is wrong. What is wrong is what the data does once the artifact is running.
Scanning answers the wrong question
The first instinct is to catch the bad dependency before it ships. Software composition analysis, signed provenance, SBOM diffing, registry reputation: all of it does that, and all of it is worth running. It catches known-bad versions, typosquats, packages whose provenance does not match their source. When a published CVE lands, it tells you which builds carry it.
That is real coverage. Hilt does not replace it, and a team without it is exposed in ways runtime governance will not fix.
But a scanner asks whether the artifact is known to be bad. It cannot ask whether the data this process touches is behaving the way it should. A dependency clean at install time gets weaponized by a later update. A package benign in nine hundred environments turns malicious only in the one where it finds a CI secret. The most expensive cases never reach a feed at all, because the attacker built the package for one target and published the payload nowhere a scanner could learn it. When the artifact is unknown-bad, the scanner stays quiet. The data still walks out.
Why the moves look permitted
Picture a build agent in your CI environment. It imports a few hundred transitive dependencies to compile and test a service. One of them, three levels deep, was updated last week to read environment variables and post anything that looks like a token to a remote endpoint.
The operating system sees nothing unusual. The build process is allowed to read its own environment. It is allowed to make outbound connections, because it pulls from package registries and pushes artifacts to storage. The malicious read is a permitted read. The malicious connection rides a channel the process uses legitimately a hundred times a day.
No policy is violated. No signature is missing. The exfiltration is a string of individually authorized actions, and that is the whole point of a supply-chain compromise: it never breaks a rule, because it inherited a rule that already lets it through. Every move is permitted. The pattern across the moves is the breach.
Seeing the pattern while it forms
The only place to catch this is at runtime, while the data is moving, on the movement itself. Not before, where a predictive tool guesses which package might go bad. Not after, in the forensic timeline that reconstructs the theft from logs once the data is already gone. In between. Live. On the move.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not sit between the build agent and the network. It does not read the contents of what moves to do its job. It resolves each move to a probabilistic, source-dependent identity: which process, descended from which job, reaching which destination, and whether that fits what this identity normally does.
A transitive dependency starts reading credential paths it never touched across months of history. It opens a destination no build on this host has ever contacted. It runs on a schedule that matches no pipeline. The reading process is wrong for its lineage. The accessed paths are high-value and out of pattern. The destination is new for this identity. Any one signal alone is noise. Together they form a case, not an alert.
The case names the process, the job that spawned it, the data class it reached for, and where it tried to send it. A responder reads that and knows what happened without first reverse-engineering a dependency tree.
Why a build host can actually carry this
Supply-chain exfiltration lives where teams are most reluctant to instrument: CI runners, ephemeral build hosts, production services that cannot tolerate added latency. A heavy agent that sits inline is a non-starter there. It slows the path, and it becomes one more thing that can fail in the middle of a deploy.
A collector that stays off the path removes that objection. Hilt runs at roughly 0.1% of one core and 4 to 8 MB of memory per host, single-tenant inside your own cloud across AWS, GCP, Azure, or Ali Cloud. It never sits inline. It never blocks, drops, or alters traffic. It watches the move instead of standing in its way, so a build agent or a latency-sensitive service carries it without paying for it. Events never leave your account.
When the pattern resolves to a confirmed case, the response is host-level network isolation from the control plane: quarantine the affected host, so the data has nowhere to walk to. The collector never stood between the process and its traffic to do it.
Where this fits next to what you already run
Keep your composition analysis. Keep signed provenance. Keep SBOM diffing. They close the front door against known-bad and mis-provenanced packages, and that is a different job than the one runtime governance does. Hilt is additive. It does not vet the artifact and it does not replace the scanner.
What it adds is the layer those tools were never built to cover: the data behavior of code you already accepted, running with access you already granted, after the package cleared review. A dependency that turns malicious on its next update, or was malicious all along for your environment specifically, announces itself in no feed. It announces itself in how the data starts to move. That is the move Hilt is watching.
Ask your current stack a plain question. Did any process in this build, resolved to the dependency lineage behind it and scored against how data normally moves here, start reaching for credentials it has never touched and sending them somewhere it has never sent? If the stack cannot answer, the supply-chain gap is open, and it is exactly the gap a compromised package is built to live in.
If you want to be able to answer it, that is a thirty-minute technical call, engineer to engineer. No slideware. Just how the collector sees a move and resolves it to the job behind it.