Security & isolation

Sandboxes exist to run code you do not trust - model-generated programs, third-party submissions, agent tool calls. This page describes the isolation model and what happens to your data at each point of the lifecycle, so you can judge what to run in a sandbox and what to keep out of one.

Isolation model

• Every sandbox is its own virtual machine with its own kernel, not a container sharing a host kernel. There is no shared container runtime and no syscall surface between tenants.
• Own filesystem: a writable overlay on a read-only base image. Base images are built and verified by CI, never hand-modified.
• Own network stack, or none: the default network mode is off - the VM has no network device at all. Networked modes get an isolated per-sandbox stack.
• Hard resource ceilings: CPU and memory are fixed at the size you choose; a runaway workload exhausts its own VM, not its neighbors.

Network controls

Egress is opt-in, in three steps. off (default) has no interface. restricted routes HTTPS through a forward proxy that only resolves an allowlist - the curated default set (package registries, GitHub, major model APIs) or your own list - with no raw sockets and no direct DNS. open is unrestricted and is a deliberate choice, never a default. Details in Networking & egress.

Data lifecycle

• While running: your files live in the VM's memory (/workspace, /tmp) and, if attached, on a volume disk local to the host. Env vars you pass exist only in the VM's memory and are never written to our databases or logs.
• On terminate: the VM and its memory are destroyed. Nothing under /workspace survives; volume data under /persist does.
• On pause: the VM's memory and disk state are captured into a snapshot stored on the host, reclaimed automatically after the tier's retention window (limits). A snapshot contains everything that was in the sandbox - including any secrets in memory - so treat a paused sandbox with the same care as a running one.
• Volumes: live data is a disk on the sandbox host; durable checkpoints go to EU object storage. Deleting a volume deletes its data and checkpoints.
• Activity records: we keep an audit timeline of lifecycle operations and command invocations for your console; this is operational metadata, not a copy of your files.

Credentials

• Scoped tokens: mint tokens with only sandboxes:read / sandboxes:write for agent runtimes. A leaked sandbox token cannot touch projects, deployments, or billing.
• Secrets you inject (as env vars or files) are visible to whatever code runs in that sandbox - including code a model wrote. Inject revocable, least-privilege credentials, and remember they persist inside pause snapshots until the sandbox is terminated or reaped.

Preview URLs

A preview URL's only capability is the unguessable sandbox id in its hostname: no auth header, public to anyone holding the link, serving only while the sandbox runs. Treat it like a secret link and don't put sensitive admin surfaces behind one. See Networking & egress.

Blast-radius separation

The sandbox runtime has its own MCP server and token scopes, separate from the platform's. An agent credentialed only for sandboxes can spend your sandbox budget at worst - it cannot reach your deployed applications, databases, or account settings.