When an AI tool says your data is "encrypted" or sits on "secure servers," it almost always means one thing: encryption at rest with keys the provider owns. That stops the one threat almost no consumer faces: a burglar carrying a data-center hard drive out the door. It does not stop the provider from reading your data, does not block your chats from training the next model, and does not stop a subpoena.
So the padlock on the pricing page is real, but it is aimed at a specific attacker: someone with no valid credentials trying to read raw storage. Every other threat you probably care about, the company itself reading your prompts, a court compelling access, an insider with the right permissions, training on your conversations, sits outside what standard at-rest encryption covers. This piece maps each threat to the protection that actually stops it, in plain English, so you can read a privacy page and know what the word is doing.
The one-line test for any AI privacy page: ask who holds the key. If the answer is the provider, "encrypted" protects you from a stolen disk and nothing else about who can read your data.
What does "encrypted" mean for AI data?
For AI data, "encrypted" usually means encryption at rest: your data is scrambled while it sits on disk, in a database, or in a storage bucket, so a stolen drive is unreadable without the key. Google encrypts all customer content at rest automatically, and states plainly that it owns and manages the keys used for that default encryption. That last clause is the whole story: if the provider holds the keys, the provider can decrypt.
Think of it as a vault with a lock the storage company installed and kept a copy of the key to. Your files are genuinely safe from someone who breaks into the warehouse and grabs a hard drive. They are not safe from the company that owns the vault, because that company can open it any time it has a business reason, a support ticket, or a legal order. Security writers put it bluntly: with server-side encryption using the provider's keys, the cloud provider can technically read your data.
The threat model matters. At-rest encryption is designed to thwart offline attacks: stolen backup tapes, a breached storage subsystem, improperly disposed media. It was never built to stop someone with valid credentials. If an attacker or an employee has an identity with read access, storage-level encryption treats that as authorized and hands over the plaintext.
In transit vs at rest: two different armored moments
TLS (the padlock on an https address) protects data in transit, while it moves across the network. At-rest encryption protects data once it lands on disk. They cover different moments in the data's life, and one without the other leaves a gap. Picture an armored truck versus a vault: transit encryption guards the trip, at-rest encryption guards the storage.
Here is why the distinction is easy to abuse in marketing. A page can truthfully say "encrypted in transit and at rest" while still meaning the provider decrypts your data the moment it needs to process it, which is constantly, because an AI has to read your prompt to answer it. TLS stops a stranger on the same coffee-shop Wi-Fi from sniffing your session. It does nothing about the company on the other end of the connection, which is the party actually receiving your plaintext.
The processing gap nobody advertises
Data has a third state that both TLS and at-rest encryption ignore: in use. To generate an answer, a model must decrypt your prompt into readable text inside memory. At that instant the data is plaintext on the provider's infrastructure. So even a service that is genuinely encrypted in transit and at rest is, by necessity, handling your content in the clear during the seconds it works on it. That is how computation works. It becomes a problem only when a privacy page uses "encrypted" to imply the provider never sees your content, which it does.
What changes with customer-managed keys (CMEK)
Customer-managed encryption keys shift who holds the key from the provider to you. CMEK is still server-side envelope encryption, but a customer controls the key that protects the data, which is the difference from default encryption. The practical power is revocation: if you disable or destroy the key, or pull the service's permission to use it, that data can't be accessed, even by Google.
Read that carefully, because it is often oversold. CMEK does not mean the provider can never see your data. During normal operation the service still asks your key system to unwrap the key and decrypt, and while it is processing, the plaintext exists on the provider's side. What CMEK gives you is a cryptographic kill switch and an audit trail: log every access, and cut off access entirely by killing the key. That is a meaningfully stronger position than default encryption, where the provider owns the only key and you have no lever at all.
The genuinely provider-blind option is client-side encryption, where the data is encrypted before it ever reaches the server and the provider only ever stores opaque blobs it cannot read. That is real, but it collides with AI: a model cannot answer questions about content it cannot decrypt. Any tool that reads, searches, or reasons over your documents must decrypt them somewhere. So most AI privacy stories live in the CMEK-plus-isolation zone, not the client-side-encrypted zone. Know which one a product is actually offering.
The five threats, and what really stops each
Match the threat to the mechanism and the marketing falls apart fast. The columns below are the three mechanisms a privacy page can lean on, from weakest to strongest. Four of the five threats you actually worry about, at-rest encryption does not touch.
| Does encryption stop this threat? | At-rest encryption (provider keys) | CMEK / customer-controlled keys | Client-side / end-to-end encryption |
|---|---|---|---|
| Stolen physical disk or lost backup tape | Stops it. This is exactly what at-rest encryption is for. | Stops it, same as at-rest, plus you hold the key. | Stops it. Stored blobs are unreadable without your key. |
| Network interception (coffee-shop Wi-Fi) | Not the job. TLS in transit is what stops this. | Not the job. TLS in transit stops this. | Not the job. TLS in transit stops this. |
| Provider reads your data (staff, support, ops) | Does not stop it. Provider owns the key and can decrypt. | Limits it. You can revoke the key and audit every access. | Stops it. Provider stores only blobs it cannot read. |
| Your chats used to train a model | Does not stop it. Encryption is unrelated to training policy. | Does not stop it either. Governed by the training terms, not the key. | Blocks server-side training, but rules out most AI features that read your content. |
| Subpoena or court order to the provider | Does not stop it. Provider can decrypt and comply. | Reduces exposure only if you can and do revoke access; policy and jurisdiction still apply. | Provider cannot produce readable content it never could decrypt. |
The training row surprises people most. Encryption and training are separate switches on separate walls. OpenAI trains on consumer ChatGPT conversations by default unless you opt out, while it excludes business and API data from training by default. None of that turns on whether the data is encrypted; the data-use policy attached to your account tier decides it. A service can be fully encrypted at rest and still feed your prompts into the next model version, because those are two unrelated decisions.
Here is what most coverage misses
Most explainers stop at "in transit vs at rest" and imply that once you have both, you are private. The part they skip: encryption at rest is close to irrelevant against the threats consumers actually face with AI. The realistic risks are a compromised employee account, an over-broad internal access policy, a training default nobody read, and legal process. At-rest encryption, the exact thing splashed across the pricing page, stops none of those.
The second thing coverage glosses over is legal process. When cloud data is not end-to-end encrypted, the provider holds a copy of the key and can decrypt it, so a warrant can compel readable content. Apple spells this out: under its default Standard Data Protection, Apple stores the encryption keys in its data centers and can therefore access the data, while only its optional Advanced Data Protection uses end-to-end encryption that removes Apple's access. If the provider can decrypt it, a court can order the provider to produce it. "Encrypted" and "beyond the reach of a subpoena" are not the same sentence, though the word is often placed to make you feel like they are.
Just ask who holds the key. It is the one follow-up that cuts through every buzzword on a privacy page. Provider holds it, you get stolen-disk protection and nothing more. If you cannot find the answer at all, assume the provider holds it.
How to tell if an AI tool is actually private
Translate the buzzwords back into threats. "Secure servers" and "bank-level encryption" almost always describe at-rest encryption with provider-held keys, which is table stakes and tells you nothing about internal access. "Encrypted in transit" is TLS, which everyone should have and which protects the network, not the destination. Neither phrase addresses training, insider access, or legal compulsion. So push past the words and interrogate five things.
- Who holds the keys? Provider-held keys mean the provider can read your data. Customer-managed keys (CMEK) give you a revocation lever and an audit log.
- Is my data used to train models, and is that on or off by default? Check the tier you are actually on, because consumer defaults often differ from business defaults.
- Who inside the company can access my content, and is it logged? At-rest encryption does not answer this; access policy and audit logs do.
- What happens under a subpoena? If the provider can decrypt, a court can compel it to produce. Encryption does not change that.
- Is the data ever processed in plaintext? For any AI that reads your content, yes, at least momentarily. The question is who is exposed and for how long.
A useful mental test: assume "encrypted" on a page means "a thief cannot read our stolen hard drives," and nothing more, until the page proves otherwise. Want credit for protecting you from insider access, training, or legal exposure? Name the mechanism: key ownership, per-user isolation, training defaults, access logging. Vague strength words are a tell that the specifics are weaker than the vibe.
Where MemX stands, stated honestly
MemX is not end-to-end encrypted and not zero-knowledge, and saying that plainly is the point of this whole article. MemX is an external AI memory layer: you back up and search your own documents, chats, voice notes, and photos, and ask questions across them in plain language. Because MemX has to read your content to answer questions about it, true E2EE is off the table. Any tool that reasons over your files and still claims E2EE is either wrong or has quietly redefined the term.
What MemX is, is private by architecture: per-user isolation so one person's data is not commingled with another's, customer-managed keys (CMEK) so there is a real revocation lever rather than a single provider-held key, encryption at rest, and on-device processing where it fits. That is a stronger, more specific posture than "secure servers," and it maps directly to the threats this article walks through: the insider-access row and the audit trail, not just the stolen-disk row. Read our privacy page against this exact table and it holds up. That is the differentiator against tools that stamp "encrypted" on the page and hope you stop reading.
01what does encrypted mean for AI data
It maps to one threat only: a stolen disk. "Encrypted" for AI data almost always means encryption at rest with provider-held keys. It leaves the provider reading your prompts, training defaults, insider access, and subpoenas untouched, because the provider holds the key and can decrypt on demand.
02can an AI company read my data if it is encrypted
Yes, if the company holds the encryption keys, which is the default. At-rest encryption stops outsiders who steal raw storage, not the company itself. To answer your prompt, the AI must decrypt it into plaintext, so provider-side access is built in unless you control the keys.
03does encryption stop AI from training on my data
No. Encryption and training are separate settings. Data can be fully encrypted and still used to train a model. The data-use policy on your account tier governs training. OpenAI, for example, trains on consumer ChatGPT chats by default unless you opt out, while it excludes business and API data.
04does encryption protect my AI chats from a subpoena
Not if the provider can decrypt. Cloud data that is not end-to-end encrypted is subject to normal warrant and subpoena standards, so a provider holding the keys can be ordered to produce readable content. Encryption at rest does not put your data beyond legal process.
05what is the difference between CMEK and encryption at rest
Both encrypt stored data. The difference is who holds the key. With default at-rest encryption the provider owns the key and can decrypt anytime. With customer-managed keys (CMEK) you control the key, can log every access, and can revoke it to cut off access, even the provider's.
Written by Arpit Tripathi, founder of MemX, which builds an external, model-agnostic memory layer. The sources for every claim here are linked inline, from cloud provider key-management docs to AI data-use policies. Verify them against your own provider's current terms before you rely on any single claim.
