Workspace Protection

Workspace Protection adds client-held cryptography to a workspace. It is a workspace-level security capability, not a WebTTY-only feature.

Workspace Protection requires an Enterprise workspace. Hosted Basic and Pro projects can still use normal rstream authentication, project permissions, token policy, and explicit-key WebTTY E2E where configured, but they do not get workspace-managed key custody, trusted browser/device approval, or Recovery Kit flows.

When Workspace Protection is active, selected protected data can be opened only from trusted browsers, trusted devices, or the workspace Recovery Kit. rstream stores public keys, encrypted envelopes, signatures, metadata, and audit events. It does not store the private key material needed to open protected data by itself.

Protected access is a chain. Authentication and permissions are still required, but protected data also needs trusted local key material.

account authentication
        |
        | verifies the rstream user
        v
workspace and project permissions
        |
        | authorize the action
        v
trusted browser or trusted device
        |
        | holds local private key material
        v
protected workspace data

This layering is deliberate. A signed-in user can be allowed to view a workspace and still be unable to decrypt protected data from an untrusted browser. A trusted device can hold decrypt material and still be blocked by permissions if the user or credential does not have access to the workspace, project, server, session, or log.

What it adds

Transport encryption protects network connections. Authentication and permissions decide who can call APIs and runtime surfaces. Workspace Protection adds a separate client-side boundary for data that must remain unreadable to rstream servers without trusted local key material.

WebTTY uses this model for workspace-managed terminal encryption and encrypted recordings. The same model can protect other sensitive workspace data over time, such as security-sensitive audit material or protected configuration.

Workspace Protection does not replace access control. A user still needs the right workspace, project, and WebTTY permissions. The additional rule is that authorization alone is not enough to decrypt protected data. The browser or device must also hold trusted local keys.

The model is close to a password-manager trust model. The service can sync encrypted envelopes, enforce account and workspace policy, and coordinate device approval, but the useful plaintext boundary is local to trusted clients.

Product availability

Workspace Protection is an Enterprise workspace feature. It is not enabled on individual Basic or Pro hosted projects, and it is not part of the public self-hosted Community Edition image.

Explicit-key WebTTY E2E remains useful outside Enterprise workspaces. The operator owns direct endpoint identity distribution. Workspace Protection is the enterprise path where workspace policy, device approval, recovery, and protected data envelopes are managed as one product surface.

Setup requirements

Workspace Protection is not fully set up until an owner or admin has completed the setup flow and saved the Recovery Kit offline.

The initial setup creates a workspace keyset, trusts the first browser, and creates the first Recovery Kit. The Recovery Kit is workspace-wide. It is not tied to one user or one browser. If every trusted browser, every trusted device, and the current Recovery Kit are lost, rstream cannot recover protected workspace data.

This is the intended zero-trust tradeoff. rstream can coordinate access and store encrypted envelopes, but it cannot recreate private workspace key material from server-side data alone.

Initial setup is one ceremony. The workspace is not fully protected until both the first trusted browser and the Recovery Kit envelope exist.

owner/admin browser
        |
        | setup Workspace Protection
        v
workspace keyset created locally
        |
        +--> first trusted browser envelope
        |
        +--> workspace Recovery Kit envelope
        |
        +--> workspace metadata and audit event stored by rstream

The setup flow completes these steps before the workspace is marked active:

1. Confirm the workspace is Enterprise and the current user is an owner or admin.
2. Create the workspace keyset locally in the browser.
3. Trust the current browser.
4. Create the Recovery Kit and store it offline.
5. Mark Workspace Protection as active only after the Recovery Kit is registered.

If the Recovery Kit step fails, the setup is incomplete. The workspace remains in setup state and returns the owner/admin to the setup flow instead of presenting the workspace as fully protected.

Trusted access paths

A trusted browser is used by the Dashboard and other browser UI flows. Its private keys live in that browser profile.

A trusted device is used by CLI, agent, service, and automation workflows. Its private keys live under the local rstream workspace directory.

Both can unlock protected workspace data, but they are separate cryptographic devices. Trusting a browser does not automatically trust the local CLI. Trusting a CLI device does not automatically trust the browser.

Approval flow

A new browser or device generates private keys locally and sends only public material plus proof metadata to rstream. A trusted owner/admin compares the verification code shown by the requester with the verification code shown to the approver.

If the codes match, the trusted client signs the approval and encrypts the workspace private bundle for the new browser or device. If the codes do not match, the request must be rejected.

The verification code is derived from the public keys, workspace id, device kind, WebTTY key material when present, and fingerprint. This prevents the server from silently swapping the public key during approval without changing the code.

rstream can coordinate a request, but it cannot decide trust alone. Approval happens from a trusted browser or device after the code has been compared.

requesting browser or device
        |
        | public key, kind, fingerprint, proof metadata
        v
rstream coordination API
        |
        | pending request
        v
trusted owner/admin browser or device
        |
        | compares verification code with requester
        | signs approval and wraps workspace keys for requester
        v
requester becomes trusted

rstream cannot safely approve a new access path on its own. It can store the request, enforce who may approve it, and record the decision. The actual trust decision must be made from a trusted client after the verification code has been compared out of band.

Recovery

The Recovery Kit is the offline fallback for the workspace keyset. Print it or store it outside the normal rstream account path. Anyone with the current Recovery Kit can recover protected workspace data, so treat it as a high-value secret.

Rotate the Recovery Kit if it may have been exposed or after an operational recovery. Rotation creates new recovery material and registers a new encrypted envelope. Treat the old kit as invalid only after the replacement is active and stored offline.

Recovery is intentionally local. The browser decrypts the kit locally, then registers a new trusted-browser envelope; rstream never receives the workspace private bundle in plaintext.

Recovery Kit entered in browser
        |
        | parsed locally
        v
workspace key bundle decrypted locally
        |
        | new trusted browser envelope created
        v
rstream stores metadata and encrypted envelope

The service records that recovery happened, but it does not receive the recovered private workspace key bundle in plaintext.

What rstream stores

Workspace Protection still needs server-side state. The important boundary is what kind of state is stored.

Protected application data, such as workspace-managed WebTTY terminal payloads or encrypted session recordings, is stored as encrypted payloads plus metadata. Metadata can remain useful for listing sessions, retention, billing, and audits; terminal content requires a trusted local decrypt path.

Runtime responsibilities

Workspace Protection separates setup responsibility from runtime responsibility. This distinction matters for workspace-managed WebTTY because several components participate in one protected session, but none of the server-side components should be able to decrypt terminal payloads by itself.

trusted browser / device
        |
        | signed workspace credential
        v
rstream engine
        |
        | checks active trusted device and policy
        v
WebTTY server
        |
        | verifies WebTTY client proof against pinned workspace trust
        v
remote shell

The engine can block a revoked device from starting a new session, but it cannot create a valid client proof by itself. A captured workspace credential is not enough to open a protected terminal because the WebTTY server also requires a fresh WebTTY client proof from the trusted client private key. Conversely, a valid WebTTY proof is not enough if the engine no longer considers the device active.

Failure modes

Workspace Protection fails closed.

Relationship with WebTTY

Workspace-managed WebTTY E2E requires Workspace Protection. A registered WebTTY server using workspace_managed encryption must be enrolled from a trusted workspace device. During enrollment, the runtime host pins the public workspace keyset identity it needs to verify workspace-managed WebTTY client proofs; it never receives workspace private keys and does not depend on the Control plane at session runtime.

Lightweight WebTTY can still use explicit-key E2E without Workspace Protection. That path is local and operator-managed.

The full cryptographic model is documented in Encryption Model. WebTTY setup is documented in End-to-End Encryption.