VM-level isolation
Each workspace has its own guest kernel and root filesystem. Workspace apps share that VM; app releases do not create a separate micro-VM for each app. Treat workspace administrators and code with guest root access as trusted with that workspace’s contents. The platform uses network and service authorization boundaries in addition to VM isolation. Do not interpret a VM boundary as a guarantee that all outbound network access is blocked or that malicious code cannot contact public APIs.Credential protection
Platform secrets
Control-plane credentials are not required in ordinary workspace code. VM-local Rigbox services use the workspace’s bridge-network identity, scoped to its compute node, rather than a personal account key copied into the guest. The CLI inside a workspace uses this ambient identity for supported workspace-scoped commands. Use the execution-mode reference for its actual command surface. The workspace bridge that carries those commands serves only the calling workspace’s resources. It doesn’t serve account API keys or SSH keys, and it serves account-wide settings (AI defaults, setup scripts, and service specs) read-only. Code in one workspace, including an AI agent, can’t use it to add a key that reaches your other workspaces or to change a script that runs in them. Deploys from inside a workspace upload into that workspace only.AI provider keys
Managed AI routes requests through the platform proxy without requiring your provider key in application code. BYOK means supplying credentials for your own provider. If a credential is injected into the guest or application’s environment, code there can read it. Do not claim that environment injection makes a secret inaccessible or guarantees it never reaches disk. Applicationsecrets: are deployment inputs, not a promise of an encrypted application secret store. Treat environment output, app metadata, logs, and process access as potential disclosure paths.
API keys
Personalrb_ API keys grant account access. Keep them on a trusted local machine or backend, rotate them when exposed, and never distribute your own key to end-user browser code or an untrusted workspace.
GitHub deployment credentials are a distinct short-lived credential flow bound to a repository/workspace. They are not interchangeable with personal account keys.
App access control
Private, public, and email-restricted app visibility governs access through the app route. It does not isolate apps sharing a workspace or secure a database against other code with local access. Apply application authentication when your own product needs it. For programmatic access to a private route, use an authorized key as described in authentication. A valid key alone does not grant access to every owner’s app.SSH authentication
Workspace SSH uses public keys registered on your account.rig login registers your local key and writes a host entry per workspace, and the target returned by rig workspace ssh-info is the one to use; see SSH access. The workspace SSH path and the separate SSH TUI gateway are different. Do not infer the host, username, or port from an old infrastructure diagram.
The CLI records the gateway’s host keys in its own ~/.config/rigbox/known_hosts and adds keys from a later scan only when they agree with a key already on file, so a changed host key still fails host-key checking. A workspace login runs a fixed command that connects you to your own VM. Port, agent, and X11 forwarding and tunnels are turned off for these logins, so an SSH session can’t reach services on the host it passes through.