Message encryption

OrganizeOS encrypts every message at rest. This page is the admin-facing version of the model: what the protection actually buys you, when the platform can decrypt, and how to plan around legal exposure. The member-facing version lives at message privacy.

What encryption at rest protects against

Every channel, DM, and group message is encrypted with AES-256 before it is written to the database. Each channel has its own key, and those keys are themselves encrypted by a platform-level master key. Message plaintext never lives on disk.

About the cipher. AES-256 is the same encryption standard used by governments to protect classified data, by banks to protect financial records, and by end-to-end messengers like Signal. The key space is 2^256, which is large enough that brute-forcing a single message is computationally infeasible with current or foreseeable hardware (including quantum computers, against the symmetric portion of the system). The strength of the cipher is not where this model can fail. The honest limits in the rest of this page are about key handling, not about an attacker breaking the math.

The encryption defeats a specific and important category of attack: anything that gets the data without getting the key. Concretely, that covers most of the realistic ways a workspace's conversations can leak:

• Database breach. If an attacker pulls the message database, they get ciphertext. The conversations are unreadable without the master key, which lives separately.
• Backup or snapshot theft. Database backups, replicas, and point-in-time snapshots all carry the encrypted form. A leaked backup is unreadable for the same reason.
• Cloud-storage misconfiguration. The most common source of accidental data exposure (open buckets, wrong permissions, leaky exports) returns ciphertext, not plaintext.
• Unauthorized staff access. No staff member can browse messages by querying the database directly. The decrypt path is server code that runs only when a signed-in member has a valid reason to read a message; ad-hoc database access returns scrambled data.
• Lost or stolen infrastructure. A leaked disk image, a misplaced drive, a former contractor's lingering access: none produce readable messages without the master key.

These are not theoretical attacks. Most data exposure incidents in the wild fall into one of those categories, and at-rest encryption makes the exposed data useless to the attacker. Your members' conversations stay private through the failure modes that actually happen.

How decryption works

The platform holds the master key, which means it can decrypt your messages in four specific situations. Each is intentional and necessary for the product to work:

Reading a message. When a member opens a channel or DM, the server decrypts in memory and serves the plaintext to their browser. This is the normal read path; the interface cannot display messages any other way.

Running a search. When a member searches, the server pulls candidate rows, decrypts them in memory, runs a substring match, and returns the results. The plaintext exists only for the duration of the request.

Org-admin moderation review. Your organization's admins can review messages within your own org for legitimate moderation purposes: handling reports, enforcing your community standards, or investigating a policy complaint. Moderation reviews leave an audit trail.

Legally compelled production. If the platform receives a valid subpoena or court order requiring production of records, it can be compelled to decrypt and produce them. Overbroad requests are challenged where appropriate, but the system cannot truthfully tell a court "we technically cannot decrypt this."

When you describe the encryption to your members, the precise version is: "OrganizeOS encrypts messages at rest. The platform can decrypt them for moderation or under court order, and we use Signal for conversations where that is not acceptable." That sentence is true, and it is stronger than the vague claim most workspaces make.

What this does not protect against

These limits do not undo the protections above. They describe situations where a different tool, not tighter encryption-at-rest, is the right answer.

Legitimate account access. Anyone with a member's credentials sees their messages. The encryption is server-side; the member's browser receives plaintext after sign-in. A compromised account is not a database breach, and the fix is account security (strong passwords, two-factor authentication, current device review), not encryption.

Insider access. With the master key, a malicious operator could decrypt anything. This model relies on operator trust; it does not protect against the platform itself acting in bad faith.

Legal compulsion combined with infrastructure access. A court order paired with access to the master key defeats this model. The mitigation is not tighter encryption at rest; it is using Signal or Matrix for conversations where this threat is realistic.

These limits are also documented for your members in the in-app encrypted-message explainer, so the model in their heads matches the one the platform actually provides.

Subpoena exposure and how retention bounds it

At-rest encryption and aggressive retention together give your organization a real subpoena-defense posture without needing true end-to-end encryption:

• For current conversations, the platform can decrypt under legal compulsion. Sensitive planning that must be subpoena-resistant does not belong on OrganizeOS.
• For historical conversations, retention deletion is the strongest defense. A channel with a 7-day retention window has nothing older than 7 days for anyone to compel production of. The ciphertext is gone, and the key has nothing left to unlock.

A practical playbook for organizations with serious subpoena concerns:

1. Use Signal or Matrix for planning conversations where the legal exposure of participants depends on the content staying private.
2. Use OrganizeOS with short retention windows (7 to 30 days) for routine coordination that benefits from being in the same platform as your CRM, events, and member data.
3. Use OrganizeOS with longer or indefinite retention for institutional knowledge that needs to survive turnover: process documentation, governance discussions, and public-facing positions.

Retention is set per-channel, so different channels in the same workspace can carry different policies.

Why this matters

A workspace's communications are more legally attractive than those of most consumer apps. The combination here (real at-rest encryption against the failure modes that actually happen, honest framing of where the platform can decrypt, short retention windows where appropriate, and a clear pointer to true end-to-end tools for sensitive cases) is a defensible posture that does not depend on claims the platform cannot back up. When a member asks whether their messages are private, you can answer precisely rather than vaguely. The precision is itself part of the security guarantee.