TL;DR:
- Microsoft confirmed it hands BitLocker recovery keys to authorities under valid legal orders. When the vendor holds the key, the vendor can be compelled to surrender it. That is a real sovereignty question.
- Encryption locks the disk. It says nothing about the authorized copy, the permitted export, the routine sync that carries your most sensitive data out while the credential checks out fine.
- Key custody is necessary and it is half the picture. The other half is the move itself, and the move is only visible at runtime, while it happens.
Microsoft hands BitLocker recovery keys to government authorities when served a valid legal order, sometimes with no notice to the customer. The lesson security leaders take from it is correct as far as it goes: hold your own keys, because a key in someone else's custody is a key someone else can be made to give up.
Then the data gets used, and the lesson runs out. Encryption answers one question. Who can read the disk at rest. It is silent on the question every breach actually turns on. Where is this data going right now, and does the move fit the job behind it.
The lock holds. The door is open by permission.
At-rest encryption earns its keep. A stolen laptop stays unreadable. A seized disk stays gibberish. Hold your own keys and that guarantee stays yours. None of that is in dispute.
Now decrypt the file to use it, which is what the access was granted for. The credential is valid. The session is authorized. The copy is permitted. So the lock did its job and stepped aside, and so does every other control built to stop unauthorized access, because there is nothing unauthorized to stop. The data is in the clear by design, and from there it goes wherever the permitted move sends it.
Key sovereignty does not touch any of this:
- An export far larger than this user or this service has ever moved before
- An authorized sync that quietly repoints to a destination no one has used
- A pull from a sensitive store at an hour and a volume the job behind it never needed
- An AI agent with broad read access moving data in a shape no human would
Read each line on its own and it passes. Read the lines together and they are the breach. Encryption at rest is the wrong place to stand to catch this, because the data is already decrypted for the access you granted before the move begins.
The pattern shows up while the data moves, or not at all.
Teams reach for two places to catch data loss. Both miss the permitted move.
Predictive tools, the DLP world, guess in advance which data and which actions are dangerous. They guess wrong often. They bury teams in false alarms. And they still wave through the move that reads like an ordinary Tuesday until you set it against context.
Detection and response tells you after. The data is already gone. What is left is forensics and a disclosure letter.
That leaves one vantage point: runtime, while the bytes are in motion. Not before, when you are guessing. Not after, when it is cleanup. At runtime a permitted move gives itself away, because you can hold it against the identity making it and the job it claims to serve, and watch it fail to match.
Data Movement Governance, the layer above the lock
Hilt works at runtime, in a category called Data Movement Governance. It adds to encryption. It does not replace it. Encryption keeps the disk unreadable to anyone without access. Data Movement Governance watches what the data does once access is legitimately granted and it starts to move.
One lightweight collector watches data movement at the kernel, the single vantage point where every move is visible whatever the application or protocol. It is metadata-only by default, so the privacy story stays short: you see that data is moving, where it is going, and whether the move fits, without reading the data. Content-aware inspection is there when a case calls for it. It is never the default and never required to do the work.
The collector sits off the path. It does not run inline. It does not block, drop, or alter traffic. Overhead is roughly 0.1% of one core and a few megabytes of memory, 4 to 8 MB resident, so it watches without becoming a tax on what it watches.
For each move the collector resolves a probabilistic, source-dependent identity: which user or workload, and the job behind the move. That context turns a permitted action into a signal you can read. A 50-gigabyte export is not suspicious by itself. A 50-gigabyte export by a service that has never moved past a few hundred megabytes, to a destination it has never touched, is the move worth surfacing.
When a move does not fit, the response is host-level network isolation, quarantine from the control plane, never inline interference with traffic. The host is contained at the network so the move cannot finish, and the events that justified it stay in your own account.
Holding both halves
Owning your keys and watching your own movement do different jobs, and you want both. One keeps the disk at rest unreadable to anyone without access. The other watches the data in motion under access that checks out. The BitLocker story is a clean prompt to look at both at once:
- Key custody: prefer architectures where you control key generation, storage, and access, so no vendor can be compelled to hand over what only you should hold.
- Runtime visibility: plan for legitimate access to move data in illegitimate ways, and put a layer in place that sees the move as it happens, in time to act.
- Single-tenant by design: keep the movement signal in your own cloud (AWS, GCP, Azure, Ali Cloud), so the visibility you gain is not a new place your metadata leaves.
- Staff for both: the people who reason about key management should reason about movement, because the exfiltration that costs you is rarely a picked lock. It is a permitted door opened at the wrong hour.
Access keeps spreading across cloud, SaaS, endpoints, and AI agents, and the permitted move keeps becoming the way valuable data actually leaves. Treat the key and the movement as one posture and you are watching both ends of it instead of one.
Frequently Asked Questions
Does controlling my own encryption keys solve data exfiltration?
It solves one part. It keeps data at rest unreadable to anyone without access, and it keeps that guarantee in your hands instead of a vendor's. It does nothing about data in motion under legitimate access, which is where most exfiltration now happens. The credential is valid, the move is permitted, the data is already decrypted by design. Catching that means watching the move at runtime, which is what Data Movement Governance adds.
How is data movement governance different from DLP?
DLP guesses in advance which data and actions are dangerous, which buries teams in false alarms and still passes the move that reads as normal in isolation. Data Movement Governance is runtime and behavioral. It watches the move as it happens, resolves the identity and the job behind it, and surfaces the move that breaks the source's own pattern, not a static rule.
Does watching data movement mean reading my data?
No. The default is metadata-only: you see that data is moving, where it is going, and whether the move fits, without inspecting contents. Content-aware inspection is there for the cases that call for it. It is never required to surface an anomalous move, and it is never the default.
Will a collector that watches data movement slow my systems down?
It sits off the path, not inline, so it does not block, drop, or alter traffic. Overhead is roughly 0.1% of one core and a few megabytes of memory, 4 to 8 MB resident. It watches movement without becoming a performance tax on the workloads it watches.
What happens when a move looks wrong?
The response is host-level network isolation, quarantine from the control plane, never inline blocking. The host is contained at the network so the move cannot finish, while the case that justifies the action stays in your own account. The response is decisive, and the collector never enters the path of your traffic.
If your key story is sorted and the movement story is still open, that is the conversation worth having. We can walk through how Hilt would see your data move, in your own cloud, on a 30-minute technical call.