Encryption Questions to Ask an AI Email Vendor

Encryption is the part of a vendor call where nodding along costs you the most. Every SaaS deck says it. Very few decks say what algorithm, what key hierarchy, whose KMS, and who inside the company can pull plaintext. Those are the six answers that actually change what happens if the vendor is breached, subpoenaed, or acquired.

This is a buyer's guide to those six questions — the shape of an answer that passes, the shape that should end the call, a worked example you can run against your own shortlist, and an honest verdict on where we sit. We build AI Emaily, and we cover our own limits in the same words we would have to use if you were interrogating us.

The short answer#

Ask about encryption at rest and in transit vendor questions in this order: transport, storage, credential custody, envelope encryption, key rotation, and who can decrypt. Do not accept a single-word yes on any of them. A vendor that says only "yes, we encrypt" is describing the box the answer arrives in, not the answer.

The passing answers each contain a specific noun. TLS 1.2 or higher with modern cipher suites. AES-256 at the storage layer. A KMS name or category — HSM-backed, hardware-isolated, or a named cloud KMS. A key hierarchy with per-user data encryption keys wrapped by a key encryption key that lives only in the KMS. A rotation cadence measured in days or weeks, run without downtime. And a named internal role — usually a break-glass on-call engineer — with the audit trail that fires when it happens.

If you get all six in specific nouns, you have a vendor whose encryption story is real. If you get one or two and a lot of adjectives, you have a vendor whose story is a slogan.

Criteria that actually matter#

The six questions are not equally important, and none of them is the one most buyers lead with. "Are you SOC 2?" is a routing question, not an encryption one — it tells you an auditor sampled controls, not what those controls do.

Transport is where most vendors are strongest and where a bad answer is most disqualifying. If a vendor cannot state a TLS version and a fallback policy, they are running a stack somebody else configured and they cannot promise you it will not regress.

Storage at rest is a two-part question. What algorithm is the storage layer using, and are message bodies additionally wrapped with a per-object key that a separate service holds? A single blanket AES-256 answer is fine for metadata. For message bodies specifically, a per-object KMS wrap means a stolen storage volume does not by itself yield plaintext.

Credential custody is the question that most often exposes a weak stack. OAuth tokens, IMAP passwords, and any bring-your-own-key material must not live in the same table as everything else, and they must not appear in application logs, error reporters, or analytics pipelines. If the vendor cannot confirm that plaintext credentials never reach those three destinations, assume they do.

Envelope encryption is a design choice, not a marketing word. It means each secret is wrapped in a per-user or per-object data encryption key, which is itself wrapped by a key encryption key held in a KMS. The secret and the key that unlocks it are never stored together. It matters because it caps blast radius — stealing the database does not reveal credentials without also breaching the KMS — and because it makes rotation cheap.

Key rotation cadence tells you whether the vendor treats keys as living infrastructure or as install-and-forget. A rolling automated rotation with no downtime is the answer that passes. "On breach" is the answer that fails; by the time you rotate on breach you have already lost.

Who can decrypt is the question vendors are least prepared for. The truthful answer is that at least one internal role can — a break-glass mechanism exists in every hosted product. The vendors worth trusting name the role, name the audit event, and can produce a log line the last time it fired.

Scoring table: six questions, six shapes of answer#

Copy this into your evaluation sheet. Score each row 2 for a specific-noun answer, 1 for a hedge that needs a follow-up, 0 for the red-flag phrasing. A vendor that scores below 8 out of 12 is not a vendor whose encryption story you can defend upstream.

Where the honest concession sits#

The six questions above assume the vendor has to be able to read your mail to do its job. That assumption is true of any AI email client, us included. It is not true of every email product on the market, and that is the concession you should hear before we make our own case.

If your threat model requires that nobody at the vendor can ever decrypt your message body under any circumstance, no AI email client is the right answer — including AI Emaily. Proton Mail and Tuta encrypt user-to-user mail end-to-end between two accounts on their networks, using keys that live on your device rather than in a KMS on their side. That is a genuinely different security posture, and it is stronger on that one axis than anything we do. It also rules out an AI agent reading and drafting for you, which is the trade-off.

So the six questions in this guide are the right questions for buyers who want an AI email tool. If you are shopping between an AI email tool and end-to-end encrypted mail, the answer is not a score on this sheet — the answer is which trade-off you are willing to make.

Worked example: running the six questions on a real shortlist#

Take a two-vendor shortlist. Vendor A returns a security PDF; Vendor B returns a short email from an engineer. Score them side by side and see which encryption story survives.

Vendor A scores 3 out of 12. Nothing they said was false — the sentences are all true of any competent SaaS. Nothing they said was specific either, which means nothing they said is defensible when your CISO asks a follow-up. Vendor B scores 12 out of 12, and you did not have to read a compliance PDF to get there.

The scoring is not the point on its own. The point is that the shape of a vendor's answer predicts the shape of the incident write-up you will be reading if something goes wrong. Slogans predict handwaved postmortems.

Red flags: the phrasings that end the review#

Certain answers should end the call rather than earn a follow-up. Not because they prove insecurity — they might not — but because they mean the person on the call cannot answer the question, and the review will stall in a chain of forwarded emails.

• "We take security very seriously." This is a category. It is not an answer.
• "Bank-grade encryption" or "military-grade encryption." Both phrases mean AES-256, which is fine — but a vendor reaching for a metaphor is a vendor whose engineering team is not in the room.
• "Nobody at our company can access your data." Mathematically impossible for a product that renders your mail server-side. A vendor claiming this either does not understand their own stack or is willing to say things they cannot defend.
• "Keys are rotated on breach." Rotation after breach is not a rotation policy. It is a confession that the current cadence is zero.
• "That's covered in our SOC 2." SOC 2 tests that controls exist. It does not describe the controls. A vendor who cannot narrate their own encryption without gesturing at an auditor's report has outsourced the answer to the auditor.
• "We use HTTPS." No TLS floor is a TLS 1.0 fallback waiting to be found.

What we'd pick and why (honest)#

We build AI Emaily. On this sheet, our own answers to the six questions come out as follows, and we would rather hand them to you the same way we ask other vendors to hand theirs to us.

Transport is TLS 1.2 minimum with modern cipher suites; older TLS versions are rejected at the load balancer rather than deprecated in docs. At rest, message bodies, metadata, and summaries are AES-256 at the storage layer, and message body blobs additionally carry a per-object KMS-managed key — a compromised storage volume alone does not yield plaintext without also breaching the KMS. Credential custody uses envelope encryption for OAuth tokens, IMAP and SMTP credentials, and BYOK keys; plaintext never touches application logs, error reporters, or analytics pipelines. Envelope encryption is real: a per-user DEK wraps each secret, a KEK held in a dedicated hardware-isolated KMS wraps the DEK, and the two are never stored together. Key rotation runs automatically on a rolling schedule with no downtime, with per-user DEKs re-wrapping without needing to re-encrypt the underlying ciphertext. On the sixth question, the honest answer is that a small on-call engineering role can, under a break-glass procedure with an audit event on every unlock — the same shape of answer we tell you to demand from anyone else.

We would score ourselves 12 out of 12 on the six questions in this guide. That is not the whole security picture. We do not currently hold a SOC 2 Type II report — it is on the roadmap and we will not claim it before it is real. We do not sign a BAA, so if your mail regularly contains protected health information we are not the right vendor regardless of any encryption answer. And on the end-to-end encryption axis, Proton Mail and Tuta genuinely do something we do not — encrypt user-to-user mail with keys that live on your device rather than in a KMS on ours. That is a stronger posture on that one axis, and it is why we said it out loud earlier in the post.

If those three caveats do not disqualify us, the six-question sheet is the fastest way to compare our encryption story against anyone else's — including a shortlist with us on it. Our /docs/encryption page carries the full detail; /security carries the wider control set; /pricing carries the trial terms if you want to test the answers yourself.