End-to-End vs Encryption at Rest: What the Words Really Promise

Most encryption marketing is technically true and functionally misleading. When a product says your data is "encrypted," it's telling you something — but almost certainly not what you think it's telling you. The distinction between end-to-end vs encryption at rest is the difference between a lock where only you hold the key and a lock where the building manager keeps a copy in the office. Both are locks. Both involve metal and tumblers. One of them means the building manager can let someone in while you're away.

Key Takeaways

• Encryption at rest protects data on disk but leaves the provider holding the decryption keys — they can read your files, and can be legally compelled to do so.
• End-to-end encryption means keys never leave sender and recipient devices, so the service operator cannot access content even if they want to — but bolting AI features onto E2EE systems can quietly break that guarantee.
• The "third state" — data in use — is where most AI products expose content, because inference requires decrypted data at processing time. This is the gap neither term covers.
• Regulatory safe harbors have turned "encrypted" into a legal magic word that often obscures what's actually protected, rewarding the label over the architecture.
• We built Selina with files and transfers (SelinaSEND) that are zero-knowledge encrypted end-to-end, but we state plainly that memory is NOT end-to-end encrypted — because inference sends a slice of each request to a frontier provider. Honesty about limits is the architecture.

What does "encryption at rest" actually protect?

It protects data on disk from being read if someone steals the physical drive or gains unauthorized access to the storage layer. That's it. The data is scrambled using a key — often AES-256 — and unscrambled when the system needs to process it. The important part: the provider holds the decryption keys. They can read your files. They can be served a warrant and comply. If a service says "AES-256 encryption" without further specifics, it's almost certainly describing encryption at rest.

This isn't a flaw, exactly. It's a design choice. Encryption at rest defends against a specific threat model: unauthorized physical or storage-layer access. It does nothing against the provider themselves, or anyone who compromises the provider's key management. For consumer cloud storage — the kind most people use daily — the provider can technically read files and is legally compelled to comply with law-enforcement requests.

None of this is hidden. It's just never foregrounded, because the word "encrypted" does enough marketing work on its own.

What does "end-to-end encryption" actually mean?

It means data is encrypted on the sender's device and decrypted only on the recipient's device, with keys never reaching the service provider. The operator is structurally locked out. Not by policy, not by a pinky promise, but by the math. They don't have the key. They can't produce the key. If subpoenaed, they can hand over ciphertext — which is useless without the key they never possessed.

This is a stronger guarantee. It's also a narrower one than people assume. E2EE protects content in transit and at rest on the server — but it says nothing about what happens on the endpoints themselves, and it says nothing about metadata. Who messaged whom, when, how often, from which IP address — all of that can be visible to the provider even in a properly implemented E2EE system.

Why do people confuse these two terms?

Because the compliance industry trained them to. All 50 U.S. states exempt encrypted data from breach notification requirements. A stolen laptop holding only encrypted-at-rest files may never trigger public disclosure. The word "encrypted" became a legal safe harbor — a checkbox that satisfies regulators regardless of whether the encryption model actually prevents the provider from reading the data.

This incentive structure is backwards. It rewards the label, not the architecture. A company can encrypt data at rest, hold all the keys, get breached through an application-layer vulnerability that exposes decrypted data in memory, and still argue — correctly, under most state laws — that the encrypted data wasn't compromised because the disk-level encryption was never broken. The attacker didn't need to break it. They accessed the data after the system decrypted it for processing.

The result: "encrypted" became a magic word. It means something. It just doesn't mean what most people hear when they read it.

What is the "third state" problem — data in use?

Data exists in three states: at rest (stored on disk), in transit (moving between systems), and in use (actively being processed). Traditional encryption only covers two of these three states. The third — data in use — is where AI products live.

When an LLM processes your prompt, the data must be decrypted. The model can't run inference on ciphertext. This is a structural reality, not a vendor shortcut. Even if your data was encrypted at rest and encrypted in transit, the moment it reaches the inference layer, it's plaintext in memory. This is the gap that makes "we encrypt everything" claims from AI products worth interrogating carefully.

For products that route requests to external inference providers — which is most of them, including ours — the data-in-use window extends beyond your own infrastructure. A slice of each request reaches the provider's compute environment. You can negotiate data processing agreements. You can choose providers with strong contractual commitments. But the data is there, decrypted, during processing. Anyone who tells you otherwise is either running inference entirely on-device or misrepresenting their architecture.

How did an E2EE promise break in production? The WhatsApp case study.

This isn't abstract. In January 2026, a class action was filed against Meta alleging that WhatsApp misled over 3 billion users by claiming "unbreakable" end-to-end encryption while allegedly allowing internal employees to access private communications. Meta has called the claims "false and absurd." The case is in early procedural stages.

We're not taking sides on the litigation. What's instructive is the architectural pattern the complaint describes — and it maps to a problem every AI product will face eventually.

WhatsApp's Signal protocol implementation is, by most credible technical analyses, genuine E2EE at the message-transport layer. Messages are encrypted sender-to-recipient. But a platform can be technically E2EE at the protocol layer while still exposing content through adjacent surfaces. The complaint points to content moderation workflows, reported-message handling, and — most relevant for this piece — Meta AI features inside WhatsApp that can access and summarize messages, with summaries passing through Meta's servers.

This is the pattern: an E2EE messaging system bolts on an AI feature. The AI feature needs to read the messages to do anything useful. Suddenly the guarantee that "only sender and recipient can read the content" has a third party in the room — the AI inference pipeline. The encryption didn't break. The scope of who counts as a "recipient" quietly expanded.

Why is E2EE especially hard for AI products?

Because AI inference, by definition, means a machine reads your data. Researchers from NYU and Cornell formalized this problem: using encrypted content to train or operate AI models shared between multiple users fundamentally breaks encryption's promises, because the model becomes a function dependent on the private data that went into it. Their recommendation: any processing of encrypted content should happen locally on-device whenever possible.

On-device inference is real and improving. But it imposes hard constraints — model size, compute budget, latency, capability. The frontier models that produce the best results are too large to run on consumer hardware. If you want frontier-quality inference, the data travels to a data center. That's the trade-off.

End-to-end encryption is not a standard, or even necessarily an available, feature for AI chatbots. This is the current state of the industry. Not a bug in any individual product — a structural constraint of the technology.

How should you read a product's encryption claims?

Ask three questions, in this order.

First: encrypted by whom, with whose keys? If the provider holds the keys, they can read the data. Encryption at rest with provider-held keys protects you from disk theft. It does not protect you from the provider — or from anyone who compromises the provider's key management infrastructure.

Second: encrypted when? Data at rest and data in transit are different states. A product can encrypt both and still expose data during processing. The data-in-use gap is real, and it's where most AI-related exposure happens.

Third: does the product route data to external services for processing? If yes — and for AI products, the answer is almost always yes — then the encryption boundary does not extend to the inference layer. The provider's contractual commitments matter here, but they're policy controls, not cryptographic ones. Policy can change. Math doesn't.

A useful heuristic: if a product says "encrypted" without specifying at rest, in transit, or end-to-end, and without explaining key custody, treat the claim as marketing until proven otherwise.

What does this mean for the cost of getting it wrong?

The average global data breach costs approximately USD $4.4 million. That number aggregates detection, response, notification, lost business, and regulatory consequences. It's a mean, not a median, so it's skewed by large breaches — but the point stands: the cost of exposure is measured in millions, not thousands.

Encryption at rest reduces the likelihood of breach-notification triggers — because of those state-level safe harbors — but it doesn't reduce the likelihood of the breach itself. If an attacker gains application-layer access and reads data that's decrypted for processing, the encryption-at-rest layer is irrelevant. The data was exposed in its third state. The same breach reports note that encryption at rest alone did nothing to stop breaches where data was exposed while actively in use.

For regulated industries — healthcare under HIPAA, financial services under the FTC's Safeguards Rule — the nuances matter even more. HIPAA does not technically require encryption, but it rewards it through breach-notification safe harbors. This means organizations can choose whether to encrypt, but if they don't, they lose the regulatory cover when something goes wrong. The incentive, again, is to encrypt — but the incentive doesn't distinguish between encryption models that protect against the provider and models that don't.

Where does Selina sit in this landscape?

We draw a line through the product that we think is honest, and we explain both sides of it.

Files and transfers — SelinaSEND — are zero-knowledge encrypted, end-to-end. We don't hold the keys. We can't read the content. If someone subpoenas us for a file sent through SelinaSEND, we can hand over ciphertext and nothing else. Delete means gone. Actually gone.

Memory is NOT end-to-end encrypted. Memory is protected and encrypted at rest. But a slice of each request reaches a frontier provider at inference time — it has to, because that's how LLM inference works. We route requests through a stack of frontier models, selected per task. The data is decrypted during processing. We're honest about this because the alternative is to make a claim we can't back up architecturally.

Operational metadata — the kind of non-content data any system generates to function — is kept for a short retention window. We don't claim zero retention. Your account is protected. Content is encrypted.

This is not the strongest possible set of claims. A product that ran inference entirely on-device could make stronger ones — at the cost of capability, latency, and model quality. A product that didn't offer persistent memory could avoid the data-in-use problem entirely — at the cost of being useful. We chose a point on the trade-off curve and we describe it plainly. What we don't claim is part of the design.

What should the industry move toward?

The honest answer: confidential computing and encrypted-in-use architectures. These are real technologies — hardware-level trusted execution environments that process data without exposing it to the host operating system or the operator. They're not theoretical. They're shipping in production silicon. But they add cost, complexity, and latency — and the tooling for running LLM inference inside a confidential-compute enclave is early-stage at best.

The AI assistant landscape is bifurcating into three lanes: local/edge-first agents that prioritize absolute data isolation, encrypted-but-feature-limited E2EE tools, and hybrid cloud products that balance privacy and capability. None of these categories is wrong. They serve different threat models and different user priorities.

What's wrong is ambiguity. Calling something "encrypted" without specifying which state, who holds the keys, and what happens during inference is — at best — incomplete. At worst, it's the kind of promise that ends up in a class-action complaint.

How do you audit an encryption claim in under five minutes?

Here's a checklist. It works for AI products, cloud storage, messaging apps — anything that uses the word "encrypted" in its marketing.

1. Find the key custody statement. Who holds the encryption keys? If the answer isn't "only the user" or "only sender and recipient," it's not E2EE. It might still be useful encryption. But it's not E2EE.
2. Look for the data-in-use disclosure. Does the product acknowledge that data is decrypted during processing? If it doesn't mention this at all, that's a red flag. Every AI product decrypts data during inference. Silence on this point is a choice.
3. Check for third-party processing. Does the product route data to external APIs or inference providers? If yes, the encryption boundary is narrower than a standalone system. Contractual protections exist, but they're not cryptographic.
4. Read the breach-notification policy. Does the product rely on encryption-at-rest safe harbors for its compliance posture? That's fine — but it tells you the encryption is serving a legal function, not necessarily a security one beyond disk-level protection.
5. Search for the honest limit. The most credible products tell you what they don't encrypt, or where the encryption boundary ends. If a product only tells you what it does protect and never mentions the gaps, be skeptical.

Does the terminology even matter if the provider is trustworthy?

Yes. Trust is a policy decision. It can be revoked, overridden, or breached. Encryption is a mathematical decision. It either holds or it doesn't.

A trustworthy provider with encryption at rest and provider-held keys can be compelled by law enforcement to produce your data. A trustworthy provider with E2EE cannot — they don't have the keys. The difference isn't about whether you trust the provider. It's about what the provider is structurally capable of doing, regardless of intent.

This doesn't mean E2EE is always the right choice. It comes with real trade-offs: reduced functionality, harder key recovery, inability to do server-side search or processing. Those trade-offs are sometimes worth accepting and sometimes not. The point is that the words should describe the architecture, not a feeling about the company.

The bottom line: words should match architecture

Encryption at rest means the disk is encrypted and the provider holds the keys. End-to-end encryption means the provider doesn't hold the keys and structurally can't read the content. These are different promises. They defend against different threats. Neither is universally better — but conflating them is always misleading.

For AI products specifically, the data-in-use gap makes end-to-end encryption claims especially fraught. If an AI reads your data to produce a response, someone's infrastructure decrypted it. The question isn't whether that happened — it's who controls that infrastructure, what contractual and technical safeguards bound them, and whether the product tells you about it or pretends it doesn't exist.

We think the right move is to say what you encrypt end-to-end, say what you encrypt at rest, and say where the encryption boundary ends. Then let the reader decide. The words should promise exactly what the architecture delivers. Not more.

If that sounds like the kind of product philosophy you want behind your AI assistant, start a free 7-day trial — no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io