How to run AI-generated code safely in a sandbox

By the end of this guide you will have a setup where code written by a language model runs inside an isolated environment instead of on your own server: your app sends the code in, the sandbox executes it, and you get output back without the code touching your files, secrets or network. The tool for the job is a code sandbox for AI agents, which is usually a cloud service or a self-hosted runtime built on containers or microVMs.

The reason to bother is simple: model-written code is untrusted code. This guide covers how to pick between hosted and self-hosted options, the order of setup, and a comparison of six tools from our Developer platforms category.

Key takeaways

• Treat every line an AI model writes as untrusted. Run it in a sandbox with no access to your host, your secrets or your internal network.
• The main decision is hosted or self-hosted. E2B and Runloop are hosted services, while SPACE, CubeSandbox and forkd are open source and you operate them yourself.
• Isolation strength varies: microVM-based tools give each sandbox its own kernel, while plain containers share the host kernel.
• A sandbox limits damage, but it does not make output correct. Review code before it runs anywhere that matters.

What you need before you start

• A clear job for the code. For example data analysis for an agent, running tests, or building a coding assistant. This decides how long sandboxes live and how much compute they need.
• A way to call the sandbox. Hosted services offer SDKs and APIs. E2B lists Python and JavaScript SDKs, a CLI and an API.
• Infrastructure skills if you self-host. SPACE documents Kubernetes setup, and forkd needs Linux with KVM.
• A list of what the code may reach. Files, packages, domains and credentials.
• Time. A hosted prototype takes under an hour. A self-hosted setup takes a day or more.
• Difficulty. Moderate for hosted services, harder for self-hosted runtimes.

Which kind of AI tool fits this job

Hosted sandbox services. You call an API, run code, and pay for usage. E2B creates isolated cloud sandboxes through its SDKs, supports custom templates and a Code Interpreter service, and bills per second while a sandbox runs. Runloop offers devboxes for AI software engineering agents, with blueprints, snapshots and agent gateways that keep LLM keys out of the sandbox.

Self-hosted microVM sandboxes. If code or data cannot leave your infrastructure, run the sandbox yourself. SPACE is an open-source platform published by Perplexity that runs code in Firecracker microVMs through an HTTP API. CubeSandbox is a self-hosted microVM service built on RustVMM and KVM, with an E2B-compatible SDK interface. forkd is an open-source Firecracker runtime that forks many sandboxes from a warmed parent snapshot, which suits running many parallel attempts.

A runtime layer for Kubernetes. Edera is a container runtime that gives each Kubernetes pod its own microVM with a dedicated Linux kernel. It installs as a RuntimeClass and runs existing container images, so it suits teams that already run on Kubernetes and want stronger isolation without a new API.

Step 1: Define the threat and the requirements

You end this step knowing what the sandbox must protect and what the code needs.

1. List what must be protected: your host, other tenants, API keys, internal services, user data.
2. List what the generated code genuinely needs: packages, file access, network access to specific domains, run time.
3. Decide lifetime: a one-shot run, or a session that persists across steps.
4. Decide scale: how many sandboxes at once, and how quickly they must start.

Check it worked by writing two sentences: what the code may touch, and what it must never touch.

Step 2: Choose hosted or self-hosted

Pick the operating model before the product.

1. Choose hosted if you want the fastest start and no infrastructure to run. E2B's Hobby plan has a $0 base price and a one-time $100 of free credits, according to its listing.
2. Choose self-hosted if data must stay inside your network. SPACE, CubeSandbox and forkd are all open source, and you operate them yourself.
3. Choose a runtime layer such as Edera if you already run workloads on Kubernetes.
4. Check hardware needs. forkd needs Linux 5.7 or newer with KVM, and managed Kubernetes often needs metal nodes or nested virtualization for it.

Check it worked by confirming your team can run and patch whatever you pick.

Step 3: Create your first sandbox and run code

Get one end-to-end run working before you wire in a model.

1. Install the SDK or deploy the service. With E2B, you create a sandbox, execute code in it, then pause or kill it when the job ends.
2. Run a harmless script, such as printing the Python version, and read the output.
3. Run a script that tries something you want blocked, such as reading a file outside the sandbox or reaching an internal address.
4. Confirm the attempt fails and note how the failure appears.

Check it worked by seeing the harmless run succeed and the blocked run fail.

Step 4: Connect the model and pass code in

Now let the model write the code.

1. Send the model's output to your sandbox rather than to a shell on your own machine.
2. Pass only the files and data the task needs.
3. Return stdout, stderr and any generated files to the model or user.
4. Keep API keys out of the sandbox. Runloop's agent gateways proxy LLM requests so keys are not exposed to the sandbox, and CubeSandbox lists a credential vault with domain filtering.

Check it worked by running a task end to end and confirming no secret is visible from inside the sandbox.

Step 5: Set limits on time, resources and network

A sandbox that can run forever or reach anything is only half a sandbox.

1. Set a maximum run time. E2B's Hobby sandboxes run for up to 1 hour continuously and allow 20 concurrent sandboxes, so know your plan's limits.
2. Set CPU and memory sizes. E2B's templates can set vCPU and memory, and forkd supports per-child cgroup memory limits.
3. Restrict network access to the domains the task needs. CubeSandbox lists domain allowlists with audit logs.
4. Set spending limits. E2B's dashboard lists spending limits and a usage tab.

Check it worked by running an infinite loop and a large allocation and seeing both stopped cleanly.

Step 6: Handle state, snapshots and cleanup

Decide what survives between runs.

1. For one-off runs, destroy the sandbox as soon as the result is back.
2. For longer sessions, pause rather than keep running. E2B lists paused and killed sandboxes as costing nothing, and SPACE lists keep, pause and suspend options.
3. Use snapshots to skip repeated setup. forkd caches installed packages as snapshots, and Runloop snapshots save a devbox's disk state.
4. Track lifecycle events. E2B lists webhooks for created, paused and killed sandboxes.

Check it worked by listing active sandboxes after a test run and finding none left over.

Step 7: Log, review and test your defenses

Assume something will eventually go wrong, and prepare to see it.

1. Log every piece of code sent to the sandbox, with the prompt that produced it.
2. Keep audit logs where the tool offers them. forkd lists an append-only JSON audit log.
3. Test with hostile prompts that ask the model to write code that probes the network or reads environment variables.
4. Review the vendor's own caveats. forkd's benchmark figures come from the project's own tests, and SPACE marks some fields as incubating, outside its supported contract.
5. Have a person review code before it is allowed to run against production systems or real customer data.

Check it worked by confirming a hostile test run is logged and blocked.

Tools for this job compared

Tool	Good fit for	Pricing	Stated limits
E2B	Hosted sandboxes through Python and JavaScript SDKs, CLI and API	Freemium, paid from $150/mo (checked 24 Oct 2026)	CPU-only; Hobby sandboxes run up to 1 hour with 20 concurrent; Volumes are in beta
SPACE	Self-hosted Firecracker microVMs via HTTP API	Open source	You deploy and operate it yourself; lifecycle calls are asynchronous and need polling
Edera	Per-pod microVM isolation on Kubernetes	Contact sales	hostNetwork pods unsupported; initial image pulls can be slower; EderaON licenses last 90 days
CubeSandbox	Self-hosted microVMs with E2B SDK compatibility	Open source	No hosted service; GPU sandboxes and full E2B API parity are roadmap items
forkd	Forking many Firecracker sandboxes from one snapshot	Open source	Needs Linux 5.7 or newer with KVM; self-hosted; benchmarks are the project's own
Runloop	Hosted devboxes for AI software engineering agents	Freemium, paid from $250/mo (checked 24 Oct 2026)	Usage-based compute billed separately; Pro Trial caps at 3 running devboxes

Prices and plan limits change, so confirm the current terms on each vendor's site before you build around them.

Common mistakes to avoid

• Running model output on your own server. A single bad command can read files or secrets. Fix it by sending all generated code to a sandbox and never executing it with your app's own permissions.
• Assuming containers are enough. Containers share the host kernel, so a container escape can reach other workloads. Fix it by choosing a microVM-based option such as SPACE, CubeSandbox, forkd or Edera when isolation matters most.
• Leaving the network open. Code that can reach anything can leak data or probe internal systems. Fix it by allowing only the domains the task needs and logging requests.
• Putting secrets inside the sandbox. Anything the code can read, it can print or send. Fix it by using gateways or vaults that keep keys outside the sandbox.
• Forgetting cleanup. Sandboxes left running add cost and attack surface. Fix it by destroying or pausing sandboxes after each task and checking the active list regularly.

How we put this together

This is an evidence-based guide built from each tool's listing in our directory, which is compiled from the vendor's own site and pricing page. It is not a review based on using the tools. We don't rank tools, and nobody paid to be included. Some outbound links may be affiliate links; see our disclosure.

Frequently asked questions

Is there a free way to run AI-generated code in a sandbox?

Yes. SPACE, CubeSandbox and forkd are open source and list no paid plans, though you pay for the hardware and effort of running them. E2B's Hobby plan has a $0 base price and a one-time $100 of free credits, and Runloop's Basic plan is free plus usage-based compute.

Why not just run the code in a Docker container?

A container shares the host's kernel, so a container escape can reach the host and other workloads. Edera and CubeSandbox give each sandbox its own kernel, SPACE and forkd run each sandbox as a Firecracker microVM, and forkd lists KVM hardware isolation for each child. Containers can still be part of a defense, but they are weaker isolation for untrusted code.

Can a sandbox make AI-generated code safe?

It limits what the code can damage, but it does not make the code correct or the output trustworthy. Review code and results before using them for anything important, and keep a person in the loop for actions that affect customers, money or production systems.

Do I need GPUs in the sandbox?

Often not. E2B sandboxes are CPU-only with no GPU option, and CubeSandbox lists GPU sandboxes as a roadmap item. Edera targets GPU workloads on Kubernetes, so check the listing for your needs.

Can I keep the code and data inside my own infrastructure?

Yes, with self-hosted options. SPACE, CubeSandbox and forkd are all run by you, and Edera installs into your own Kubernetes cluster. Hosted services such as E2B and Runloop run in the vendor's environment, so read their data terms first.

Compare more options in our Developer platforms category.