Your cloud provider can probably read your files — here's how to check
Almost every cloud storage provider will tell you your files are encrypted, and almost every one is telling the truth. The word doing the quiet work in that sentence is "encrypted" — because there are two very different things it can mean, and only one of them stops the provider from reading your data. The gap between them is where most people's assumptions about their privacy turn out to be wrong.
Encrypted-at-rest is not the same as private
When a provider says your files are "encrypted at rest" or "encrypted in transit", they usually mean server-side encryption: the files are scrambled on their disks and over the wire, but the provider holds the keys. The data is protected from someone who steals a hard drive out of the datacenter, or from an eavesdropper on the network. It is not protected from the provider itself, because the provider can decrypt it any time it needs to — to index it for search, generate previews, run an AI feature over it, or respond to a legal request.
End-to-end encryption — also called client-side or zero-knowledge encryption — is the other kind. Here the data is encrypted on your device with a key the provider never sees, so what lands on their servers is opaque ciphertext they cannot read even if they wanted to. The practical test is simple: if your provider can show you a preview of a document you uploaded, search inside it, or recover it after you forget your password, they can read it. That is server-side encryption wearing a privacy-flavored label.
What the terms of service actually permit
It is worth reading the part of a cloud provider's terms that grants them a license over your content, because it is rarely as narrow as people assume. The common shape is a clause granting the provider a broad, worldwide, royalty-free license to "host, store, reproduce, modify, and create derivative works" from your content for the purpose of "operating and improving the service". That last phrase is the elastic one.
"Operating the service" plausibly covers backups, thumbnails, and abuse scanning. "Improving the service" is much broader, and in 2026 it increasingly means feeding content into machine-learning systems — training or fine-tuning models, building search features, or powering an in-app assistant. Some providers carve out an explicit opt-out for AI training; many fold it into the general improvement language and turn it on by default. The point is not that every provider acts in bad faith. It is that the contract you agreed to permits far more than "we keep your files safe", and a clause written for thumbnails reads just as easily as a license to train on your documents.
- A broad content license "to operate and improve" the service — improvement is the word that quietly stretches to cover AI training.
- Rights to "reproduce, modify, and create derivative works" — derivative works is exactly what a trained model is.
- Server-side scanning for "safety", "abuse", or "quality" — all of which require the provider to be able to read the content.
- An AI or assistant feature that can answer questions about your files — proof, by itself, that the plaintext is reachable on their side.
How to tell who holds your keys
You do not need to read source code to work out whether a provider can read your files. A few observable behaviors give it away, because every convenience feature that reaches inside your content requires the provider to hold a key that can decrypt it.
- 1Can you reset your password and still get your files back? If yes, the provider can decrypt your data — true end-to-end encryption means a lost password means lost files, with no reset path.
- 2Does the web interface show previews, thumbnails, or full-text search of your documents? Generating those requires reading the plaintext server-side.
- 3Is there an AI assistant, smart search, or "ask your files" feature? It can only work if the plaintext is available to their systems.
- 4Does the marketing say "zero-knowledge", "end-to-end", or "the provider cannot access your data" — in those words, not just "encrypted"? Vague "bank-grade encryption" language almost always means server-side.
- 5Who generates the encryption keys? If onboarding never asks you to set a separate encryption passphrase or hold a key, the provider made and kept the keys for you.
If most of those point at the provider, that is not necessarily a reason to panic — for a folder of holiday photos it may be a perfectly reasonable trade for convenience. It is a reason to be honest with yourself about which files genuinely need to stay private, and to stop assuming "it's encrypted" covers them.
Zero-knowledge and BYOK, in plain terms
Two terms come up whenever you go looking for real privacy. Zero-knowledge means the service is built so it never has the knowledge required to read your data — the keys are derived and held on your device, so even a fully compromised provider, or one served a subpoena, has only ciphertext to hand over. BYOK, "bring your own key" (and its cousin, bringing your own storage bucket), means you control the keys or the storage rather than renting them, so the vendor is never the single party holding both your data and the means to unlock it.
The durable property you are looking for, under either name, is the same: the entity that stores your bytes is not the entity that can decrypt them. When those two are the same company, your privacy depends entirely on that company's current policy, its future owners, and whatever its terms let it do — none of which you control. When they are separate, your files stay private even if the storage provider changes its mind, gets acquired, or is compelled to open the vault.
What you can do about it
The fix is not to abandon cloud storage. It is to encrypt the files that matter before they reach it, so that whatever the provider's terms permit, what they actually receive is unreadable. For a personal vault, an audited open-source tool that encrypts a folder before it syncs is a great, free start. If you collaborate, or you want the file names and folder structure hidden too — not just contents — you want something purpose-built for that.
Kerveros encrypts every file — including filenames — on your machine with XChaCha20-Poly1305 before it touches any provider, and stores the result in an S3-compatible bucket you own (bring your own Tigris, Backblaze B2, AWS S3, or MinIO). You hold the keys; the provider sees only opaque blobs, so its terms of service apply to ciphertext that is worthless to train on or read. It is a one-time €79 purchase, not a subscription.
See KerverosWhatever you choose, the test from the start of this post is the one to keep: if your provider can read your files, so can anyone the provider answers to — today's policy, tomorrow's owner, and whatever an "improve the service" clause grows to mean. The only configuration that does not depend on trusting them is the one where they never held the key.