BEAMdocs usebeam.sh →

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, the answer is: only you.

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. The keys never leave your device. 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. What the server stores is ciphertext plus minimal metadata — timestamps, IDs, status, ordering. What the server cannot do is read your content. Not because we promise not to — because we don't have the keys.

The script for your Tuesday talk, your memory note that you tend to overrun on Q&A, the API key you added in Settings — all encrypted on your device first. Files you drag in are encrypted the same way before upload.

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. Betrayal is structurally impossible, not just contractually forbidden.

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. 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. Flagged to flip to default-on before public beta.

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