Encryption

Most "encrypted" workspaces aren't, in the way that matters. Encryption-at-rest on a server is still encryption the server can undo — the company holds the keys, can be compelled by court order, can be acquired by a worse company, can change the policy any time. The question that matters is who holds the key. In BEAM, with encryption on, the answer is: only you.

One thing first: encryption is off until you turn it on. Everything below describes BEAM with it on. With it off, your content syncs to the server in a form the database can read — and the Quick Start tells you, accurately, that you can skip the setup step. Do not skip it.

The substrate

When you set an encryption password, BEAM derives a key from that password on your device — PBKDF2 with 600,000 rounds, split into separate content and vault keys. Your password and recovery phrase never leave your device. A copy of your key, sealed under your recovery phrase, is stored on the server so a second device can be unlocked — we cannot open it without the phrase. The content fields of your tasks, documents, messages, memory notes, and decision records are encrypted with AES-256-GCM in your browser, before anything is sent to the server. For those fields, what the server stores is ciphertext plus minimal metadata — timestamps, IDs, status, ordering — and what the server cannot do is read your content. Not because we promise not to — because we don't have the keys. Task comments, imported file names and memory category labels joined the encrypted set in September 2026 — for data written after that. Rows written before it stay as they were stored, because neither change backfilled history. Run sync force once if you want the whole history moved.

The script for your Tuesday talk, your memory note that you tend to overrun on Q&A — encrypted on your device first. Files you drag in are encrypted the same way before upload. API keys you add in Settings are sealed in the vault on your device; when you make a bring-your-own-key request, that key travels with the request through BEAM's relay to place the provider call — encrypted in transit and never written to a database. It is held in the server's memory for as long as that server process runs — server/providers/registry.ts files it in a process-global map with no eviction.

The recovery phrase

When you set your password, BEAM also generates a 24-word recovery phrase. You write it down. You save it somewhere you can find it again.

This step feels like ceremony, but it's the load-bearing piece of the privacy claim. If BEAM could recover your data when you forgot the password, then anyone with access to BEAM's servers could too. The irreversibility is the thing that makes the privacy real. Lose both the password and the phrase, and your data is unrecoverable. That isn't a bug; it's the property that prevents BEAM from ever betraying you.

This is what we mean by privacy is architectural, not policy. A privacy policy is something a company writes and can rewrite. The cryptographic structure above is something the company cannot unilaterally change without breaking the app for every existing user. That is a stronger promise than a policy — and it is not an absolute one. The gaps below say where it stops.

One consequence worth knowing: changing your password generates a new recovery phrase, and the old one stops working. Save the new one when you see it.

The honest gaps

A privacy claim that hides its gaps isn't trustworthy. Three things BEAM's architecture doesn't cover, stated plainly:

Structural metadata crosses the server in plaintext when AI tools run. When the AI works with your workspace, task titles, status, dates, and structure pass through BEAM's server so tools can act on them. Descriptions, doc bodies, memories, and messages are stripped before that payload is built — they never cross this path — but titles do, and so does interface state that can carry your words: shelved snippets, your command history, and BEAM's own generated observations about your tasks ride the same payload. Name a task "Fire the CFO" and that title is briefly visible to infrastructure that the body of your notes never is.

AI context is plaintext at the provider boundary. When you run council, ask, or any AI command, BEAM sends your relevant context — the task you're asking about, the doc content it retrieved — to Claude, GPT, or Gemini. Their servers see that content. We mitigate with HMAC-SHA-256 identity hashing (providers see anonymous IDs, not your account), timing jitter, uniform request headers, and a 12-message history cap. We don't mitigate the fact that AI providers see whatever you specifically ask them about. That's the cost of using AI on real work. If you want a hard line here, settings ai-context off stops the AI from reading workspace data at all.

The PII scanner default is opt-in. A client-side scanner can warn about or redact emails, phone numbers, SSNs, and card numbers before they reach a provider — but it currently ships off by default. Turning it on by default is tracked work.

Encryption is opt-in, and history is not rewritten when you switch it on. A workspace that ran without encryption wrote content the server could read, and turning encryption on from that point does not reach back and re-seal those rows. sync force moves them. Until you run it, some of your older content is stored the way it was written. This is tracked as an open finding rather than closed quietly.

These appear in our internal audits because hiding them would make the rest of the claim look better than it is.

What this means in practice

The Encryption tab in Settings shows your status and holds the controls: change your password (BEAM re-encrypts under the new key and issues a fresh recovery phrase), lock now, and an optional idle auto-lock timer — off by default; set it if you work anywhere shared. In the terminal, privacy shows the same status plus exactly which fields are encrypted and which remain metadata, and privacy lock clears your keys from memory on the spot.

If you ever see "encryption disabled" without remembering disabling it, treat it as a security event and reach out via feedback.

See also: Reference: Settings → Encryption · privacy