Your email client sees:
- Every conversation with your accountant.
- Every customer escalation.
- Every NDA you ever signed.
- Every receipt for everything you ever bought.
- Every personal message from people who trust you.
- Every confidential thing your colleagues told you in writing.
It is, plausibly, the single most invasive piece of software on your machine. Your bank does not see all of that. Your phone does not see all of that. Your inbox does.
So when an email client wants to ship a feature that requires sending your email content to a third-party server for processing, the question is not “is this convenient.” The question is whether the convenience is worth the data exposure.
In most cases, our view: it is not.
The default has changed
Until about 2022, email clients were architecturally local. Your client downloaded mail, processed it on your machine, displayed it. Cloud features were rare and clearly opt-in.
Then LLMs got useful. Suddenly every client had a Summarize button, a Draft Reply button, a Smart Compose. Most of them quietly send the email content to a server (theirs, OpenAI's, Anthropic's) to do the processing. The opt-in moment, in some clients, is an afterthought.
This is not malice. It is a category-wide shrug. The tradeoff was made for you.
What “processing in the cloud” actually means
When your client sends an email to a server for AI processing, here is the chain:
- The email body leaves your machine encrypted in transit.
- It arrives at the AI provider's server. There, it is decrypted, processed by the model, and a result is generated.
- Some providers retain the input for a period (30 days is common) for “abuse monitoring.”
- The result is returned to your client.
Steps 2 and 3 are where the privacy posture lives. Most consumer email AI features run on shared infrastructure with logging. Most providers make a privacy claim. Few of them are independently audited.
The real question is not “do you trust the company that made your email client.” The real question is “do you trust their model provider, their cloud provider, their abuse-monitoring vendor, and any subprocessor in between.”
Every server that touches your email is a server that has to never be breached.
The trust chain
Your average AI-powered email feature involves at least three companies.
- The email client maker.
- The model provider (often OpenAI or Anthropic).
- The cloud host (often AWS or Google Cloud).
You must trust all three. Each one's breach is your data's breach. Each one's subpoena is a subpoena that pulls your email. Each one's decade-long retention quietly accumulates in their systems.
This is fine for some categories of data. We are not arguing every cloud feature is bad. Email is a specific category where the data is uniquely sensitive across a uniquely large surface.
Where on-device classification fits
STAMP does classification on-device. The triage layer (“is this urgent, is this VIP, does it need a reply”) runs on your Mac. No content leaves the machine for processing.
We covered the technical details in on-device email classification, explained. The architectural point: the privacy properties are baked in. We could not exfiltrate your email if we wanted to, because the classifier never has cause to send it anywhere.
The cost is that the model is smaller. We give up some capabilities (cloud-grade summarization, very long context). We accept that cost.
Things we do not ship
To make this concrete, three features we deliberately do not ship in STAMP:
- One-click summarization that sends to a cloud LLM. We do not have it. We could add it; we have not.
- Cloud-based search that indexes your email server-side. We do not have it. Search runs locally.
- “Train on my email” opt-in for personalization. We do not have it, and we do not have a roadmap for it.
These are real product limitations. We are not pretending the user is not giving up something. We just think the privacy floor matters more.
Where third-party AI is fine in email
We are not absolutist. Three places we think cloud AI is reasonable in email:
- Spam filtering by your provider. Gmail and Microsoft already do this server-side. The data is already there. Adding spam filtering does not change the threat model.
- Calendar parsing of public events. A conference invite is mostly public. A model parsing it for calendar suggestion is low-stakes.
- Translation of explicitly selected text. If you select a paragraph and ask for translation, the data exposure is bounded and obvious.
In each case, the user knows what is sent and gets a clear benefit. That is the right form of consent.
What good privacy looks like in an email client
Five questions to ask any email client you evaluate:
- Where does email content live during processing? On-device, on the maker's server, on a third-party AI server?
- What is retained, and for how long? Specifically about your inputs, not just “outputs.”
- Who has access? Engineers, support, abuse monitoring, law enforcement under what process?
- Has it been audited? By whom, when, what scope?
- What is the breach posture? A breach disclosure policy, a track record.
If the client cannot answer any of those clearly, treat it as a yellow flag.
Our own scorecard
We will not pretend STAMP is unaudited or unfinished. Honest scorecard:
- Where does email content live during processing? On-device, in memory.
- What is retained? Local fine-tuning corrections, on-device, not visible to us.
- Who has access? Nobody at STAMP. Nobody at any subprocessor.
- Has it been audited? Independent audit scheduled for 2026 H2.
- What is the breach posture? Public disclosure within 72 hours, no exceptions.
If those answers stop being true, we will publish a release note in 18-point bold.
Where to go from here
For the technical details, on-device email classification, explained. For the broader privacy comparison, email privacy in 2026 — what to ask before you trust a client.
Your mail. Your machine. hello@stamp.email