The blast radius is a disposable box.
An agent needs to run commands, install packages, start your app and click around it. The only responsible way to allow that is to give it an environment that is worth nothing — one run’s copy of one repository, thrown away afterwards, reaching only what you allow.
What exists, and for how long
Four properties, in the order they matter to a security review.
Provisioned per run
A run gets its own environment. It is not a shared worker with a workspace directory per customer — the boundary is the environment itself, and it belongs to one run.
The repository arrives as a copy
The agent works against a clone at a known base commit. Your default branch is never the working copy; output leaves as a branch and a pull request.
It runs as an unprivileged user
Processes inside the box are not root, and the runtime image is ours rather than whatever the agent decides to install.
It is disposable
The environment is torn down after the run. Where a session is resumed on purpose, it is paused instead — pausing preserves the filesystem so a resumed session continues rather than restarting.
What holds, and where it is enforced
Including the three that are partial. A security page that only lists the finished controls is a marketing page.
| What holds | How it is enforced | Where |
|---|---|---|
| One environment per run | The run provisions its own sandbox and holds the only handle to it. Nothing is shared between two runs at the same time. | sandbox provider |
| Three interchangeable backends | A single provider interface with three implementations: a hosted sandbox service (the default), Kubernetes pods for a cluster you control, and a microVM service. The runtime does not care which one it is talking to, which is what makes "run it in our own cluster" a configuration rather than a rewrite. | provider interface |
| Secrets arrive at egress, not at rest | Vault values are decrypted only when injected into a run, their use is audited, and matches are redacted out of the run’s output. | vault |
| Preview access is signedpartial | When the preview proxy is configured, the claim is carried in the hostname and verified before a single byte is forwarded — a preview URL only works if it was minted for someone whose session and organization were checked. Without the proxy configured, previews fall back to unguessable provider URLs, which is obscurity rather than authentication. | preview proxy |
| Network egress is controllablepartial | Egress can be locked to an allowlist of hosts per project. The default today is open, because a coding agent that cannot reach a package registry cannot build anything — so this is a decision to make per project rather than a promise we can make for you. | sandbox egress policy |
| Warm reuse is opt-out, not invisiblepartial | After a green run we can snapshot the environment’s disk so the next run resumes fast instead of reinstalling the world. That means build caches and dependencies carry across runs of the same repository, inside your organization. It is on by default and can be turned off per deployment. | warm snapshots |
Read this before you point it at anything
- The default egress policy is open. Locking it down is per project and worth doing before you point an agent at anything sensitive.
- Warm snapshots mean environment state persists between runs of the same repository. That is a performance feature with a real trade-off, and we would rather you decide it deliberately.
- Preview URLs are only cryptographically protected when the preview proxy is configured for the deployment. Ask us which mode you are on.
- The sandbox bounds what an agent can reach; it does not make an agent correct. That is what the verification gate is for.