Test AI Agent Code in a Free Sandbox Before It Touches Your Repo

An agent-written change should prove itself on a disposable machine before you merge it. A free-tier sandbox gives you exactly that: a Firecracker microVM where untrusted or agent-written code runs in isolation, at no cost while you evaluate. CreateOS Sandbox includes 500 free credits for new accounts, enough to run real agent sessions, not just a hello world, before you commit to anything.

Introduction

AI coding agents write code fast. They also write code you did not review, running with whatever access you gave them. The failure mode is familiar: an agent edits files, installs packages, or calls a network endpoint, and you find out what it did after it already happened on your machine.

The fix is a staging layer between the agent and everything you care about. Run the agent's code on a machine that exists only for that session, with network access you control, then throw it away. If the code misbehaves, the blast radius is one disposable VM.

This piece explains how a free-tier sandbox fits that workflow: what it isolates, what it costs, how egress control actually works, and where the free tier ends. The examples use CreateOS Sandbox, but the pattern applies to any agent workflow that executes generated code.

Key Takeaways

A sandbox gives agent-written code its own machine per session, so a bad change costs you a VM, not your repo or your laptop.
Isolation is on by default. Outbound network 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 you branch an agent's working state and try N candidate fixes in parallel, keeping the one that passes.
New accounts start with 500 free credits, with per-second billing and $0 egress after that, so the free tier is a real evaluation, not a demo mode.
2.6 million sandboxes created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026.

What a Sandbox Actually Isolates

Every CreateOS Sandbox is a Firecracker microVM with its own guest kernel. It is not a container and not a shared-kernel process namespace. The isolation boundary is the machine itself.

That distinction matters for agent code specifically. A container shares the host kernel, so a kernel-level escape or a clever syscall path is a shared risk. A microVM boots a kernel per session. Code inside the sandbox sees its own machine, its own filesystem, and nothing else. When the session ends, the machine is gone.

For a pre-commit workflow, this means the agent can install dependencies, run build scripts, execute test suites, and mutate files freely. Worst case, you delete the sandbox. Your working tree, your credentials, and your host are untouched.

How Egress Control Works (and What the Default Actually Is)

This is the part most teams get wrong, so it is worth being precise.

Isolation is on by default. Egress restriction is not. A sandbox with no egress rules set has open outbound access. If your agent needs to pip install or clone a repo on first run, that works out of the box.

Deny-by-default starts once you set at least one rule. From that point, everything not on the allowlist is denied. You can set the allowlist four ways: the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>.

Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Enforcement sits in the host kernel with eBPF, outside the VM. Code inside the sandbox cannot rewrite the rules or route around them, so the policy survives even a full guest compromise. Inbound is closed by default regardless of what you set on egress.

For a pre-commit workflow, a practical pattern: leave egress open while the agent installs dependencies, then set an allowlist covering only your package registry and test endpoints before the agent runs anything with network reach.

Fork the Agent's State Instead of Re-Running It

The expensive part of testing agent output is usually not the run itself. It is re-running the whole session when a candidate fix fails.

CreateOS Sandbox supports pause, resume, and fork. Pausing writes a Firecracker snapshot of the full guest state, memory and disk, and stops compute billing. Resuming restores that exact machine. Forking a paused sandbox branches its memory and working state, so you can take one agent session that hit a failing test and spin up N parallel attempts at the fix, each on its own machine, then keep the winner.

Timing, with the qualifiers that matter: sandbox creation is a restore from snapshot, tens of milliseconds, about 30 ms on an idle host (an idle-host figure, not an SLA). Pause takes about 1.4 seconds. Same-host resume comes in under 0.7 seconds. Cross-host cold resume runs 11 to 13 seconds.

What the Free Tier Covers

New accounts start with 500 free credits. That is enough to run real agent sessions end to end: create a sandbox, run the agent's code, set an egress rule, pause and fork, and measure the timings yourself.

After the credits, pricing is per-second billing with $0 egress, and pausing stops the meter. Shapes run from a quarter CPU up to 8 CPUs with 16 GB of RAM, and 10 to 60 GB of disk. You can also bring your own storage (S3, R2, MinIO) or bring your own compute, running the same API on your own machines if code cannot leave your boundary.

Scale context, dated as required: 2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026, and NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023. The product is young, and it is fine to evaluate it with that frame: the CI that runs on it daily is the usable proof.

A Pre-Commit Workflow in Practice

The pattern fits in ten minutes:

Create a sandbox from the SDK or CLI (npm install @nodeops-createos/sandbox, or the createos CLI).
Let the agent apply its change and install dependencies inside the sandbox, not on your machine.
Set an egress allowlist covering only what the test run needs.
Run the test suite. If it fails, pause the sandbox, fork it, and try candidate fixes in parallel.
Merge only after a run passes. Destroy the sandbox either way.

The full API and quickstart live in the CreateOS docs.

Frequently Asked Questions

Is the free tier limited to toy workloads? No. New accounts get 500 free credits, and sandboxes scale from a quarter CPU to 8 CPUs and 16 GB of RAM. You can run a full agent session, including dependency installs and test suites, on the free tier.

Is outbound network access blocked by default? No, and this is a common misconception. Isolation is on by default; egress restriction is not. Outbound access is open until you set at least one rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest. Inbound is closed by default either way.

What happens if the agent's code is malicious? It runs on a disposable Firecracker microVM with its own guest kernel. With an egress allowlist set, it cannot reach hosts outside the list, and the enforcement sits outside the VM where the code cannot touch it. When the session ends, the machine is destroyed.

Can I run this on my own infrastructure? Yes. CreateOS Sandbox supports bring-your-own compute, the same API on your own machines, and bring-your-own storage with S3, R2, or MinIO. You can self-host the control plane and storage entirely if code cannot leave your boundary.

Try It Before You Commit

The free tier exists so you can test this against your own agent workflow, not a demo. Start with 500 free credits on CreateOS Sandbox, check sandbox pricing for what comes after, and run your first agent session on a machine you can afford to lose.

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.