Rooms

​

What is a room?

A Room is an encrypted workspace. It has its own key, its own member list, and its own audit log. Every file uploaded to a room is encrypted with that room’s key — members outside the room cannot decrypt the files even if they obtain the ciphertext.

​

Creating a room

1. Navigate to Rooms in the sidebar
2. Click New Room
3. Set a name, optional description, and classification level
4. Click Create

The room is immediately active. You are automatically set as the room owner.

​

Encryption modes

Every room uses one of three encryption modes, chosen when the room is created. The mode cannot be changed afterwards, so choose carefully.

​

Envelope

The default mode, described in detail in Encryption. Files are encrypted on your device before upload, and the per-file key (DEK) is wrapped by a server-side key (KEK) that is itself protected by your KMS/HSM. This lets Enclave run server-side workflows — DLP scanning, e-signatures, full-text search, link previews — without ever storing plaintext.

​

Zero-Knowledge and Zero-Knowledge Strict (ZK Strict)

Zero-Knowledge and ZK Strict rooms share the same client-side key architecture. The only difference between them is whether a server-side workflow may ever request temporary access to room content — Zero-Knowledge allows it with your explicit, per-action consent; ZK Strict never allows it under any circumstances.

​

Setting up your encryption key

The first time you open a Zero-Knowledge or ZK Strict room, Enclave asks you to set up encryption: you choose a passphrase, and your browser generates a personal key pair (X25519).

• Your private key is encrypted on-device with a key derived from your passphrase (PBKDF2-HMAC-SHA-256, 600,000 iterations) before anything is sent to Enclave.
• Enclave stores only this encrypted copy. Your passphrase itself is never transmitted, and Enclave has no way to recover it.
• One key pair covers every Zero-Knowledge/ZK Strict room you belong to — you set it up once, then unlock it with your passphrase at the start of each browser session.

​

The room encryption key (REK)

Each Zero-Knowledge/ZK Strict room has one symmetric room encryption key (REK). Rather than being wrapped by a server-managed KEK as in Envelope mode, the REK is wrapped individually — using ECIES (X25519 + HKDF-SHA-256 + AES-256-GCM) — for every member’s public key. Enclave stores one of these wrapped copies per member, but never an unwrapped REK, so it has nothing on its own capable of decrypting the room. The REK in turn protects:

​

Getting access

Because the REK must be wrapped specifically for your key before Enclave can hand it to you, new members (and external guests, below) don’t get instant access:

1. After you set up encryption, Enclave automatically requests access to the room’s REK on your behalf.
2. Any room admin who is currently online sees a pending access banner listing everyone waiting, and can grant access with a single click — this wraps the current REK for each waiting member or guest using their public key.
3. Until access is granted, you can see the room and its file list, but cannot open, download, or decrypt anything inside it.

​

Key rotation

When a member is removed from a Zero-Knowledge/ZK Strict room, Enclave prompts an admin to rotate the room’s encryption key. Rotation runs entirely in the admin’s browser:

1. A brand-new REK is generated.
2. It’s re-wrapped for every remaining member and any external guests with active access.
3. Every file, chat message, and secret in the room is re-encrypted under the new REK.

The removed member’s copy of the old REK cannot decrypt anything created after rotation. At no point does the server see an unwrapped REK, before or during rotation.

​

Server-side workflows and consent

• Zero-Knowledge — Workflows such as e-signature requests can still run, but each one requires you to explicitly enable it for that specific item. When you do, your browser decrypts that one file locally, computes a cryptographic hash, and sends only the hash — not the file — to the server, which is enough to issue a verifiable signing certificate without ever exposing plaintext.
• ZK Strict — These workflows are unavailable. The relevant actions don’t appear in the UI, and the server rejects the corresponding requests outright. Choose this mode for content that must never be processed server-side under any circumstances — for example, material under legal hold or subject to strict regulatory confidentiality.

​

External guests

Zero-Knowledge/ZK Strict rooms can still include guests from outside your organisation, invited individually by a room admin. On first access, a guest sets up their own vault — a passphrase-protected key, created once and reused for every Zero-Knowledge/ZK Strict room your organisation shares with them afterwards. As with internal members, an admin must grant the guest access to a room’s REK before they can decrypt anything in it. Guests view and download files entirely in their browser: each file is decrypted client-side, and a confidential watermark — the guest’s email address, verification details, and a timestamp — is applied before display or download. Enclave’s servers handle only ciphertext throughout.

​

Room roles

​

Adding members

Only users who are members of the Org Unit that owns the room can be added as room members.

1. Open the room
2. Click Members → Add member
3. Select users from the Org Unit
4. Assign a role

​

File classification

Each file in a room carries a classification label: Classification is set at upload time and can be changed by room owners and contributors.

​

External guest access

Rooms can host external guests — counterparty lawyers, auditors, vendors — without giving them an Enclave account. A room admin enables Allow external users in the room’s Policies tab, then issues individual invitations from the External access tab. Each invitation carries:

• A role (Viewer or Contributor) controlling what the guest may do in the room, and — for Contributors — an optional per-invitee upload grant (see below)
• A clearance ceiling (C1–C4) capping the highest classification the guest may open — a C3/C4 ceiling is held for admin approval (see Sharing Policies)
• An authentication method — the guest’s corporate SSO (OIDC) or one-time email codes

The clearance ceiling can never be set below the room’s own classification floor: inviting a guest into a room classified Confidential requires a ceiling of at least C3. Enclave pre-selects the floor and refuses anything lower. Guests work in a dedicated portal scoped to that single room. Every guest session is attested, and every action is written to the audit log.

​

Managing guest access over time

Room admins control the full lifecycle of an invitation from the External access tab:

• Suspend / Reactivate — a reversible pause. While suspended, the guest cannot sign in and any live sessions are blocked on their very next request; reactivating restores access without re-inviting (existing sessions resume working). Use this when a deal is on hold or an access review is in progress.
• Rotate link — if an invite link may have leaked, rotating mints a fresh link (emailed to the invitee) and kills the old one immediately, without changing the invitation’s terms or the guest’s sessions.
• Revoke — terminal: the invitation and all of its sessions are permanently terminated. For a temporary block, use Suspend instead.
• Re-invite — one click on a revoked or expired invitation opens a new invitation pre-filled with the same terms (role, clearance ceiling, upload grant, domain restriction). A C3/C4 ceiling goes through justification and admin approval again.
• Status filter — revoked and expired invitations are deliberately retained (attestations, evidence packages, and the audit trail hang off them); filter the list by status to declutter instead of deleting.

Every lifecycle action — suspend, reactivate, rotation, revocation — is written to the immutable audit log.

​

External guest uploads

Due-diligence workflows are bidirectional — counterparties often need to submit documents, not just read them. Rooms support this as an explicit, admin-controlled capability:

1. In the room’s Policies tab, enable Allow external guest uploads. This is the master switch — it is available only when Allow external users is on, and is off by default.
2. Grant upload access per invitee: when creating a Contributor-role invitation, tick Allow this guest to upload files — or toggle the grant later on an existing invitation from the External access tab (the upload icon on the invitation row). Grant changes are live: they take effect on the guest’s next request, no re-invite needed. Only guests whose invitation carries this grant can upload — other contributors and all viewers cannot, even with the room policy on.
3. Every external upload requires admin approval. Submitted files land in a pending state — room members cannot see or open them until a room admin releases them. Pending guest uploads appear in an awaiting review banner at the top of the room’s Approvals tab, where an admin can Approve or Reject them directly, or route them through a multi-person approval workflow instead. The guest sees their own submissions with a Pending approval badge and is notified of the decision by email; rejected files remain visible only to the uploader.

External uploads travel the exact same pipeline as internal ones — encrypted client-side before upload, scanned by DLP, classified automatically — and count toward your organisation’s storage quota. Guests cannot attach sharing options, PINs, access limits, or expiry to the files they submit. To limit abuse, each guest session is capped at 50 uploads / 1 GiB by default. On the private appliance these caps can be tuned with the EXT_UPLOAD_MAX_FILES and EXT_UPLOAD_MAX_BYTES environment variables.

​

Sharing files externally

Room owners can share individual files with users outside the organisation via a time-limited, encrypted share link. The link includes a short-lived access token — it cannot be used after expiry. External share links do not grant room access. The recipient can download only the specific file.

​

Archiving and deleting rooms

• Archive — room becomes read-only; files are retained and auditable
• Delete — permanently removes all files and keys; this action is irreversible