Could you prove your data is untouched after a breach?

A leaked token gave attackers two months inside a pharma network. Everyone considered the data that were stolen. Almost no one asked about the data that remained.

‍

In March 2026, an attacker found a GitHub token sitting in a company's client-side JavaScript. It was scoped to hundreds of private repositories, had no expiry, and belonged to no one in particular. They used it to walk into the network and stay for roughly two months before anyone noticed.

By the time the pharmaceutical company disclosed the breach that June, the reported haul included source code, proprietary compound data, internal AI models, and clinical-trial records for around 11,500 patients. The coverage did what breach coverage does: it tallied the compromised assets - stolen patient records, exposed credentials, and leaked internal files.

But sit with the timeline for a moment. Two months of access to internal systems - not read-only theft, but a foothold deep enough to move laterally and harvest more credentials. And here is the question almost nobody asked out loud: for every record that wasn't copied, can anyone now prove it wasn't quietly changed? Not that it was. That no one can demonstrate it wasn't.

A clean dataset and a dataset you can prove is clean are two different things, and most days, nothing forces you to consider the gap. A breach forces it. So does a lawsuit. So does an inspection.

This isn’t just a security problem - the regulatory angle

For most companies a breach is a security incident. For anyone running regulated trials, it's also a data-integrity event - and the rules are explicit about what that means. Under 21 CFR Part 11 and EU GMP Annex 11, records supporting a regulated decision have to be attributable, contemporaneous, and verifiable: who did it, when, and provable that it hasn't been silently rewritten since. The audit trail is the mechanism that carries all three.

Which is why write access is the truly worrying part. Copying data is a confidentiality loss. Write access is a different animal: if an attacker could alter records, then proving they didn't becomes your burden, which you solve with the audit trail. So the real question is whether that trail could have been touched by the same access that touched the data.

How much has to go wrong - and yet how ordinary

The uncomfortable part of that breach isn't how sophisticated it was. It's how ordinary. A machine credential nobody governed, over-scoped far past what it needed, sitting in shipped front-end code. Once inside, the token could clone repositories and collect further credentials - the blast radius widening with each one.

And the severity of a leaked credential depends entirely on what it can reach. This is where architecture decides the outcome long before the attacker shows up:

• A narrowly-scoped, short-lived service token - the damage is contained to one function, and it expires.
• A developer credential - bad, but usually bounded by that person's role and reviewable against it.
• An over-permissioned token with broad write access - the case that turns a leak into a crisis, because it can reach both the data and, in most systems, the record of what happened to it.

That’s the whole problem. In many clinical systems the audit trail is a feature of the application - a table the application writes to, running on the same infrastructure the same privileged accounts administer. So the record of what happened and the thing that happened share a fate. Reach one, and you can reach the other. When that's the shape of your system, a single over-scoped credential doesn't just leak data - it obliterates the assurance that data hasn’t been tampered with and thus the validity of years of scientific work.

You don’t fix this with a better lock but a second tier.

You can rotate tokens, scope them tighter, scan build artifacts for secrets - and you should, all of it. But every one of those controls is an attempt to keep the attacker out. None of them answers the question that remains after someone gets in anyway: can you still prove the records are what they were?

Answering that requires a structural choice, not a tighter lock. You have to separate the record of what happened from the systems where things happen - so that no credential able to touch the data can reach the account that determines what was done to it. Two tiers, deliberately kept apart. It's the same principle behind a black box on an aircraft: the recorder is isolated precisely so that whatever happens to the plane can't rewrite the record of it.

This is how Carelane is built.

‍

The application tier is where the work happens, and every action in it - every creation, every edit, every access - is written to append-only collections: records can be created and read, but never updated or deleted, not even by an administrator. The audit trail isn't a log the application is trusted to maintain honestly. It's an immutable structure that can’t be altered.

The infrastructure tier sits beneath it, in a separate trust boundary with separately restricted access. It records every operation against the system, and it cannot be manipulated - not by an attacker, not by a developer, not by us, regardless of permissions. Switching it off isn't a silent option either: the attempt to do so lands in a record the attempt can't reach.

The point of the second tier isn't that it makes a breach impossible - nothing does. It's that it changes what a breach can take from you. Exfiltration is still serious; separation doesn't undo a copy. But integrity survives independently of the systems an attacker can reach, so the question "were these records altered?" has a demonstrable answer instead of a hope. The credential that reaches the data cannot reach the account of what it did.

In the worst case, an inability to demonstrate clean data doesn’t ruin years of work.

‍

How to tell whether you could actually prove it

You don't need a breach to find out where you stand. You need to run the drill before someone runs it for you. A concrete version of the exercise:

• Pick a real decision. Take the last significant call your team made on trial data - a dataset locked, a milestone filed, a model trained - and try to reconstruct the exact state of the underlying records at that moment.
• Ask who can edit the audit trail. List every role and credential that could alter or delete an audit record. If the answer includes an administrator, a DBA, or a cloud account - anyone - the trail can't independently vouch for the data.
• Check whether disabling logging is silent. If someone with sufficient access turned logging off for an hour, would you know afterwards? If the off-switch leaves no trace the switch itself can't erase, that's a gap.
• Find the direct write paths. Map every way a record can change without going through the application - migrations, scripts, direct datastore access. Each unlogged path is a place where "prove it" quietly becomes "trust us."

If those questions have clean answers, your integrity story will hold under scrutiny. If they don't, you know where you need to get to work - and it's far cheaper to do so now, while the only one forcing the question is you, than after a regulator, a plaintiff, or an attacker forces it for you.

Because the honest test is simple. If someone asked you tomorrow to prove the trial data behind your last major decision hadn't been altered - not assert it, prove it - the answer is either a record you can produce or a hope you can't. The time to decide which, is now.

‍