Your inbox is sensitive. We treat it that way.
> Encrypted at rest and in transit, encrypted credentials, no selling or training on your data, and a clear deletion path.
> The boring, correct stuff.
Encryption in transit
TLS protects web, MCP, provider API, and IMAPS connections in transit.
Encryption at rest
Credentials are encrypted with AES-256-GCM using per-user derived keys before being written to Postgres or cache. App passwords are never stored in plaintext.
Minimal access scope
CME requests only what it needs. For Gmail IMAP, that means read/write mail access — no account management, no settings changes. Future OAuth integrations will use gmail.modify scope.
No training on your email
We do not use your messages to train models. Period. You bring your own Anthropic or OpenAI key, or use your AI provider's paid seat.
Data residency
US (primary). Attachments stored via S3-compatible storage with signed URLs.
Deletion on request
Disconnect an account to remove its credentials and indexed metadata. Account-deletion requests are completed within 30 days, except where law requires retention.
Where we are, and where we’re going.
- 01SOC 2 Type I — in progress (target: Q3 2026)
- 02GDPR — DPA available on request
- 03Google OAuth — verification in review (Limited Use scopes)
- 04Microsoft 365 / Outlook — coming soon
- 05Sub-processors list published and versioned
What actually happens when your agent asks for email.
- 01Your MCP client sends an authenticated request to your personal CME endpoint.
- 02CME looks up which connected account(s) the request targets.
- 03We hit Gmail API / Graph / IMAP with your stored token, or serve from our local thread index.
- 04Results stream back to the MCP client. Your chosen AI provider handles them under that provider's terms and privacy policy.
- 05Sync daemons pull new mail incrementally; nothing sits in a queue longer than it has to.
Questions about our threat model?
> Real responses, usually same-day.