Executing code you did not write, without pretending it is safe
Isolation is not a feature you enable; it is a boundary with a specific shape, specific costs and specific gaps. This page states where the boundary is, what it stops, and what remains your problem.
Start from the threat, not the technology
"Untrusted code" covers several different threats and they do not have the same answer. Code that is
merely careless — a model-written script with an accidental infinite loop or a stray
rm -rf — needs containment of blast radius and a resource ceiling. Code that is
adversarial — a submission to a grading system, or a script an agent was manipulated into
writing through prompt injection — needs an isolation boundary that holds against someone actively
attacking it. Code that is merely confidential, where the risk is one tenant reading another's
data, needs single tenancy.
Most platforms solve the first and describe it as if it solved the second. The distinction that matters is what an attacker has to break, and how much code is on the other side of it.
Where the boundary sits
Language-level
An import allowlist, a stripped __builtins__, a restricted AST. Cheap, and appropriate for careless code from a trusted author. Not an adversarial boundary: the attack surface is the whole interpreter, and every mature attempt at this in Python and JavaScript has been escaped.
Container
Namespaces, cgroups and seccomp around a process. A real boundary, and the right one for many workloads. But the kernel is shared with every other workload on the host, so an unprivileged-reachable kernel bug is a cross-tenant event rather than a local one.
Virtual machine
Its own kernel, its own filesystem, its own network stack. An attacker who compromises the kernel has compromised a machine that will be destroyed shortly and that nobody else shares. This is what a sandbox here is.
The controls, specifically
- One VM per sandbox. Not a container on a shared kernel, and not a machine recycled from another account. Single-tenant for its whole life.
- Destroyed, not wiped. On
DELETEor on timeout expiry, the machine and its disk are destroyed. A reconciler continuously compares recorded state against what is actually running and removes anything unaccounted for, so a bug in our control plane does not leave your data on a forgotten machine. - Unprivileged execution. Commands run as a normal user with no sudo. Privilege escalation inside the sandbox requires a local kernel exploit, and succeeding at it only gets the attacker root on a machine that is already theirs alone.
- Metadata endpoint blocked. The cloud provider's instance metadata service is unreachable from inside the sandbox. This closes the standard escalation path against hosted execution environments, where reading metadata yields infrastructure credentials.
- Outbound SMTP blocked. Mail ports are closed. This is an abuse control rather than a security control for you, but it is the difference between a sandbox platform and an open relay.
- Bounded lifetime. Every sandbox has a timeout, at most 24 hours. There is no such thing as a sandbox that quietly stays alive.
What is still yours to handle
Outbound network access. It is on, because installing a package or calling an API is what almost every sandbox is for. It also means exfiltration is possible by design. If your data must not leave, do not put it in the sandbox — fetch it under your control, pass only what the job needs, and treat the sandbox as a place data goes to, not a place data is protected in.
Credential scope. The isolation boundary does not care how powerful the token you passed in
is. Use per-task, short-lived, minimally scoped credentials; pass them in the env of the
specific exec call that needs them rather than at sandbox creation, so their exposure window
is one command.
Output handling. Command output is attacker-controlled text. If you render it in a web UI, escape it; if you feed it to a model, remember that it can contain instructions. A sandbox that contains the execution does nothing about a prompt injection carried out through the results.
Spend. Prepaid credit caps the financial damage of a runaway loop, and the concurrency
limit of 20 sandboxes caps how fast it can accumulate, but the ceiling is still your balance.
Watch GET /v1/usage if you are running an unattended agent.
What we do not claim
No certifications, no audited attestations, no uptime guarantee. The design is described above and on the security page so you can judge it directly; measured operational behaviour is in limits. We would rather be checkable than impressive.
Questions
Is a VM really safer than a container for untrusted code?
For this threat model, yes, and the reason is narrow rather than ideological. A container is a set of kernel features — namespaces, cgroups, seccomp — applied to a process that still calls into the same kernel as every other workload on the host. A kernel vulnerability reachable from an unprivileged syscall is therefore a cross-tenant problem. A virtual machine runs its own kernel, so the same bug is contained and the attacker's next step is a hypervisor escape, a much smaller and much more scrutinised interface.
Are you SOC 2 certified?
No. We hold no certifications and we are not going to imply otherwise. What we can describe is the technical design — single-tenant VMs, unprivileged execution, no machine reuse across accounts, destruction on expiry — and you can evaluate that on its merits. If your procurement process requires an audited attestation, this service does not currently meet it.
Can code in a sandbox reach the internet?
Yes, by default, because almost every real workload needs it — pip, npm, git clone, API calls. That is a deliberate trade and it is the single most important thing to understand about the threat model: outbound network access means anything inside the sandbox can leave the sandbox. Two specific paths are closed: the cloud metadata endpoint is blocked, and outbound SMTP is blocked.
Can one sandbox see another?
No. Each sandbox is a separate virtual machine with its own kernel, filesystem and network stack, and machines are never reused between accounts. When a sandbox is destroyed, the underlying machine is destroyed rather than wiped and re-leased.
What do you log about what I run?
The commands you submit through the API, plus sandbox metadata: id, size, timestamps, exit codes and durations. That is what makes usage history and billing possible. The contents of the sandbox filesystem are not collected. Details are in the privacy policy.
What is the worst case if a sandbox is fully compromised?
The attacker has an unprivileged shell on a throwaway Linux machine with internet access, for at most the remaining lifetime of that sandbox. They can see whatever you put in it — your code, your data, any credentials in the environment — and they can send it somewhere. They cannot reach your other sandboxes, other customers, or our control plane. Sizing your exposure means asking what you handed to the sandbox, not what the sandbox is.
Put the boundary where it belongs
A dedicated VM per sandbox, destroyed when the work is done. Start with $${SIGNUP_BONUS} of credit and no card.