Security & Isolation
Rigbox is designed to run untrusted code safely. Every workspace is an isolated micro-VM with no access to platform secrets, other users’ data, or the control plane.VM-level isolation
Each workspace runs in a Firecracker micro-VM — not a container. This means:| Property | What it means |
|---|---|
| Dedicated kernel | Each VM boots its own Linux kernel. No kernel sharing between workspaces. |
| Separate filesystem | Each VM has its own ext4 disk. No shared volumes or overlays. |
| Network isolation | VMs sit on an internal network with no direct access to other VMs or the database. |
| Process isolation | Processes in one VM cannot see or signal processes in another. |
Credential protection
Platform secrets
Database credentials, internal auth tokens, and service keys are held in the control plane. They never enter workspace VMs. The only credential a VM receives is its own workspace API key, which has scoped access to that workspace’s resources.AI provider keys
In managed mode, AI provider API keys (Anthropic, OpenAI, Google) are held by the AI proxy service. The proxy injects keys at request time — they never enter the VM. Your code calls the standard SDK endpoint, and the proxy transparently adds authentication. In BYOK mode, you provide your own keys via the AI config API. Keys are stored encrypted and injected into the VM’s environment at boot — they are not persisted to disk inside the VM.API keys
User API keys use therb_ prefix and grant full account access. Best practices:
- Store keys in environment variables or a secrets manager
- Never commit keys to version control
- Use the API to rotate keys regularly
- Use scoped workspace access when possible
App access control
Every app exposed from a workspace has a visibility setting:| Mode | Who can access | Use for |
|---|---|---|
| Private (default) | Only the workspace owner | Development, testing |
| Public | Anyone with the URL | Demos, public APIs, static sites |
| Privileged | Owner + specific email addresses | Team collaboration, internal tools |
SSH authentication
SSH access uses public key authentication exclusively. No password authentication is supported.- Register keys via the API or CLI (
rig ssh-key add) - Keys are synced to workspace VMs on start and on-demand via the sync endpoint
- The SSH gateway authenticates your key and routes to your workspace
Network model
- Workspace VMs are on an internal network — not directly accessible from the internet
- All inbound traffic flows through the API gateway, reverse proxy, or SSH gateway
- Outbound AI requests flow through the managed proxy (when enabled)
- VMs can make outbound HTTP requests to the public internet for package installation, git clones, etc.
Rate limiting
API requests are rate-limited per user to prevent abuse. Limits vary by endpoint class:| Endpoint class | Default limit |
|---|---|
| Authentication | 120 requests/min |
| Workspaces | 180 requests/min |
| Apps | 240 requests/min |
429 Too Many Requests. Retry with exponential backoff.
See Resource Limits for plan-level quotas.
Learn more
Architecture
How the two-zone model works
App Visibility
Control who can access your apps