Johns Hopkins breach shows why *shadow AI* is an evidence problem

What happened at Johns Hopkins

On 15 January 2025, Johns Hopkins Bayview Medical Center in Baltimore reported a data breach involving 841 patients ^[1]. A staff member had uploaded a spreadsheet containing patient information to a publicly available AI website. The hospital said it had no evidence that any data was misused, but the information was disclosed to an unauthorised third party.

It's the kind of incident that happens when someone wants a quick answer and reaches for the nearest tool. The spreadsheet goes in, the AI does something with it, and then it's out there. The hospital found out and reported it. What it couldn't show is exactly what went in, when or to which site, because the upload happened outside the systems the hospital controls.

Shadow AI is the filing cabinet left open

Shadow AI means employees using external AI tools—public chatbots, summarisers, translators—that the organisation knows nothing about. It's like someone photocopying a sensitive file and leaving the copies on a bench outside. You have no log of what was copied, who took it or where it went.

The problem isn't that AI tools exist. Many of them are useful. The problem is when sensitive data flows into them without the organisation having a record, a control or even a way to know it happened.

In healthcare, it's especially tricky. Patient records are protected under laws like GDPR in Europe and equivalent rules in the US ^[2]. Sweden's Patientdatalagen requires that access to patient records is documented ^[3]. Shadow AI use bypasses all of that. There's no entry in the access log, no approval workflow and no fingerprint of what left the building.

Why it's an evidence question

When a breach happens, the questions come quickly. Which patients were affected? What information was disclosed? When did it happen? To which service?

If the upload happened through the organisation's own systems, the logs should have answers. If it happened through an employee's browser to a public site, the answers are often: we don't know, we don't have that and we're trying to piece it together from what the employee remembers.

That's hard for the organisation, harder for the patients and hardest for anyone who has to report the breach to a supervisor or a regulator. Article 33 of GDPR requires that a personal data breach is reported to the supervisory authority within 72 hours of becoming aware of it, and Article 34 says affected individuals must be informed without undue delay if the breach is likely to result in a high risk to their rights ^[2]. The clock starts when you know, not when it's convenient, and the report is supposed to describe the nature of the breach, the likely consequences and the measures taken. If you don't have logs, you're guessing.

What this means for you

If people in your organisation handle sensitive data, here are three questions worth asking now:

1. Do you have a policy that tells staff which AI tools they may use with patient data, customer data or proprietary information, and which ones they may not?
2. If an employee uploads something to a public AI site today, would you have a log of it tomorrow?
3. When you investigate a suspected breach, can you show what data left your systems, when and to where, or are you relying on what someone remembers?

Shadow AI won't go away by forbidding it. People use the tools that help them get their work done. The organisation's job is to make the safe tools easy to reach and to know when someone reaches for something else.

How a digital witness would help

A digital witness can't stop an employee from uploading data to a public site, and it doesn't decide who is allowed to do what. What it does is give you a record that's hard to argue with later.

Here, the thing to seal is the log of data leaving controlled systems: which file or data set, a fingerprint of its content, the user, the destination if known and the timestamp. Sealing takes a fingerprint of that log entry, not the patient data itself, so the data never goes anywhere except where it was already going. The sealed fingerprint goes to WitniumChain, and you get a witness ID back.

If a breach is suspected, you pull the logs and check them. Calculate the fingerprint again and compare it with the sealed one. If it matches, the log hasn't changed since it was written. Change a single character and it won't match. That way an auditor, a supervisor or an affected patient's representative can see that the log you're showing them is the log that was written at the time, not one edited when the questions started coming in.

It's sealed as each log entry is written, through the REST API, the SDK or the MCP server. The content stays with you. The first 2,000 witnesses a month are free. Read the docs to see how it fits your logging setup.

What it doesn't do: it doesn't show that the log is complete, that the upload was authorised or that no harm was done. It shows that the log entry you have now is the one that was written then.

What to watch

Shadow AI is going to be a recurring theme. The tools keep getting easier to use, and the rules keep asking for more documentation. If your organisation handles personal data, the GDPR duties around data protection by design (Article 25) and security of processing (Article 32) already apply ^[2]. If you're in a regulated sector, the logging and incident reporting rules are even tighter.

The Johns Hopkins breach didn't happen because someone was careless. It happened because the safe path and the quick path weren't the same path, and the organisation didn't know which one had been taken until afterwards.

Logs are like receipts. Nobody wants them until something's questioned. By then, it's too late to start writing them.