Why end-to-end encryption is non-negotiable for healthcare AI

Every healthcare software vendor says their product is "secure." Almost none of them can explain what that word actually covers. For an AI agent that touches patient data, the answer needs to be specific: encrypted at rest, encrypted in transit, and — increasingly — encrypted in a way that limits what even the vendor operating the system can see.

At rest and in transit are the floor, not the ceiling

Encryption at rest means data sitting in a database or file store is unreadable without the decryption key, even if the underlying storage is somehow accessed directly. Encryption in transit (TLS) means data moving between a client and a server can't be read by anyone intercepting the connection. Both are table stakes for any system handling health data — a system missing either shouldn't be in production, let alone connected to an AI agent.

But "we encrypt data at rest and in transit" is the floor. It says nothing about who can decrypt it, under what conditions, and with what oversight.

The question that actually matters: who holds the keys?

If a vendor holds both the encrypted data and the keys to decrypt it, that vendor — or anyone who compromises that vendor — can read everything. For a clinic's patient records processed by an agent, that means the vendor's own infrastructure is a single point of failure for every patient's data across every client the vendor serves.

The alternative is architecture where keys are scoped to the client's own environment, so a breach of the vendor's infrastructure doesn't automatically mean a breach of the data. This is more work to build. It's also the difference between a vendor that can credibly say "we couldn't read your patients' records even if we wanted to" and one that's just promising not to look.

What this means for an AI agent specifically

An agent that queries patient records to answer a clinical question has to decrypt that data at some point to reason about it — that's unavoidable. What's avoidable is where that decryption happens and what leaves the client's environment. An agent architecture where decryption happens inside the client's own infrastructure, and only the agent's output (not the raw underlying records) leaves that boundary, is a fundamentally different risk profile than one that pipes raw patient data through a third-party API to get an answer.

Encryption is necessary, not sufficient

None of this replaces access control, audit logging, or minimizing what data an agent touches in the first place. Encryption protects data from being read by someone who shouldn't have it if they get their hands on it. It does nothing to stop an agent — or a person — with legitimate access from misusing that access. Both layers have to exist together, because they're solving different problems.