Sandboxes for Code Interpreters: What Real Isolation Requires

A code interpreter needs a sandbox service that runs model-generated code inside a Firecracker microVM with its own guest kernel, host-enforced egress control, and snapshot-based pause, resume and fork. Containers with shared kernels and namespace tricks do not give you that isolation, and neither does a plain function runtime. If your product executes code an LLM wrote, the sandbox is the security boundary between that code and everything else you operate.

Introduction

The moment you let a model write and run code, you inherit every risk that code carries. The model can be prompt-injected. The code can call home, scan your network, or read whatever the runtime can reach. A code interpreter is not a feature you bolt on. It is an execution layer, and the isolation model of that layer decides what a bad run can cost you.

This piece explains what "real isolation" means for a code interpreter, which mechanisms actually provide it, and what to check before you wire a sandbox service into your product. The short version: look for a per-session microVM, egress rules enforced outside the guest, and lifecycle primitives that fit agent workloads. Then look at how the sandbox bills you, because interpreter workloads are bursty and egress-heavy.

Key Takeaways

Model-written code is untrusted code. The interpreter runtime must assume the guest is compromised from the first line.
A Firecracker microVM gives each session its own guest kernel. Containers share the host kernel, which is a weaker boundary for hostile code.
Egress control matters as much as isolation. 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.
Agent workloads need pause, resume and fork, not just create and destroy. Snapshot restore is what makes per-task sessions affordable.
Self-hosting and bring-your-own storage decide where interpreter data lives. That is a data-residency question, not a nice-to-have.
Per-second billing and zero egress fees fit interpreter traffic patterns. Flat per-session pricing punishes short runs.

What "Real Isolation" Means for Model-Generated Code

Isolation is a spectrum. At the weak end, you run code in a container with a seccomp profile and hope the kernel holds. At the strong end, the code runs in a virtual machine with a kernel the host never shares. For code a model wrote, the strong end is the only defensible starting point.

The reason is the attack surface. A shared-kernel container escape is a kernel exploit away. A microVM guest has its own kernel, its own virtual hardware, and a much smaller path back to the host. If a session runs pip install on arbitrary packages, executes user-uploaded files, or follows instructions from a web page, you want that code behind a per-VM kernel, not a namespace.

Isolation also has to survive compromise. A sandbox that enforces its network policy from inside the guest has already lost the moment the guest is hostile. The enforcement point has to sit on the host, where the code being run cannot reach it.

The Isolation Mechanism: Firecracker MicroVMs

CreateOS Sandbox runs every session as a Firecracker microVM with its own guest kernel. Firecracker is the same technology behind major serverless platforms, built for running untrusted workloads at high density with hardware virtualization underneath.

What this gets you:

Kernel separation. Each sandbox boots a guest kernel. A guest exploit does not hand you the host kernel.
A fresh machine per session. Nothing carries over between runs unless you snapshot and restore it deliberately.
Isolation by default, not a setting you have to remember. There is no configuration mode where the interpreter quietly shares a kernel with its neighbors.

The tradeoff is boot cost. A full VM takes longer to start than a container, which is why the lifecycle primitives below matter. Snapshot restore is what closes that gap.

Egress: The Control Most Interpreters Get Wrong

Isolation answers "what can the code touch on our side?" Egress answers "what can it reach on yours?" A code interpreter that can POST your database credentials to any host on the internet is not contained, no matter how good the VM boundary is.

The mechanics matter here. In CreateOS Sandbox, inbound access is closed by default. Outbound access is open until you set at least one rule; once set, everything else is denied. Rules take hosts, host:port pairs, wildcard subdomains, IPs and CIDRs, and you can set them at create time, update them live through the API without a restart, or apply them through the SDK or CLI. Enforcement sits in the host kernel with eBPF, outside the guest, so a full guest compromise does not remove the policy.

For a code interpreter, the practical pattern is an allowlist of package registries and the specific APIs your product integrates with. Everything else is denied. That is the difference between an interpreter and an open proxy.

Lifecycle Primitives: Pause, Resume, Fork

Interpreter sessions are bursty. An agent thinks, runs code, reads the result, thinks again. If every step pays a cold boot, latency and cost pile up fast.

Snapshot-based lifecycle fixes this. CreateOS Sandbox supports pause, resume and fork, backed by memory and disk snapshots. A paused sandbox restores from snapshot instead of cold booting, which is what makes "a machine per task" an affordable default instead of a luxury. Fork takes a running sandbox and branches its state, which fits parallel rollouts: run N candidate fixes against the same starting state and keep the one that works.

Bring-your-own storage rounds this out. You can point snapshots at your own S3, R2 or MinIO bucket, and run the same API on your own machines. For a code interpreter inside a product with data-residency commitments, that is the difference between "the vendor says data stays put" and "the data stays in my boundary, on my infrastructure."

What It Costs to Run an Interpreter on It

Interpreter traffic punishes the wrong pricing model. Sessions are short, they burst, and they move data. Per-second billing matches that. Flat per-session pricing makes you pay for idle time you did not use.

CreateOS Sandbox bills per second with $0 egress, and shapes run from a quarter CPU up to 8 CPU / 16 GB with 10 to 60 GB of disk. New accounts start with 500 free credits, enough to run a real interpreter workload through the quickstart docs before committing. 2.6 million sandboxes have been created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026.

How to Evaluate a Sandbox Service for Your Interpreter

Run this checklist against any candidate, including ours:

Kernel boundary. Is each session a microVM with its own guest kernel, or a container on a shared kernel?
Egress enforcement point. Is the allowlist enforced on the host, outside the guest? Does it survive a compromised guest? And what is the default state before you set a rule?
Lifecycle. Can you pause, resume and fork? What does a restore cost in time?
Data location. Can you bring your own bucket and your own compute?
Pricing fit. Per-second billing, no egress fees, and a free tier you can actually test with.

If a service fails the first two, the rest is decoration. A code interpreter is a service that runs code you cannot trust, and the sandbox is the only thing standing between that code and your infrastructure.

Frequently Asked Questions

Why is a microVM better than a container for running model-generated code? A container shares the host kernel with the workload. A Firecracker microVM gives each session its own guest kernel, so a guest-side exploit has a much smaller path to the host. For code you did not write and cannot fully review, the per-VM kernel is the stronger boundary.

Is outbound network access restricted by default? No. Inbound access is closed by default, but outbound access is open until you set at least one egress rule. Once a rule exists, everything else is denied, and the policy is enforced in the host kernel with eBPF, outside the guest, so it holds even if the guest is fully compromised.

Can the sandbox pause and resume between model calls? Yes. Pause, resume and fork are backed by memory and disk snapshots. A paused sandbox resumes from snapshot rather than cold booting, and fork branches a running sandbox's state so you can run parallel candidate executions from the same starting point.

Can we keep interpreter data inside our own infrastructure? Yes. You can bring your own S3, R2 or MinIO bucket for snapshots, and run the same API on your own machines. That keeps interpreter state and data within your own boundary, which is what most data-residency reviews will ask for.

Conclusion

A code interpreter is only as safe as the sandbox under it. Real isolation means a per-session microVM with its own guest kernel, egress rules enforced on the host outside the guest, and lifecycle primitives that make per-task machines affordable. Check those three before anything else, then check the pricing model against your traffic shape.

If you are building this feature now, start free with 500 credits and run your interpreter workload against a real sandbox before you commit. The pricing page has the current shapes and rates.

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.