An Isolated Environment for AI Agents That Need a Shell, a Browser, and a Filesystem
AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.
An Isolated Environment for AI Agents That Need a Shell, a Browser, and a Filesystem
CreateOS Sandbox gives every AI agent its own Firecracker microVM: a full machine with an interactive shell, a real filesystem, and headless Chromium for browser work. Isolation is the default, the egress rule is yours to set, and you can test it on your own workload with 500 free credits.
Introduction
An agent that writes code needs somewhere to run it. The job sounds small until you list what the code touches. A shell, to install dependencies and execute. A filesystem, to hold state between steps. Often a browser, to use the web the way a person would. Remove any one and the agent stalls, or improvises against infrastructure you did not mean to expose.
The default answer, a container on a shared host, leaks. Agent-written code is untrusted by definition. One injected command inside a shared-kernel container has options nobody approved. Our analysis of a real sandbox escape lands on the same conclusion: the boundary has to hold against a compromised guest, not a well-behaved one.
Key Takeaways
- One sandbox is one Firecracker microVM with its own guest kernel. Not a container on a shared host.
- The environment ships whole: interactive shell with SSH forwarding, a 10 to 60 GB disk with two-way file sync, and headless Chromium with a DevTools port.
- Outbound access is open until you set a rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
- Pause in about 1.4 seconds, resume on the same host in under 0.7, and fork a paused machine to branch agent state.
- Per-second billing, $0 egress, 500 free credits to prove it on your workload.
Why a MicroVM Fits This Job
Shell, browser, and filesystem are not three services to stitch together. They are three processes on one machine, and they share state. The browser downloads a file, the shell parses it, the agent rewrites it, the browser uploads the result. Split the three across separate vendors and you pay three bills, ship state across three boundaries, and debug a chain you do not own.
A sandbox collapses that stack into one guest. Own kernel, own disk, one network policy you govern. If the code inside turns hostile, the blast radius is the machine it is standing on. Isolation by default, not a setting someone has to remember.
Multi-agent systems need more than one machine. Attach sandboxes to a private overlay network with per-network private DNS, and a browser sandbox reaches the app sandbox by name with no public exposure. Traffic between networks is denied by default.
The state model matches how agents actually work, too. Pause while a human reviews, resume exactly where it stopped. Fork a paused machine into N candidate runs and keep the winner.
Key Capabilities
The shell. An interactive shell plus SSH forwarding, wired in through the SDK (@nodeops-createos/sandbox on npm), the CLI (createos sandbox), or MCP. The docs cover the quickstart and the full API.
The browser. Headless Chromium with a DevTools port on a public URL, plus a live web URL for anything the sandbox serves. A graphical desktop with screenshots and clipboard is there when the workflow needs eyes on the page.
The filesystem. A real disk from 10 to 60 GB with two-way file sync. Bring your own Dockerfile to shape the image, or start from the default templates: Ubuntu 26.04 with Node 22, Bun, Python 3.12, Go 1.26, and Rust 1.83.
The boundary. Egress rules take a host, host:port, wildcard subdomains, IPs and CIDRs. Set them in the egress field at create time, update them live through PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or createos sandbox firewall set. Enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot rewrite or route around it.
The size. Shapes run from a quarter CPU up to 8 CPUs and 16 GB of memory. Bring your own bucket (S3, R2, MinIO) for artifacts, and bring your own compute when the session has to stay on your machines.
Proof & Evidence
2.6 million sandboxes have been created since June 2026. CreateOS's own CI has run on sandboxes since July 2026. Uptime runs at 99%+. Underneath it, NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.
Say plainly what is young and what is proven. This is a young product with real traffic, published pricing you can audit, and a product page that carries the current limits. You can verify all of it before talking to a single person.
What to Check Before You Commit
- Egress is open until you set a rule. If your threat model needs deny-by-default, set at least one rule at create time. Inbound is closed regardless.
- Cross-host cold starts take 11 to 13 seconds. If your orchestrator reschedules sessions across hosts, plan for that window or keep a session pinned to one host.
- The first request after a pause waits for the resume, and auto-resume triggers on inbound HTTP only. Set the idle window to match the way your agents wait.
- No GPU sandboxes. If the workload needs one, this is not the tool.
- Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. The trust case here is the microVM boundary, the host-enforced egress, and the bring-your-own options.
Frequently Asked Questions
Is this a container or a virtual machine?
A virtual machine. Each sandbox is a Firecracker microVM with its own guest kernel. A container shares the host kernel with every other workload on the machine. A sandbox shares nothing.
How do I control where the sandbox can send data?
Outbound access is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Rules take hosts, ports, wildcard subdomains, IPs and CIDRs, set at create time or changed live through the API, SDK, or CLI. Inbound is closed by default.
What does a sandbox cost?
Per-second billing with $0 egress, and pausing stops the meter. Shapes run from a quarter CPU to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk. New accounts start with 500 free credits. Current rates are on the Sandbox pricing page.
Can it run on our own infrastructure?
Yes. Bring your own compute runs the same API on your machines. Bring your own bucket keeps artifacts on your S3, R2, or MinIO. Self-host the control plane and storage entirely when the code cannot leave your boundary.
Conclusion
The pattern fits in a design review. Every agent gets a machine. Every machine has a boundary. The boundary is enforced outside the guest, where the code cannot reach it. Shell, browser, filesystem: all of it inside the machine, all of it disposable.
Start free with 500 credits at createos.sh/products/sandbox and run your own workload before you decide anything.
About CreateOS
CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.