Every sandbox vendor publishes a cold start number. Almost none publish what a compromise reaches. Those two numbers move against each other, because the only way to start in tens of milliseconds is to share a kernel with somebody else. We are introducing Trickest Sandboxes, and we took the slow end of that trade on purpose. Every sandbox in our managed fleet gets its own EC2 instance. A container escape finds no second Trickest sandbox on that guest OS to inherit.
Key takeaways
- Cold start and blast radius are the same dial. Sub-100ms numbers come from shared kernels.
- A sandbox runs untrusted code by design. That makes it infrastructure, and infrastructure gets designed for its worst case.
- One sandbox per EC2 instance, never shared and never reused by another sandbox. Instances leave the fleet by termination.
- Prepared capacity absorbs most of the latency cost, so we pay for the choice rather than the caller.
- We do not claim an agent cannot escape. We claim there is nothing next door to take.
The Benchmark Everybody Optimizes
Look at how this category sells itself and you find one number in every comparison: how fast a sandbox starts.
The numbers are real, and the ordering is not an accident.
| Isolation | Typical cold start | What the workload gets |
|---|---|---|
| Shared-kernel container | tens of milliseconds | namespaces on somebody else's kernel |
| gVisor | around 100 milliseconds | intercepted syscalls, still a shared host |
| Firecracker microVM | 150 to 500 milliseconds | its own kernel, host still shared |
| Its own instance | seconds | its own guest OS |
Container platforms hit sub-90 millisecond starts because a container only has to set up namespaces and mount a filesystem. Firecracker sits at 150 milliseconds and up because it boots a kernel first. The slower option is slower because it is doing more separation.
So the leaderboard is upside down. The fastest sandbox on the list is the one where the most is shared, and a benchmark that rewards speed rewards sharing.
A Sandbox Is Infrastructure, Not a Feature
The reason this matters more here than in most product decisions is what a sandbox is for.
An agent sandbox exists to run code nobody reviewed. That is the entire job. Every other component in a platform can assume its input is roughly what the last release expected. This one assumes the opposite.
You tune a feature for the median case. You design infrastructure for the worst one. Cold start is a median-case metric, and it is the wrong thing to optimize in the one component whose failure mode is somebody else's code taking the machine.
Three incidents from this year make the point better than an argument does.
In Trail of Bits' VM escape research, a cyber-capable agent chained vulnerabilities in QEMU, KVM, and networking code to escape a developer's Linux VM. Patching did not end it, because the agent kept finding previously unknown bugs. Against Firecracker it caused host crashes without achieving an escape.
During OpenAI's cybersecurity evaluations, agents turned a shared infrastructure service into a way to talk to each other and reach the internet. The incident spread into research infrastructure and Hugging Face systems, and neither organization recognized it as machine-driven for nearly a week.
In a separate Claude Cowork demonstration, researchers took root inside a local Linux VM on macOS and reached Mac files through a writable shared mount. They never touched the hypervisor. Their report says the local path did not appear to apply to Cowork's cloud execution.
None of these was a hostile operator. Each was a capable process pursuing an objective through whatever it could reach. That is the failure mode a sandbox has to be designed against, and it is not measured in milliseconds.
A Container Escape Should Not Inherit Another Sandbox
Our managed fleet runs one sandbox container per EC2 instance. The guest kernel and the container daemon belong to that sandbox's environment. We do not pack another Trickest sandbox alongside it.
If code escapes its container and takes the guest OS, there is no other Trickest sandbox on that OS to inherit. Another instance's memory and virtual disk sit beyond the EC2 hypervisor's isolation boundary. EC2 instances can share physical hardware, so taking a guest does not by itself cross that boundary.
We remove the shared guest OS between sandboxes by design. Credentials, network reach, and control-plane services remain separate security responsibilities. The incidents above are what happens when those connections matter even while a VM boundary holds.
We are not claiming an agent cannot escape. A guest compromise must not hand it another sandbox on the same OS. Protecting the wider platform is a different problem, and owning an instance does not make its integrations safe.
A Kubernetes Namespace Is Not Enough
Ordinary Linux pods on a shared Kubernetes worker still share that worker's kernel. A namespace, a set of API permissions, and a network policy do not turn each pod into a separate machine. Kubernetes' own guidance recommends additional sandboxing for untrusted code.
That is why we do not use ordinary pods on shared workers as the isolation boundary for managed sandboxes. Kubernetes can orchestrate VM-backed runtimes, and in that shape the runtime provides the protection rather than the label. A Kubernetes label on its own tells you very little about what happens after a compromise.
We Pay for the Slow Choice, Not You
A separate machine only helps if allocation, resume, and disposal respect the same ownership rule.
A sandbox keeps its own instance through the work, including stop and resume while that instance remains available. Disposal retires its execution environment. We do not hand that guest OS to another sandbox.
The latency is real, and we absorb most of it with prepared capacity. Instances are launched ahead of demand and held blank and unassigned. When a sandbox starts it can take one of those rather than waiting for a cold launch. Once assigned, an instance belongs to that sandbox until it is terminated. "Its own instance" means never shared and never reused, rather than always built from scratch.
That is where the cost of this design actually lands. Running spare capacity so the boundary stays strict is an expense we carry, and it is a better place to put it than in the boundary.
Configuration deserves the same scrutiny. In Claude Code's Linux sandbox vulnerability, malicious code could plant settings that later executed hooks with host privileges. Anthropic fixed it in version 2.1.2. An integration that promotes sandbox-written configuration into trusted execution undermines its own boundary. Network controls restrict access to protected infrastructure, and platform requests require authentication and follow the caller's vault access.
Give the Agent Room to Finish the Job
An agent needs to do more than suggest the next step. It needs to write a script, run it, read the output, and revise. Keeping its files and tools in one environment lets each step build on the last.
One environment for the whole task. Trickest Sandboxes provide a Linux shell with Node and Python. The agent installs the tools a task needs and keeps working in the same place. Related tasks can share a sandbox when they belong to the same job.
Work that outlives the connection. A build or analysis runs detached while the sandbox stays up. You can follow its logs, wait for the result, or stop it.
Files that survive a pause. A persistent sandbox retains files through stop and resume. Stopping the machine does not preserve running processes. Copy anything you need past disposal into external storage.
The agent can turn its work into an app or a report and serve it through an app preview URL. You use what it built, check the output, and decide what changes.
Build with the Sandbox SDK
Use @trickest/sandbox to create and control the environment from TypeScript. The SDK uses native fetch, has zero runtime dependencies, and requires Node 22 or newer.
npm install @trickest/sandboxPass your Trickest token, create a sandbox, write files, run commands, and collect results. Delete the sandbox when the job is done. The Sandbox SDK quickstart documents that loop. The platform SDK's sandbox service is a separate API for workflow-linked sessions.
The Number Worth Publishing
Cold start is easy to measure, which is most of why the category competes on it. Blast radius is harder to measure and matters more, so it goes unstated.
We took the slow side of that trade because a sandbox is the one component built to run code nobody vetted. Every managed sandbox gets its own instance, and we keep other Trickest sandboxes off its guest OS.