Knowledge base
Encryption at rest
Bodies, attachments and what you write are sealed before they are stored, so a copy of the database is ciphertext rather than mail.
Details
- Live. Message bodies and attachments are sealed before they are stored, and so is what you write around them: notes, thread summaries, assistant chat messages, calendar details, rules and the settings you choose. Each value is sealed with AES-256-GCM under a key derived for it alone, bound to the field it belongs in, and tagged with the id of the key that made it.
- The server holds the key. A copy of the database or of stored files is ciphertext, while the server itself can still open what it stores to thread, search and summarise. End-to-end encryption is a different claim: there the key is yours and the mail is unreadable here.
- Some fields stay readable on purpose. Search runs on the sender, subject and first 4,000 characters of each thread’s newest message, so those stay as they are. Most addresses, contact names and filenames stay readable too, because mail is routed and matched on them, and so do timestamps and your domain.
- Where a sealed value must be found by exactly what it is, such as an attendee’s address or a rule’s name, a keyed hash sits beside it. The same value always gives the same hash and the hash gives nothing back, so the lookup works without opening the field.
- One rule decides what gets sealed: what a person wrote or chose is sealed, what the machine chose is not. A hash, a token digest or a key published on purpose stays readable, because sealing it would add nothing.