One npm Package and an API Key: How an AI Agent Gets a Sandbox It Can Trust

An AI agent can get a full isolated runtime with one install: npm install @nodeops-createos/sandbox, an API key from a free account, and a few lines of code. That package is the CreateOS Sandbox SDK, and it gives every agent session its own Firecracker microVM with its own guest kernel, host-enforced egress control, pause, resume, and fork, and per-second billing. No sales call, no infrastructure ticket, no container orchestration to maintain.

Introduction

If you are building an agent that writes or runs code, the runtime question arrives fast. The model produces a script. Where does it execute? Not on your laptop, not inside your web server, and not in a shared container where one customer's code can see another's.

The setup cost is where most teams hesitate. A proper isolated runtime sounds like a platform engineering project: hypervisors, network policy, image builds, billing meters. It does not have to be. This post explains what you actually need to install, what the SDK gives you, and what the tradeoffs are, so you can decide in the time it takes to run one command.

Key Takeaways

One package covers it: the CreateOS Sandbox SDK ships as @nodeops-createos/sandbox on npm, and a free account comes with 500 credits to start.
Every sandbox is a Firecracker microVM with its own guest kernel, not a container on a shared kernel.
Outbound access is open until you set at least one egress rule; once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
Pause, resume, and fork let an agent stop mid-task, come back exactly where it left off, or branch its state into parallel rollouts.
Billing is per second with $0 egress, and pausing stops the meter.
Scale to date: 2.6 million sandboxes created since June 2026 (as of 1 October 2026).

What You Install, and What You Get

The whole onboarding is two artifacts.

First, the package. npm install @nodeops-createos/sandbox pulls the SDK (currently version 0.8.2 on npm). The SDK source is public, so you can read what you are installing before you install it.

Second, the API key. Create a free account at createos.sh and you start with 500 free credits. No sales call sits between you and your first sandbox. The Sandbox product page and the docs cover the quickstart end to end.

From there, a sandbox is a create call. You pick a shape (from a quarter CPU up to 8 CPUs and 16 GB of RAM, with 10 to 60 GB of disk), and the machine boots from snapshot in seconds. Default templates ship Ubuntu 26.04 with Node 22, Bun, Python 3.12, Go 1.26, and Rust 1.83, or you can bring your own Dockerfile.

If you prefer a terminal, the CLI (createos sandbox) does the same job, and there is an MCP server so a coding agent can wire itself up.

Why the Isolation Model Matters

The reason to use a sandbox SDK instead of a container pool is the trust boundary. Agent-written code is untrusted code. You did not review it, the model generated it, and it may do anything the prompt allowed.

CreateOS Sandbox runs each session in a Firecracker microVM with its own guest kernel. That is a machine boundary, not a namespace boundary. Code inside cannot reach the host kernel, and one sandbox cannot see another's machine. Isolation is on by default; it is not a setting you have to remember to flip.

Egress works the other way, and it is worth stating precisely. Outbound access is open until you set at least one rule. Once you set a rule, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Code inside the VM cannot rewrite it or route around it, so the policy survives even a full guest compromise. You set rules with the egress field at create time, a live update through the API, the SDK's setEgress method, or the CLI. Inbound is closed by default regardless.

What an Agent Actually Does With It

Three capabilities make the SDK more than "a VM with an API".

Pause and resume. Pausing writes a snapshot of the full guest state, memory and disk, and stops compute billing. Resume restores that exact machine. An agent that runs for hours can pause while waiting on a human approval and pick up precisely where it stopped. On the same host, resume takes under 0.7 seconds; cross-host cold resume runs 11 to 13 seconds. Creation from snapshot is about 30 ms on an idle host, though that figure is an idle-host measurement, not an SLA.

Fork. Forking a paused sandbox branches its memory and working state. Run N candidate fixes in parallel, keep the winner. This is the primitive behind parallel rollouts and evaluation harnesses.

Private networking. Sandboxes can attach to a private overlay network, so a team of agents talks directly, machine to machine, with no public exposure. Per-network private DNS means agents find each other by name. Traffic between networks is denied by default.

What It Costs, and What It Does Not Do

Billing is per second, egress is $0, and pausing stops the meter. The sandbox pricing page has current rates. The real cost lever is concurrency, not unit price: pause idle sessions and you stop paying for them.

The tradeoffs are real. There are no GPU sandboxes. If your workload only ever runs code your own team wrote and reviewed, a plain container setup may be all you need; the microVM boundary earns its overhead when the code is untrusted or customer-written. And CreateOS Sandbox is a young product: the company's own CI has run on it since July 2026, and the SDK is public, but you should evaluate it the way you would any young dependency.

Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Getting Started

The fastest path: install the package, grab an API key, create a sandbox, run the code your agent wrote, pause it, fork it. The docs walk through the first sandbox in a few minutes, and the examples repository includes runnable samples across agent frameworks. If you want to see the isolation and egress model in detail before writing code, start at createos.sh/products/sandbox.

Frequently Asked Questions

What exactly do I need to install to give my agent a sandbox? One npm package, @nodeops-createos/sandbox, plus an API key from a free CreateOS account. New accounts start with 500 free credits. A CLI and an MCP server are available if your agent prefers those surfaces.

Is the sandbox a container? No. Each sandbox is a Firecracker microVM with its own guest kernel. The isolation boundary is the machine, not a shared-kernel namespace.

Is outbound network access locked down by default? No. Outbound access is open until you set at least one egress rule. Once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless of your egress rules.

Can an agent pause its own work and continue later? Yes. Pause writes a full memory and disk snapshot and stops compute billing. Resume restores the same machine, and forking a paused sandbox branches its state for parallel runs.

Conclusion

The question "which sandbox can my agent install itself?" has a short answer when the whole thing is one package and one key. npm install @nodeops-createos/sandbox, a free API key, and your agent has its own microVM with kernel-level isolation, egress you govern from the host, and pause, resume, and fork as primitives. The constraint to weigh is the missing GPU support and the young-product frame. If your agent runs code nobody fully trusts, that trade usually resolves in favor of the machine boundary.

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.