Your card clears in a city you have never visited. Valid card, right PIN, every check green. Then your phone buzzes: "Did you just spend $900 in Lagos?"
Nobody read your receipt. The bank has no idea what you bought. It knows the charge does not fit how you spend, and that was enough to freeze it.
Run that same logic against the data leaving your company. Your most valuable records leave on access you granted on purpose. Every move is permitted, so every tool you own correctly waves it through. The breach is not any one move. It is the pattern across them, and the only place to catch the pattern is at runtime, while the data is moving. Fraud detection already solved this for money. The data version barely exists yet.
The bank makes three choices your data tools do not
Start with what the bank refuses to do. It does not re-check the rules. It already knows the card is yours and the charge is authorized, so it asks a different question: does this look like you? Most data tools never get past the first question. User allowed, channel approved, file shareable, move waved through. A valid card in Lagos passes all three. So does an analyst exporting a client book the week before he resigns.
The bank also acts while the charge is live, not in next month's statement. A statement is forensics. By the time you read it the money is gone and you are filing a dispute. Most data security lives in that statement: logs you query after an incident, a disclosure letter after a breach. The flag is worthless a month late.
And it reads none of your mail. The bank sees amount, merchant category, location, time, device, and how those compare to your baseline. It catches the bad charge without ever knowing what you bought. The signal lives in the shape of the move, not its contents. That last choice is the one most products marketing themselves as "detection" quietly break the moment they need to read your files to work.
What the data version watches
Hilt is runtime data movement governance, and it makes the same three choices against the data leaving your environment.
It watches at the kernel, below the applications, where the move actually happens. Each move resolves to a probabilistic, source-dependent identity: which user or service, which job behind it, which destination, whether this fits what that identity normally does. Call it the amount, merchant, location, and device of a data move, scored against a baseline. No single field is the verdict. The pattern across them is.
It watches metadata by default. To see that a move does not fit, Hilt does not read the bytes leaving, the same way your bank does not read your receipt. Content inspection is there when you want it. It is never the price of admission and never the default. Put this in front of a team under HIPAA, NYDFS, or attorney-client privilege and the math changes: one control legal will actually let near the data, instead of one it bans on sight. You get the flag without the exposure.
It watches off the path. The collector does not stand between your data and where it goes. It observes the move instead of sitting in it, on the order of 0.1% of one core and 4 to 8 MB of memory per host, single-tenant inside your own cloud. Events never leave your account. No tollbooth on every transaction.
The move that clears every check
Here is the valid card in Lagos, in data.
A service account that legitimately syncs records to a partner API starts sending more than usual. New destination, not blocked. A window when that job almost never runs. Pull any field on its own and it is fine. The account is authorized. The endpoint resolves. No policy breaks, so the permission-checking stack has nothing to flag. The charge clears.
Runtime data movement governance never asks whether the move was permitted, because it was. It asks whether the move fits. The job is unusual for that identity. The volume is unusual for that channel. The hour is unusual for that pattern. The destination is unfamiliar. Each one alone is noise. Stacked, they are a pattern, and a pattern is a case, not an alert.
Permission tools were never built to see this. Not carelessness. Checking permission and modeling behavior are different machines. One confirms the card is valid. The other notices it is being swiped in a city you have never visited.
Where the analogy breaks
Be honest about where the model stops, because a hostile reader will find the seam first.
A bank can decline the swipe inline. It owns the rails. Hilt does not own your network and does not pretend to. It never sits inline, never blocks, drops, or alters traffic, never becomes a single point of failure on the path your data travels. When the pattern is a breach, it isolates the host at the network, quarantine, from the control plane. That is the bank freezing the account, not declining one swipe. It contains the host the movement is coming from without ever having stood in the middle of your traffic.
Scope is the other seam. Fraud detection has one dimension that really counts: money out. Data has many. A move can be wrong by who, by which job, by how much, by where to, by when, across cloud workloads, SaaS, user endpoints, and the AI agents now moving data on access you granted them on purpose. The baseline is wider, and it sharpens as it sees more of how your data moves, the way a fraud model knows you better the longer you bank with it.
The question to put to your stack
Your bank protects you without reading your mail. It catches the charge that does not fit by watching the shape of the move, while the move is live, on metadata alone. Behavioral, not permission-based. At runtime, not after. Metadata, not content. That is the combination that closes the blind spot permission-checking tools leave wide open.
So point the fraud question at your own data. A permitted identity moves your most sensitive records, through an approved channel, to a new destination, at an unusual hour, in volumes that do not fit its history. Does anything notice while it is happening? If the honest answer is "we would find it in the logs later," you do not have a fraud alert. You have a statement.
Want to see how this maps to your environment? It is a 30-minute call, engineer to engineer, no deck. We walk the kernel-to-case path on a move that looks exactly like one of yours.