# What is an AI agent sandbox?

> An AI agent sandbox is an isolated computer where an agent can run code, install packages and use tools without touching your own machine, accounts or other users. A good one is a separate VM with its own kernel, holds only the secrets the task needs, limits what it can reach, and can be stopped, copied or thrown away.

Source: https://sandboxer.com/guides/what-is-an-ai-agent-sandbox. Updated 2026-10-24.

**Short answer:** An AI agent sandbox is an isolated computer where an agent can run code, install packages and use tools without touching your own machine, accounts or other users. A good one is a separate VM with its own kernel, holds only the secrets the task needs, limits what it can reach, and can be stopped, copied or thrown away.

## Why agents need one

A coding or computer-use agent does what a developer does: it runs shell commands, installs dependencies, starts servers and reads web pages. Two things make that risky on a machine you care about:

- **Mistakes.** A wrong `rm`, a bad migration or a runaway process hits whatever the agent can reach.
- **Untrusted input.** Instructions hidden in a web page, an issue or a file the agent reads can steer it (prompt injection). Then the agent acts with all the permissions it has.

A sandbox limits the damage to a machine that holds nothing else and that you can throw away.

## What to look for

| Property | Why it matters | In a Sandboxer sandbox |
| - | - | - |
| Isolation boundary | A shared kernel is a bigger attack surface than a hypervisor | Cloud Hypervisor microVM with its own kernel, one per sandbox |
| Secrets | The agent can only leak what's inside | `--no-env` starts with none of your secrets; add only what the task needs with `-e` |
| Network reach | Limits what a misled agent can contact | Can't reach other sandboxes directly or our internal networks; outbound internet is open by default |
| A full OS | Real tasks need packages, Docker, services | Ubuntu 24.04, root via `sudo`, systemd, Docker, `/dev/kvm` |
| Lifetime | Long tasks shouldn't die mid-way; idle ones shouldn't bill | No time limit on paid plans; stop saves memory and costs nothing |
| Disposable | Start clean, throw away after | Create in seconds, `sbx delete` when done, fork to try again |
| Observable | You need to see what it did | Command history, process list, streamed agent events |

## Container, gVisor or microVM?

| Approach | Boundary | Trade-off |
| - | - | - |
| Container (Docker) | Linux namespaces and cgroups on the shared host kernel | Light and fast; a kernel bug or a mounted Docker socket can break out |
| gVisor | A user-space kernel that intercepts system calls | Stronger than a plain container; some system calls and tools behave differently |
| MicroVM (Firecracker, Cloud Hypervisor) | Hardware virtualization; each sandbox has its own kernel | Strongest of the three; slightly more overhead per sandbox |

More detail: [Container vs microVM for untrusted code](/guides/container-vs-microvm-for-untrusted-code).

## Give an agent a sandbox in three commands

```bash
curl -fsSL https://sandboxer.com/install | sh                 # sbx CLI; signs you in
sbx new --no-env -e ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY"     # a VM with only this key
sbx prompt sb_k3v9x2mq --provider claude-code "Clone the repo, run the tests, fix what fails"
```

Or let your own agent create and use sandboxes as tools through the MCP server built into the CLI, `sbx mcp`. It gives Claude Code, Claude Desktop, Cursor, Codex or any MCP client tools to create sandboxes, run commands, move files, publish a port and stop the sandbox. See [MCP server](/docs/mcp).

## FAQ

### What is an AI sandbox?

An isolated environment where AI-generated code or an AI agent can run without access to your own computer, data or credentials. It can be a container, a gVisor sandbox or a virtual machine; a VM with its own kernel gives the strongest isolation.

### Is a Docker container a safe sandbox for an AI agent?

It's better than running on your laptop, but containers share the host's kernel. For untrusted or agent-written code, a microVM with its own kernel is a stronger boundary. Never mount the host's Docker socket into an agent's container.

### What should an agent sandbox not contain?

Anything you wouldn't hand to the agent's worst input: your SSH keys, long-lived cloud credentials, production database access and personal browser sessions. Pass only short-lived, narrowly scoped keys for the task.

### How long should a sandbox live?

As long as the task needs. Short code-execution calls can use throwaway sandboxes. Coding agents often need hours or days; then you want a sandbox you can stop and resume without losing work.

### How do I let my own agent create sandboxes?

Use an API or an MCP server. With Sandboxer, `sbx mcp` adds sandbox tools to any MCP client, and the REST API at `https://sandboxer.com/api/v1` works from any language.