Encryption & privacy, in depth
A note on honesty, same as every page here: this describes what the product does today. Where something is planned but not built, it's labelled roadmap and never implied as present. For the plain-language version see The Real Talk; for every third party that touches your data, the Data Flows page.
1 · Envelope encryption, layer by layer
"Encrypted at rest" is often just "the disk is encrypted" — which only helps if someone physically steals the drive, and does nothing against a leaked database dump. Lexicanon encrypts the actual column values and files, at the application level, under a key unique to your organisation. The scheme is envelope encryption: a fast key encrypts your data, and a second key encrypts that key.
- AES-256-GCM, per value. Each sealed value gets a fresh random nonce and an
authentication tag, stored as a versioned
encgcm2:envelope. GCM is authenticated encryption, so tampering is detected, not silently decrypted. - Bound to org and column. Your organisation id and the column's name are folded into each ciphertext's tag but never stored (this is "additional authenticated data"). Move a ciphertext to another tenant's row or a different column and it fails the integrity check — it cannot be quietly re-used.
- The key protects the keys. The DEK is stored only as ciphertext (wrapped by the KEK). The KEK — the platform master key — is a cluster secret that is never written into the database or any backup. That's what makes a leaked database or an off-site backup useless on its own.
- Rotation without downtime. A DEK carries a version. You can mint a new one; data written under the old version still reads, and new writes use the new key. Nothing has to be re-encrypted in a flag-day migration.
- Crypto-shred erasure. Destroying an org's key makes every sealed value mathematically unreadable — on live systems immediately, and unrecoverable from backups once the key is purged from the separate key store. "Deleted" means deleted, not "flagged hidden".
The same envelope primitive protects a smaller, older set of settings too — your bring-your-own-key provider credentials are encrypted (AES-256-GCM) before they're stored, so one database leak can't spill every tenant's keys at once.
2 · What exactly is sealed
Encryption at rest is on by default for Lexicanon workspaces (a workspace can deliberately turn it off; almost none do). When it's on, everything that carries meeting content is sealed under your org's DEK:
| Sealed under your key | What it is |
|---|---|
| Transcript & summaries | The streamed transcript segments, the final analysis (summary, decisions, action items), the live rolling summaries, chapter markers, and any translated analyses. |
| Names & emails | The meeting subject, speaker names, and attendee emails. |
| Search text & vectors | The indexed transcript text and the embedding vectors used for search — sealed, not just the readable copy. |
| Reports, edits & Ask-AI | Generated report artifacts, your manual edits to fields, and your Ask-AI conversations about a meeting. |
| Files on disk | The audio recording and the on-disk transcript, summary, metadata and embedding files — sealed under the same per-org key on the persistent volume. |
A small amount of derived, non-content metadata stays plaintext by design: the meeting start time and its whole-minute duration. These aren't content — they're derived numbers — and keeping them readable lets your meeting list load without unsealing every row. Timing sidecars with no content stay plaintext for the same reason. Everything a human would recognise as the meeting itself is encrypted.
3 · Two dials you control
Two independent choices decide how much you trust the platform operator with your data. One is about who can read it at rest (key custody); the other is about whose infrastructure processes it (the transcription and AI step).
- Processing exposure (available today). Run on our EU infrastructure with our AI, bring your own keys so transcription and AI hit your provider accounts under your contracts, or self-host so your audio and storage never leave your network. Every third party is named on Data Flows.
- Key custody (today: platform-held). Your DEK is wrapped by the platform KEK, which we hold. That defeats database, backup and replica leakage — but it is not operator lockout: we can still unwrap the key to run the service.
- Customer-held keys — roadmap. A tier where custody moves to you and the operator genuinely can't read your data at rest is designed but not shipped. Until it is, we won't imply it exists. If you need "the vendor cannot read it" today, the honest answer is self-host or BYOK.
4 · The life of a meeting
From the moment you hit record to the moment you erase it — and who can read it at each step.
5 · Where we draw the honest line
Here's the part most vendors won't print: to turn your audio into a transcript and a summary, a computer has to read it in the clear. During steps 1–3 above, your data is decrypted in memory on our servers — and, unless you self-host or bring your own keys, briefly at the AI provider that does the transcription and write-up. So:
- We are not "zero-knowledge" and not end-to-end encrypted while running cloud AI. Nobody doing cloud meeting-AI is, whatever the homepage says. Encryption protects your data at rest and in backups — not from a server that is actively processing it.
- If you need "the vendor genuinely cannot read it", the real answers are running the AI on your hardware (self-host), or hardware-attested secure enclaves (see the roadmap below). A passphrase bolted onto a cloud service that still processes your data is not that.
6 · On the roadmap (not built yet)
Things we think are real and haven't shipped. We'll say so plainly the day they change:
- Customer-held / revocable keys. Moving key custody to you so the operator cannot read your data at rest — the top row of the two-dials diagram. Designed, routed through the code as an explicit "not yet", not live.
- Confidential computing. Hardware-attested secure enclaves — the genuine way to process your data so even we can't read it in memory. Maturing fast; not something we run today.
- A fully offline AI mode. A local model with zero external calls. Self-hosting keeps audio and storage on your infrastructure today, but the AI write-up step still calls an external provider — there is no fully-local model option yet.
- Automatic time-based retention. Scheduled expiry isn't built; we keep your data until you delete it, and whole-workspace erasure is handled on request.
7 · Also true today
- Walled-off workspaces. Every request and stored record is tied to your organisation; the server refuses anything that crosses that line.
- Encrypted connections. All traffic to and from the service is encrypted (TLS).
- Locked-down runtime. The app runs as a non-administrator user with OS privileges stripped to the minimum — no privilege escalation, a standard kernel sandbox.
- Audit trail. Sign-ins, deletions, member and settings changes are recorded per workspace and visible to your administrators.
- Voiceprints stay put. Cross-meeting speaker recognition uses a numeric fingerprint, never the audio, and it never leaves your workspace.
- No compliance theatre. We don't wave badges we don't hold. If a certification is genuinely useful we'll pursue it and say so — not use a logo as a stand-in for whether we can read your data.