Is it worth asking a vendor about?

Briefly, and mostly to move past it. Effectively every serious vendor offers it, so a confirmation carries little information, and the conversation is better spent on retention periods, whether material trains anything, and who inside the vendor can reach it under what circumstances.

What actually changes if we hold the key ourselves?

The vendor's ability to read stored material without your involvement changes, which is the point of such arrangements. What does not change is anything about a working session: the service still needs readable data to function, so authorised use continues exactly as before.

Does it apply to what we type into an AI tool?

To whatever is retained, yes, and that is the qualification worth holding onto. The control protects stored material without addressing whether it should have been stored, for how long, or what else it may be used for, and those are the questions a buyer usually means.

Glossary

Encryption at rest

Storing data in scrambled form so it cannot be read from the storage medium itself, which is a narrower protection than the phrase usually suggests.

In plain terms

The filing cabinet is locked when nobody is using it. That genuinely stops somebody who walks off with the cabinet. It does nothing about somebody who has a key and is standing in the office during working hours, which is most of what a buyer is actually worried about.

Why it matters

Because it is the control most likely to be offered in answer to a question it does not address. Asked whether material is safe, a vendor will confirm this quickly and truthfully, and a buyer who takes the confirmation as a general answer stops asking. The genuine risks to a working system involve credentials, permissions and retention, none of which this touches.

How it works

It protects the storage rather than the service. Data written to disk is unreadable without the key, so physical theft, a discarded drive or a copy taken from underlying infrastructure yields nothing usable. Those are real risks and this addresses them completely.

The running service reads it perfectly, which is the part that limits the protection. Anything with valid credentials sees ordinary readable data, because the whole point is that authorised use continues normally. A stolen login, an over-permissioned automation and a mistaken share are unaffected, since each of them arrives as authorised.

Somebody has to hold the key, and where it lives decides how much the arrangement means. When the vendor holds it, they can read your material whenever their systems require it, which is not a criticism so much as a description. Arrangements exist that change this, and they are a separate question worth asking separately.

It is now effectively table stakes rather than a differentiator. Assuming it and asking about something else is a better use of a vendor conversation than confirming it, because a vendor without it is unusual enough that its absence would surface elsewhere.

For AI tools the more interesting question is what gets stored at all. Prompts, uploaded files and generated outputs may be retained for a period, and this control protects whatever is retained without saying anything about whether it should have been. Retention and use are the questions; this is about the safe of things already kept.

What the lock covers

This split is worth drawing because the confirmation is always truthful and the conclusion drawn from it usually is not. A vendor asked whether data is protected will say that it is encrypted at rest, and they are right; the buyer hears an answer to the right-hand column and stops. What makes the misunderstanding durable is that the left-hand column is genuinely important and genuinely handled, so nobody has said anything false. The gap only becomes visible when an incident arrives through the right-hand side, at which point the encryption was working perfectly throughout and made no difference. The practical move is to treat a confirmation as the end of that topic rather than the end of the conversation, and to spend the time on the three questions the right-hand column implies: who inside the vendor can reach material and when, how long anything is kept, and what an authorised connection is actually permitted to see. Those are answerable, they are contractual rather than technical, and they are where the difference between two vendors usually sits.

Seen in the wild

Confirming an assistant vendor encrypts stored conversations, then asking the more useful question of how long they are kept.
ChatGPT
Reading a search vendor's answer about stored indexes alongside what the index actually contains.
Glean
Checking that a self-hosted deployment encrypts its own storage, since the responsibility moves to whoever runs it.
Open WebUI

Common misconceptions

People assume

It means the vendor cannot read our material.

In fact

It means storage cannot be read without the key, and the vendor generally holds the key so that the service can function. Whether they may read it, and under what circumstances, is a contractual question rather than a technical one.

People assume

It protects against a breach.

In fact

It protects against one kind: material taken from the storage itself. Most incidents arrive through valid credentials, and to the system those look like ordinary authorised use, which this control permits by design.

Telling them apart

At rest vs In transit

At rest

Protects stored data from being read off the storage.

In transit

Protects data being sent from being read on the way.

One is about the safe. The other is about the journey. Both are standard and neither is about permissions.

Questions

Is it worth asking a vendor about?: Briefly, and mostly to move past it. Effectively every serious vendor offers it, so a confirmation carries little information, and the conversation is better spent on retention periods, whether material trains anything, and who inside the vendor can reach it under what circumstances.
What actually changes if we hold the key ourselves?: The vendor's ability to read stored material without your involvement changes, which is the point of such arrangements. What does not change is anything about a working session: the service still needs readable data to function, so authorised use continues exactly as before.
Does it apply to what we type into an AI tool?: To whatever is retained, yes, and that is the qualification worth holding onto. The control protects stored material without addressing whether it should have been stored, for how long, or what else it may be used for, and those are the questions a buyer usually means.

Key takeaways

It protects storage, not a working session with valid credentials.
Whoever holds the key decides how much the arrangement means.
It is table stakes, so confirming it carries little information.
For AI tools, what is retained matters more than that it is encrypted.

Tools that use this

ChatGPT
Confirming stored conversations are encrypted, then asking how long they are kept.
Glean
Reading the answer about stored indexes alongside what the index contains.
Open WebUI
Self-hosting moves responsibility for storage encryption to you.

Last checked August 2026

All glossary terms