Security and isolation

How is each sandbox isolated?

Each sandbox is a separate virtual machine with no shared kernel. Sandboxer's security docs describe four layers:

• One VM per sandbox. Every sandbox is its own Cloud Hypervisor microVM with its own kernel.
• No control channel on the network. The agent inside the VM talks to the host over vsock, not TCP, so nothing on the sandbox's network, even code running as root, can reach the host's control API.
• Separate disks. Each root disk is its own copy-on-write image. Forks and snapshots are reflinks, never shared writable state.
• Fresh identity on fork. Forks get a new machine-id, SSH host keys and hostname, so copies cannot impersonate each other.

Why a VM rather than a container is explained in microVMs vs containers.

What network traffic is allowed?

Outbound internet access is open, and nearly every other path is blocked or gated. The network policy from the docs:

Bandwidth is shaped per VM so one sandbox cannot starve its neighbors. Sandboxer has no egress allowlist of its own; its network guide suggests restricting outbound traffic yourself with ufw inside the VM.

How are secrets handled?

Secrets only go into a sandbox when you choose to send them. Environment variables and secret files are written in only when the sandbox's environment passes them.

• noEnv sandboxes, and environments marked safe for third parties, get none of your secrets or credentials
• Removing a secret from an environment and upgrading deletes it from the sandboxes' disks, rather than hiding it
• Share codes for named snapshots strip your logins, keys, secret files, repository credentials and SSH keys from the copy

sbx new --no-env -e ONLY_THIS_KEY=value

How do API keys and tokens limit damage?

Keys can be scoped so that a leaked one does little harm. API keys are stored as SHA-256 hashes and shown once. You can limit a key to certain actions, sandboxes and environments, and give it an expiry.

sbx api-key create one-sandbox --sandbox <sandbox-id> --actions sandbox.read,exec,file.read --ttl 7d

Inside every sandbox, SANDBOXER_TOKEN can only act on that sandbox. Hosted-port tokens and desktop URLs are redacted from Sandboxer's logs, and webhook deliveries are signed with HMAC-SHA256 and timestamped.

What data does Sandboxer keep?

Stopped sandboxes keep their disks until you delete them. You can reduce what is kept:

• Zero data retention, an account setting, deletes the data of every archived sandbox and named snapshot instead of keeping it
• Snapshots off and monitoring off stop disk snapshots, command output, process lists and metrics from being kept
• Closing an account archives sandboxes and revokes every API key, with a 30-day window to reopen, or an immediate permanent erase

The docs note that copies in backups and long-term storage may remain for a time after deletion.

How do you report a vulnerability?

Email [email protected] with a description, steps to reproduce and the impact. Sandboxer commits to acknowledge reports within 3 business days, treats sandbox escape and cross-tenant access as top priority, and offers a good-faith safe harbor for research that stays in scope.