Blog / agent sandboxes

How to Give an AI Agent a Safe, Isolated Environment on Your Own Machine

Run an AI agent's code in an isolated sandbox on your own laptop or server, with real API keys kept out of it. A step-by-step Hotcell quickstart.

A safe isolated environment for AI agents on your own machine

To give an AI agent a safe place to write and run code on your own machine, run it in a sandbox: a container or microVM with its own filesystem, limited network access and no copy of your real API keys. Hotcell, our open-source sandbox runtime, sets this up in about two commands. Each sandbox gets a short-lived token instead of your key, so a misbehaving agent can't leak anything that works outside your machine.

This guide walks through it step by step. Last reviewed October 2026.

What "safe" means for an agent

An agent that writes and runs code needs four things kept in check:

  • Files. It should only see the project it's working on, not your home folder.
  • Network. It should reach the services it needs and nothing else.
  • Keys. It should never hold your real API keys, because anything it can read, a prompt injection can make it print or send.
  • Resources. It shouldn't be able to use all of your machine's memory or CPU.

Plain Docker covers the first and partly the last. Hotcell adds the other two.

What you need

  • macOS or Linux.
  • Node.js 22 or later.
  • Docker (Docker Desktop, OrbStack or colima on a Mac). On Linux with KVM, Hotcell can also use Firecracker microVMs. On macOS it can use Apple Virtualization microVMs.

Step 1: Install Hotcell

npm i -g hotcell
hotcell

The first run is a short guided setup. After that, hotcell shows your sandboxes, with live CPU, memory and cost for each.

If you just want coding agents that run in sandboxes like this, npm install -g directionallylocal sets up Hotcell and Autopilot for you; see the docs.

If you use colima or another Docker runtime on a non-default socket, point Hotcell at it first:

export DOCKER_HOST=unix://$HOME/.colima/default/docker.sock

Step 2: Add your API key to the host

hotcell keys add openrouter

The key is stored on your machine, outside every sandbox. You can also import a .env file with hotcell keys import .env. It asks, for each variable, whether it should go through the gateway (the sandbox gets a token) or be copied in.

Step 3: Create a sandbox

hotcell create -n 1 --repo https://github.com/you/app --branch

This creates one sandbox with your repo cloned on its own branch. Use -n 5 to create five, one per agent.

Step 4: Work inside it

hotcell terminal <id>

This opens a shell inside the sandbox. Run your agent there. Calls to model providers and GitHub go through Hotcell's gateway, which swaps the sandbox's token for your real key on the way out, and meters and caps what each sandbox spends.

For a quick one-off command, create, run and destroy in one step:

hotcell run --setup "pip install ruff" "ruff check ."

Step 5: Clean up

hotcell rm --all

Every sandbox is gone. Your repo on the host is untouched.

Plain Docker vs Hotcell

Plain Docker Hotcell
Separate filesystem Yes Yes
MicroVM isolation No Yes: Firecracker (Linux/KVM) or Apple Virtualization (macOS)
Real API keys kept out No, unless you build a proxy Yes: per-sandbox tokens through a gateway
Spend caps per sandbox No Yes
Default-deny outbound network Manual Optional; enforced by the kernel on Linux and in microVMs
Refuses to overload the machine No Yes: admission control

What it can't protect

The gateway works for credentials sent in an HTTP header, which covers model providers, GitHub and most REST APIs. It can't swap credentials for databases such as Postgres, request-signing schemes such as AWS SigV4, or client certificates. If you copy those into a sandbox, the sandbox can read them.

Next steps

FAQs

Is Docker enough to sandbox an AI agent?

Docker gives the agent its own filesystem, and you can limit its CPU and memory. It doesn't keep your API keys away from the agent or cap what it spends, and outbound network rules are up to you. Hotcell adds those, and can use microVMs for a separate kernel per agent.

What's the difference between a container and a microVM for agents?

A container shares the host's kernel, so a kernel exploit inside it can reach the host. A microVM, such as Firecracker on Linux or Apple Virtualization on macOS, gives each sandbox its own kernel. Hotcell supports all three.

Can the agent still call OpenAI, Anthropic or GitHub without the real key?

Yes. The sandbox gets a short-lived token. Hotcell's gateway on the host swaps it for your real key on the way out, and meters and caps what each sandbox spends.

What secrets can't Hotcell protect?

Credentials that aren't sent in an HTTP header: database passwords such as Postgres, request-signing schemes such as AWS SigV4, and client certificates. If you copy those into a sandbox, the agent can read them.

Does this work on a Mac?

Yes. Hotcell runs on macOS with Docker Desktop, OrbStack or colima, and can use Apple Virtualization microVMs. On Linux with KVM it can use Firecracker microVMs.

Do I have to set this up myself to run coding agents?

No. npm install -g directionallylocal then dl sets up Hotcell and Autopilot, our coding agent harness, on your computer or server. Each task runs in its own sandbox and comes back as a pull request.