Most security thinking about crypto starts at the chain. Wallet hygiene, multisig thresholds, hardware security modules, signing policy. That work matters, and the firms that do it well rarely lose funds to a sloppy key.
The losses that end firms come from somewhere quieter. They come from the data that surrounds the keys: the ledger snapshots, the reconciliation exports, the customer records, the internal tooling that touches signing infrastructure. That data leaves on access someone granted on purpose. Every move is permitted. The pattern across moves is the breach.
The data that is not the key, and is the target
A digital-asset firm guards its private keys carefully because the threat model there is obvious. But the operational data around those keys moves constantly, and it moves on legitimate access.
An engineer pulls a copy of the ledger to debug a reconciliation discrepancy. A finance lead exports balances to build a board deck. An internal service reads from the signing tier to populate a dashboard. A support tool joins customer identity against on-chain addresses. None of this is exotic. All of it is permitted. And any of it, moved by the wrong identity at the wrong time to the wrong destination, is the early shape of a loss.
The attacker who has compromised a credential does not break the key. He uses the access that credential already has. He reads what that identity is allowed to read, and he moves it the way that identity is allowed to move it. The permission was correct. Only the behavior changed.
Why permission checks miss it
Most of the stack a crypto firm runs evaluates permission. Your identity provider asks whether this user may authenticate. Your cloud access policy asks whether this role may read this bucket. Your DLP asks whether this file class is allowed to leave. Each answers a yes-or-no question about a single move, and each answers it correctly.
The dangerous case passes all of them. The credential is valid. The role has the grant. The file class is one that legitimately leaves the company every day. No single move trips a rule, because no single move is the problem. The problem is the shape across moves: this identity, reading these paths, at this hour, in this volume, toward this destination, in a way it has never read them before.
That is not a permission question. It is a pattern question, and a pattern only exists at runtime, while the data is moving. Predictive tools guess at it in advance and drown teams in false alarms. Forensics reconstructs it after the funds are gone and the disclosure letter is being drafted. The shape is only visible in the moment the data actually moves.
Watching the move, not the chain
Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud. It does not sit between your data and where it is going. It does not block, drop, or alter traffic. It observes the move and resolves it to a probabilistic, source-dependent identity: which user or service, which job behind the move, which destination, and whether this fits what that identity normally does.
For a digital-asset firm that means the moves around the keys become legible without anyone reading the contents. The collector does not need to inspect the ledger to see that a service account which has read the signing-tier metadata twice a day for a year just read it forty times in an hour and opened an egress path it has never used. The job is wrong for the identity. The volume is wrong for the path. The destination is new. Any one of those signals alone is noise. Together they are a pattern, and a pattern is a case, not an alert.
Metadata-only is the default, and it is the answer to the obvious objection. A firm whose entire business is custody of value does not want a security vendor reading its data. Hilt does not have to. Content-aware inspection is available when you want it. It is never the price of admission.
Response that does not touch the path
When the pattern forms, Hilt writes the case and responds with host-level network isolation from the control plane: it quarantines the host at the network. It does not filter packets inline, and it never stands between a workload and the chain. For an infrastructure where a signing service stalling for even a moment is its own kind of incident, that distinction is the difference between a control you can run and one the infrastructure team will rip out. The collector observes the move rather than standing in its way, on the order of 0.1% of one core and 4 to 8 MB of memory per host.
Events never leave your account. For a firm reasoning about data residency under a regulator, the path from kernel event to written case runs single-tenant inside your own cloud, on AWS, GCP, Azure, or Ali Cloud. There is no vendor SaaS in the middle holding a copy of how your value moves.
The regulatory frame
Digital-asset firms increasingly operate under supervision that assumes you can account for the movement of sensitive data, not just the strength of your access controls. A New York custody license under NYDFS expects demonstrable monitoring of who touched what and when. The federal stablecoin framework under the GENIUS Act pushes issuers toward the same posture: you are expected to show that you would have seen the anomalous handling of reserve and customer data, in time to act, not just to attest that your permissions were configured correctly.
A permission audit shows the grants were right. It does not show the movement was normal. The two are different questions, and examiners are increasingly asking the second one. Runtime data movement governance answers it with the artifact that matters: a record of what each identity's data actually did, scored against how it normally moves, written up as a case rather than buried in a log no one reads until after the loss.
Where Hilt fits
Hilt does not replace your key management, your signing policy, or your HSMs. Those are the right tools for the threat at the chain, and they do their job. It does not replace your identity provider or your cloud access controls, which correctly answer the permission question move by move.
It adds the layer none of them were built for: the pattern of movement across permitted actions, resolved to the identity and the job behind it, seen at runtime while there is still time to act. In a business where the most valuable data leaves on access you granted on purpose, that layer is the one standing between a permitted move and the loss it turns into.
If your current stack cannot answer "what did this service account's data actually do over the last three hours, resolved to the job behind it and scored against how it normally moves," that is the gap, and it is worth a short, engineer-to-engineer conversation about how the collector sees it. Thirty minutes is usually enough to know whether it fits your infrastructure.