An AI agent sandbox is an isolated computer where an AI agent can run code, install software, edit files and use a browser without touching your own machine or your production systems. If the agent runs a bad command, follows a malicious instruction hidden in a web page, or just makes a mess, the damage stays inside the sandbox.
This guide explains why agents need one, the main kinds of isolation, what to check before you choose one, and where BoxCompute fits. We make BoxCompute, so we say where our approach is the wrong one.
Why an agent needs its own computer
A chatbot only writes text. An agent acts. To fix a bug it runs the test suite; to build an app it installs packages and starts a dev server; to research something it opens web pages and downloads files. Every one of those steps runs a command somewhere.
If that somewhere is your laptop or your server, four things can go wrong:
- Mistakes. One wrong
rm -rf, a migration against the wrong database, or a script that fills the disk. - Prompt injection. An agent reads text it didn't write: web pages, issues, emails, files. Any of it can carry instructions, and a model can't reliably tell your instructions from an attacker's. OWASP lists prompt injection as the top risk for LLM applications.
- Secrets. Your machine holds SSH keys, cloud credentials and browser sessions. An agent with a shell on it can read them.
- Your machine is busy. A long build, a crawler or a server the agent leaves running ties up your laptop, and stops when you close the lid.
A sandbox answers all four the same way: the agent gets a machine of its own, with only the files, network access and credentials you choose to give it.
What a sandbox gives an agent
Most agent sandboxes offer the same core:
- A shell, so the agent can run commands and read their output.
- A filesystem, to clone a repository, write code and keep results.
- Network access, usually on by default and sometimes restricted, to install packages and call APIs.
- Ports and preview links, so a web app the agent starts can be opened in your browser.
- Sometimes a desktop, with a real browser the agent can see and click, for websites that have no API.
The agent reaches all of this through tools: an SDK, an API, a CLI or an MCP server. The model decides what to run, and the sandbox is where it runs.
Four kinds of isolation
“Sandbox” covers very different technology. The main difference is how much stands between the agent's code and the machine underneath.
| Kind | What isolates the agent | Start time | Typical use |
|---|---|---|---|
| OS-level sandbox | Rules on one process, on your own machine | Instant | Limiting a coding agent on a laptop |
| Container | Linux namespaces; shares the host's kernel | Under a second | Trusted code, local development |
| User-space kernel (gVisor) | A kernel in user space that intercepts system calls | Under a second | Untrusted code at high volume |
| MicroVM (Firecracker) | A minimal virtual machine with its own kernel | Milliseconds from a snapshot | Short-lived sandboxes for untrusted code |
| Full VM | A complete virtual machine with its own kernel and OS | Seconds to tens of seconds | Long-running agent work, desktops |
The pattern: the stronger the wall between the agent and the host, the more work it takes to start. Containers are the weakest boundary, because every container on a host shares one kernel and a kernel bug can cross it. gVisor and microVMs exist to keep most of a container's speed while adding a real boundary. A full VM is the most complete computer, and the slowest to boot.
Isolation is only half the picture. A sandbox can be perfectly isolated and still let the agent send your data anywhere on the internet. Which network destinations, files and credentials the agent can reach is a separate set of settings, and it matters as much as the wall.
Disposable or persistent
The second big difference is what happens when the work stops.
Disposable sandboxes start in milliseconds, run some code and disappear, or pause until the next request. They suit code interpreters, evaluations and products that start a fresh sandbox for every user action. Most providers now offer pausing or snapshots, but speed and scale come first.
Persistent sandboxes keep their disk, often for as long as you like. The agent installs its tools once, comes back tomorrow to the same files, and can keep a service running. They suit agents that work on one project for hours or days, or that use a desktop.
Many teams use both: a persistent machine for the agent's ongoing work, and disposable sandboxes for one-off code it doesn't trust.
What to check before you choose
- Isolation. Container, gVisor, microVM or full VM, and whether that matches how much you trust the code.
- Start time. Sub-second matters if a person waits on every start. It matters much less for a job that runs for an hour.
- Longest session. Many providers cap a session at somewhere between 45 minutes and 24 hours, depending on the plan. Check what happens at the limit.
- What survives a stop. Disk, memory, running processes, and for how long a stopped sandbox is kept.
- Network controls. Whether you can block internet access, or allow only some destinations.
- Secrets. How credentials reach the sandbox, and whether the agent can read them.
- Region. Where the sandbox runs and where its files are stored, for latency and for data rules.
- Desktop and browser. Built in, available as a template, or something you build yourself.
- How you connect. SDKs for your language, an HTTP API, a CLI, or an MCP server your agent can use directly.
- Billing. Per second while running, only while the CPU is busy, or by plan. Check the minimum charge and what a stopped sandbox costs.
Our comparison of E2B, Daytona, Modal, Vercel and BoxCompute goes through these points provider by provider, with sources.
Local or hosted
You can sandbox an agent on your own machine. OS-level sandboxes and local container or microVM tools keep the agent away from most of your files, and cost nothing extra.
Teams that run their own Kubernetes clusters can host sandboxes themselves; the Kubernetes Agent Sandbox project is building a standard way to do it.
A hosted sandbox adds what a laptop can't: it keeps working when you close the lid, it doesn't share hardware with your own work, many can run at once, and a preview link works for anyone you send it to. The cost is that you pay for the compute, and your code runs in someone else's data centre.
How BoxCompute does it
BoxCompute gives each agent project a full Linux VM with its own kernel, hosted in Cyberjaya, Malaysia.
- It keeps its disk.
/workspace, installed packages and the agent's files stay when the VM stops, with no expiry. A VM stops after 30 minutes idle, and a stopped VM costs nothing. - It has a desktop. On Large and bigger VMs, the BoxCompute agent can use Chrome on the VM's own screen while you watch, and you can take over.
- It works with the agent you already use. Connect Claude, Claude Code, Codex or Cursor through our MCP server, or use the HTTP API, CLI and SDKs. Or use the BoxCompute agent in your browser.
- It is billed by the second. About $0.05 an hour for Small (0.5 vCPU, 1 GiB) and $0.15 for Large (1.5 vCPU, 3 GiB), with a one-minute minimum.
And the trade-off: a new VM takes about 30 seconds to boot, and resuming a stopped one about 20. If you start thousands of short sandboxes an hour, a microVM service will serve you better. If an agent works in one place for an hour or a week, half a minute at the start matters less than a computer that remembers.
Questions people ask
Is a Docker container a sandbox? It's a light one. A container keeps an agent's files and processes apart, but it shares the host's kernel, so it's a weaker boundary than gVisor, a microVM or a VM. It's fine for code you trust; for code an agent writes from untrusted input, use something stronger.
Is a sandbox the same as a VM? No. A VM is one way to build a sandbox. Others use containers, gVisor or microVMs.
Can a sandboxed agent reach the internet? Usually yes, by default, because agents need to install packages. Many providers let you turn it off or restrict it. Remember that isolation doesn't stop an agent from sending data out over an open network.
Do I need one if I just chat with ChatGPT or Claude? No. You need a sandbox once the AI runs code or commands for you. Chat apps that run code already use their own.
How much does it cost? Hosted sandboxes are usually billed per second of compute, a few cents an hour for a small machine. BoxCompute gives eligible new accounts $5 of free credit for 14 days, which is about 100 hours of a Small VM.
Sources
- OWASP: LLM01 Prompt Injection
- gVisor: What is gVisor?
- Firecracker: project site
- Kubernetes SIG Apps: Agent Sandbox
- BoxCompute: pricing, MCP server, comparison with other providers