A healthcare AI vendor moves patient data for a living. It pulls clinical records from a health system, lands them in a pipeline, turns them into features, feeds them to a model, returns a prediction. The BAA was signed. The access was scoped. The pipeline was approved. Every one of those moves was granted on purpose.
So the dangerous move and the routine one look identical. The data that makes your model worth anything leaves on access you handed out yourself.
The access is correct, so every tool waves it through
Healthcare AI security gets reviewed as a permissions question. Is the data de-identified. Is the bucket encrypted. Is the vendor in scope under the BAA. Does the access map to a signed agreement. For a working pipeline the answer is yes, yes, yes, yes. The data moves because it is supposed to.
Which is the gap. A tool that checks whether a move was permitted passes every move in a healthy pipeline, because the pipeline is built out of permitted moves. The danger is not one unauthorized read. It is the shape across many reads: which records, by which job, in what volume, toward which destination, against what that job normally does.
Your bank flags the charge that does not fit the pattern of your spending. It never decides each purchase is forbidden. The pattern is the signal. Patient data needs the same read.
Walk the path and watch where it leaks
A record passes through four places where movement looks routine and is not.
Into the pipeline. A training job that reads a fixed feature set every night starts pulling raw clinical notes, or reaches a cohort ten times its usual batch. The credentials are valid. The job is approved. The shape of the read changed and nothing flagged it.
Across the de-identification boundary. PHI is stripped before a model sees it. A broken transform, a new code path, a debugging shortcut routes identified records past the boundary they were meant to stay behind. The connection is allowed. The destination is internal. No rule was broken.
Out of the model. Models trained on patient data memorize some of it. An inference endpoint or an export job pulls more out of the model, or the store behind it, than any user should get. The endpoint is public on purpose. The traffic is sanctioned.
Into the next vendor. The stack is a chain: a labeling service, a GPU host, a hosted foundation model. Each handoff is a permitted egress to an approved party. The permission was right. Only the behavior across the handoffs tells you a copy went somewhere it should not have.
Four times the access control did its job. Four times the question worth asking is how the data moved, not whether it was allowed to.
A policy is checked twice and the breach happens between
Write another policy and you tighten the BAA, add a data-handling clause, require an attestation. Useful. Not a control. A policy states intent, and it gets checked at design time and at audit time. It is not checked while a training job is reading records at two in the morning.
Data loss prevention guesses in advance which moves are dangerous, fires on the wrong ones, buries the team, and still passes the permitted move, because by its own rules the move is fine. Forensics catch it from the far side: after the export, in the disclosure letter, when the records are already gone. For a healthcare AI vendor, "after" is a reportable breach and a notification clock already running.
The pattern is only visible in the middle. At runtime. While the data moves.
Governing the movement, not the permission
That is the layer Hilt adds. One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud. It resolves each move to a probabilistic, source-dependent identity: which job, which user or service, which destination, and whether this fits what that identity normally does.
For a healthcare AI vendor the resolution is the whole game. A training job reads a cohort; Hilt scores that read against months of how the job actually behaves. Records cross toward a third-party endpoint; Hilt weighs the volume and the destination against the baseline for that path. One unusual signal is noise. But the job is wrong for its identity, and the read is a bulk pull of high-value paths in a short window, and the destination volume runs high on an approved channel. Those line up. Lined up, they are a case, not an alert.
Hilt does not read your data to do this. Metadata only is the default, so it sees that a pattern is wrong without opening a clinical record. For a custodian of PHI that is the point. The control that watches the data does not become one more place the data sits exposed. Content-aware inspection is there when you want it. It is never the cost of entry.
And it stays off the path. The collector observes movement instead of standing in it, at roughly 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline. It does not block, drop, or alter traffic. When a pattern turns dangerous, the response is host-level network isolation, quarantine from the control plane, not a filter jammed between your model and your data.
What it does not touch
Your cloud posture tool still flags the misconfigured bucket. Your endpoint agent still catches known attack patterns on the box. Your access management still decides who holds the credential. They are good at what they cover, and Hilt replaces none of them. They judge permission and configuration. They were never built to judge the pattern of movement across permitted actions, which is precisely where patient data leaves a working pipeline. Hilt sits next to them and reads that pattern.
The question your stack should answer
Ask your current tools what a given training job's data actually did last night: the cohort it read, the destination it reached, scored against how that job normally moves, on the runs against the new model. If nothing can answer that, the most valuable data you hold can leave on access you granted, and the forensic report tells you first.
If that gap is worth thirty minutes, we will walk you through the kernel-to-case path, engineer to engineer.