# Encryption & privacy, in depth

*Last updated 11 July 2026 · Operated by Govannon, Netherlands · Covers the Lexicanon meeting-intelligence platform.*

**The short version.** For Lexicanon workspaces, your meeting content is encrypted at rest under a key that
belongs to your organisation alone — the transcript, the summary, the names and emails, the audio, all of it.
The key that unlocks those keys is held separately from the database, so a stolen database or backup is just
ciphertext. You hold two dials: *who can read your data at rest* and *whose infrastructure processes it*. This
page is honest about the one thing encryption can't do — hide your words from the AI while it's actively
reading them.

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 (/real-talk); for
every third party that touches your data, the Data Flows page (/data-flows).

## 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 (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.** Your per-organisation Data Key (DEK) is stored only as ciphertext, wrapped by
  the platform Key-Encryption Key (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 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. No 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 your bring-your-own-key provider credentials too — they're 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:

- **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. 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: *who can read it at
rest* (key custody) and *whose infrastructure processes it* (transcription and AI).

- **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 the Data Flows page.
- **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

1. **Capture** — your device records; no bot joins the call.
2. **Live transcription** — speech-to-text streams in; a rolling summary appears.
3. **Analysis** — the finished transcript becomes an AI summary, decisions and action items.
4. **Sealed at rest** — everything above is sealed under your org's DEK: transcripts, summaries, names,
   emails, search vectors, reports, chats, and the audio and transcript files on disk. Only start time and
   duration stay plaintext, by design.
5. **Tenant isolation** — only your workspace can read it; every request and row is scoped to your
   organisation on the server.
6. **Erase** — crypto-shred the key, making all of it unreadable live and in backups.

Steps 1–3 must read your words in the clear to do the work; from step 4 on, everything sits sealed and
workspace-isolated until you choose to destroy it.

## 5. Where we draw the honest line

To turn your audio into a transcript and a summary, a computer has to read it in the clear. During steps 1–3
your data is decrypted in memory on our servers — and, unless you self-host or bring your own keys, briefly at
the AI provider. So:

- We are **not "zero-knowledge" and not end-to-end encrypted** while running cloud AI. Nobody doing cloud
  meeting-AI is. Encryption protects your data *at rest* and *in backups* — not from a server 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 (roadmap). A passphrase bolted onto a cloud service that
  still processes your data is not that.

## 6. On the roadmap (not built yet)

- **Customer-held / revocable keys** — moving key custody to you so the operator cannot read your data at
  rest. Designed, routed through the code as an explicit "not yet", not live.
- **Confidential computing** — hardware-attested secure enclaves so even we can't read your data in memory.
  Maturing fast; not 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's 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.

---

*Markdown edition for AI assistants — canonical page: [https://lexicanon.com/security](https://lexicanon.com/security) · Lexicanon.*