When you connect an AI tool to your email you hand it the most sensitive corpus in your professional life — contracts, money, legal exposure, medical details, the conversations you would not want quoted. Every tool in this category asks for that access. Most explain what they do with it in language chosen to sound stronger than it is.
“Zero-knowledge” is the most abused phrase in that vocabulary. This is what it actually means, why almost nothing in this category qualifies, and what to ask instead.
What Zero-Knowledge Actually Means
Zero-knowledge means the provider cannot read your data — not that they promise not to. The decryption key is derived on your device and never reaches their servers, so what they store is ciphertext they have no way to open.
The distinction is not academic. It is the difference between:
- “We do not read your email.” A policy. It holds until the policy changes, an employee ignores it, an acquirer rewrites it, or a court overrides it.
- “We cannot read your email.” A property of the mathematics. It holds regardless of who owns the company or what a subpoena demands.
The one-question test: if a court ordered the company to produce your readable email, could they comply? A zero-knowledge provider answers no and can show you why. Everyone else answers yes, whatever the landing page says.
The Contradiction at the Heart of AI Email
Here is the problem nobody in this category likes to state plainly: an AI assistant has to read your email to be useful, and reading requires plaintext.
You cannot tell a customer's pricing question from a newsletter without understanding the words. You cannot draft a reply in someone's voice without reading how they write. If that understanding happens on a server, then at that moment the data is readable on that server — and a system that can read plaintext to do its job is not zero-knowledge about the thing it just read.
There is one honest way to have both: run the model on the user's own device. Some privacy-first clients do exactly that, and they accept the trade — smaller models, less reasoning across your full history, more limited features. That is a real engineering position with real costs. What is not honest is claiming the privacy property while sending the plaintext to a server anyway.
What Mailient Actually Does
Precisely, so you can check it rather than trust it:
- AES-256-GCM at rest. Authenticated encryption, so tampered ciphertext is rejected rather than silently accepted. This covers the access tokens for every service you connect.
- TLS in transit. Standard, and table stakes.
- Personal details stripped in some AI calls. Some AI calls replace names and email addresses with placeholders before the content is sent to a language model, and restore them afterwards; not every call does yet. The model provider does not receive the identities of the people you correspond with.
- Google OAuth. We never see your password. Tokens are scoped and you can revoke them from your Google account in seconds.
- No training on your mail, and no routine human access to it.
That is a genuinely strong posture. What it is not is zero-knowledge: the encryption keys live in our infrastructure, not in your browser, so we hold the technical ability to decrypt. Under the one-question test above, we would have to answer yes.
A Correction
An earlier version of this page described Mailient as zero-knowledge, with keys held in your browser and blobs the server could not read. That described an architecture we had built but had not put on the live path, and it should not have been published as a description of the shipped product. It has been corrected here, on the security page and in the privacy policy.
We are leaving this note rather than quietly editing the page, because a company's handling of its own overclaim is itself a security signal.
What to Ask Any Vendor
Five questions that separate architecture from adjectives. Ask them of us too.
- Where is the decryption key? If any answer mentions their servers, their KMS, or their cloud provider, it is not zero-knowledge. There is no version of this where the key is in two places.
- Could you comply with a subpoena for my readable mail? The only disqualifying answer is a vague one.
- Which third parties see my content? Nearly every AI email tool sends text to a model provider it does not own. Ask which, and what that provider is contractually allowed to do with it.
- Is my data used for training — by you or by them? These are two different questions and vendors often answer only the first.
- What can the product do without asking me? Not encryption, but the same family of question. Reading is one risk; acting on your behalf is another.
The Real Trade-off
You are choosing on a spectrum, not between private and not-private.
At one end: no AI touches your mail, and you do all the work. At the other: a capable assistant reads everything, and you rely on encryption, contracts and access controls rather than mathematical impossibility. On-device tools sit in between, trading capability for a stronger guarantee.
Every position on that spectrum is defensible. What is not defensible is a vendor claiming the guarantee of one end while operating at the other — which is common enough in this category that the phrase has stopped carrying information.
If mathematical impossibility is what you need, you should be running an on-device tool, and we would rather tell you that than sell you something on a claim that does not survive the one-question test. If strong conventional protection plus a clear statement of what actually happens is enough, that is what our security page now describes — accurately.