> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kvelden.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rooms

> Secure encrypted workspaces for your team.

## 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.

| Mode                                  | Who holds the keys                              | Server-side workflows (DLP, signing, search, previews)         |
| ------------------------------------- | ----------------------------------------------- | -------------------------------------------------------------- |
| **Envelope** (default)                | Enclave, wrapped by your organisation's KMS/HSM | Always available                                               |
| **Zero-Knowledge**                    | Only the members' devices                       | Available, but each one requires the relevant member's consent |
| **Zero-Knowledge Strict (ZK Strict)** | Only the members' devices                       | Never available, under any circumstances                       |

### Envelope

The default mode, described in detail in [Encryption](/enclave/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.

<Warning>
  Your passphrase cannot be reset. If you forget it, an admin must grant your replacement key access to each room again — files encrypted before that point cannot be recovered for you (other members are unaffected).
</Warning>

#### 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:

| Content                                              | Encrypted with the REK?                                                      |
| ---------------------------------------------------- | ---------------------------------------------------------------------------- |
| Files                                                | ✓ — each file has its own key (DEK), wrapped by the REK                      |
| Chat messages                                        | ✓ — each message has its own key, wrapped by the REK                         |
| Room secrets                                         | ✓                                                                            |
| Full-text search index, file previews, link previews | Not generated — these require server-side plaintext, which Enclave never has |

#### 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.

<Note>
  See [Zero-Knowledge Design](/security/zero-knowledge) for the full security model behind Zero-Knowledge and ZK Strict rooms, including what Enclave can and cannot see at every step.
</Note>

## Room roles

| Role        | Upload | Download | Manage members | Delete room |
| ----------- | ------ | -------- | -------------- | ----------- |
| Owner       | ✓      | ✓        | ✓              | ✓           |
| Contributor | ✓      | ✓        | —              | —           |
| Viewer      | —      | ✓        | —              | —           |

## 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

<Warning>
  If a user is removed from an Org Unit, they lose access to all rooms owned by that Org Unit — not just one room. Review Org Unit membership carefully before removal.
</Warning>

<Note>
  Classified rooms enforce a **clearance floor** on membership: joining a room classified **Internal**, **Confidential**, or **Restricted** requires a clearance of at least **C2**, **C3**, or **C4** respectively. If a user's clearance is below the room's floor, Enclave refuses the membership with a clear reason — raise the user's clearance first (see [Clearance Levels](/organization/clearance)).
</Note>

## File classification

Each file in a room carries a classification label:

| Label             | Access required                                    |
| ----------------- | -------------------------------------------------- |
| C1 — Public       | Any authenticated user                             |
| C2 — Internal     | Clearance ≥ C2 (default for most users)            |
| C3 — Confidential | Clearance ≥ C3                                     |
| C4 — Restricted   | Clearance ≥ C4 (owners and security officers only) |

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](/enclave/sharing-policies#external-links-to-confidential-data-approval-workflow))
* 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.

<Note>
  External guest uploads are currently available in **Envelope** rooms only. In Zero-Knowledge and ZK Strict rooms, guests can view and download but not yet upload.
</Note>

## 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

<Danger>
  Deleted rooms cannot be recovered. Ensure you have an offline backup of any files you need to retain before deleting a room.
</Danger>