A statistical programmer pulls case report data from the analysis environment to a working directory. She does it again the next day, and again the day after. Each pull is small. Each goes through the sanctioned interface. Each sits well inside the access her role was granted on purpose. Nothing she does should fire an alert, and nothing does. By the time her three oncology studies have bled into one near-complete copy of unblinded data, sitting in a directory a week before the readout, every control the CRO runs has watched it happen and called it work.
That is the move your stack cannot see. Not because it is hidden. Because it is permitted.
A CRO runs on permitted movement. Trial protocols arrive from sponsors. Enrollment and case report forms come from sites. Lab values, imaging, adverse event reports, and randomization data travel between the EDC, the safety database, the central lab, the biostatistics environment, and back out to the sponsor. The CRO exists to make those moves happen. So it grants access widely and on purpose: a clinical data manager touches dozens of studies, a biostatistician pulls from the locked database, a sponsor's monitor reviews records remotely. The access map is wide because the work is wide.
Auditors and sponsors interrogate that map in qualification audits. Who can reach what. Your IAM answers that one well, and it should. The question nobody asks, because almost no tool can answer it, is what the granted access did after it was used.
Your controls grade single events, not patterns
A mature CRO already runs serious controls. IAM decides who can reach which study. The EDC and the safety system log actions inside their own walls. DLP catches a patient identifier in an outbound email or a bulk export to a personal drive. Endpoint tools watch the laptops. A coordinator emailing a roster of subject names to a personal account fires, and it should.
Every one of those controls grades one event against a rule. Was this permitted. Did this match a signature. Is this destination on a list. They are sharp on the obvious case and blind to its opposite: the move that is permitted, runs through an approved channel, comes from a legitimate identity, and is wrong only as a pattern across many moves.
Go back to the programmer. No single export trips a volume rule. No destination is new. No identifier rides an email. Action by action, she is doing exactly what her role does every week. What is off is the shape across the moves: the breadth of studies touched in one window, the off-hours timing, the slow accumulation toward a full unblinded copy ahead of a readout, a destination volume that is unusual for this identity even through an approved path. Any one signal, alone, is noise. Stacked, they are a breach forming in plain sight.
You can only see that shape in one place: at runtime, while the data is moving. Not before, where predictive tools guess and mostly guess wrong. Not after, where the forensics and the disclosure letter live.
What it means to watch the movement
Hilt runs one lightweight collector that watches data movement at the kernel, metadata only by default, off the path. It does not sit between your data and where it goes, and it does not block, drop, or alter traffic. It does not read trial records or the sponsor's protocol to see that a pattern is wrong, which is the whole point when the data is PHI and the protocol is confidential property. Content-aware inspection is there when you want it. It is not the price of admission.
Each move resolves to a probabilistic, source-dependent identity: which user, which job behind the action, which destination, and whether this fits what that identity has done across months of real movement. When the accumulation forms, the deviation surfaces across layers at once: the breadth of studies, the timing, the destination volume for this identity. The system writes it up as a case, not one more line in the on-call queue. A case is something a clinical operations or security lead acts on. An alert is something they triage.
The collector is single-tenant inside your own cloud, on AWS, GCP, Azure, or Ali Cloud. Events never leave your account, which keeps the residency story clean for sponsor contracts and the regulatory regimes a trial already answers to. Its footprint runs near 0.1% of one core and 4 to 8 MB of memory per host. The validated environment does not have to fight it.
None of this displaces what a CRO qualifies on. IAM still decides who gets access to which study. Your EDC and safety system audit trails are still the system of record for actions inside them, and regulators expect them. Your DLP still catches the identifier in the outbound email. Hilt adds the one layer those tools were never built for: the behavioral pattern of movement across permitted actions, resolved to the job behind each move and scored against how your data normally travels. A CRO's entire operating model is granted access moving sensitive data between parties on purpose. The exposure living inside that model is a pattern problem, and a pattern is exactly what permission-checking cannot see.
The harder half of the audit answer
When a sponsor asks how you protect trial and patient data, the access map is the easy half. The harder half, the one most CROs cannot give, is whether you can show what the granted access did once it was used.
Ask your stack the real question. What did this programmer's movement do across these three studies, resolved to the job behind it and scored against how it normally moves, in the two weeks before the readout. If it cannot answer, that is your exposure. It is not negligence. It is the part of the surface your controls were never built to watch.
If you would rather be able to answer that than not, the next step is a thirty-minute technical call, engineer to engineer, on how the collector would sit in your environment and what it would resolve. No data leaves your account to find out.