Sandboxes for AI Agents: Docker and VMs

What This Article Covers

• Why AI agents should run in isolation
• What a sandbox means in the context of agents
• How Docker functions as a lightweight sandbox
• When a virtual machine makes sense
• How filesystem and network isolation work

Introduction

AI agents are compelling because they can complete tasks autonomously. They access tools, read files, execute commands, and communicate with other APIs. Yet this same freedom introduces risk. An agent with unrestricted access to your operating system can cause serious damage.

A sandbox is a confined space where an agent operates. What happens inside stays inside. Files, processes, and network connections are isolated from the rest of your system. In this article, we’ll show you how to build such an environment using Docker and virtual machines.

If you’re getting started with AI agent fundamentals, check out our guides on Tool Calling and safe operations.

Why Sandboxes Matter for AI Agents

Without constraints, agents can be dangerously capable. A small prompt mistake or a misunderstood command might cause an agent to delete files, extract passwords, or send sensitive data online.

A sandbox prevents a single agent failure from compromising your entire system. It provides:

• Restricted filesystem access
• Limited network capabilities
• Control over allowed processes and resources
• Quick recovery through sandbox reset
• Separation between agents and sensitive user data

Sandboxes are not a substitute for human approval or guardrails, but they form an essential technical foundation. Both should always work together.

Understanding Sandboxes

Think of a sandbox as an isolated playground. An agent can work inside it, but can’t simply walk through a door into the rest of your house. Technically, this happens through OS-level features like namespaces, cgroups, capabilities, and virtual networks.

Namespaces isolate processes from one another. Cgroups limit CPU, RAM, and disk usage. Capabilities restrict which root permissions a process holds. Virtual networks allow you to filter traffic.

Docker leverages these Linux kernel features to build containers. A virtual machine takes isolation further by spinning up an entire separate operating system. Both approaches have merit depending on your threat model and isolation requirements.

Who Should Read This

This article is for developers who want to run AI agents locally or on a server. You should be comfortable with the terminal. Docker experience helps but isn’t required.

This is for you if you:

• Need to run an AI agent with tools like Bash or Python
• Want to prevent an agent from accidentally modifying files
• Plan to use Docker or virtual machines for isolation
• Need to understand which isolation level fits your scenario

Key Terms

Term	Definition
Sandbox	An isolated environment where a process runs with restricted privileges.
Container	A lightweight isolation environment sharing the same kernel.
Docker	A platform for building and running containers.
VM	Virtual machine. A full operating system on simulated hardware.
Namespace	A kernel feature that isolates processes from each other.
Cgroup	A kernel feature that limits resources like RAM and CPU.
Capabilities	Fine-grained root permissions a process may hold.
Volume	A mounted directory in a container that shares data with the host.
Image	A read-only template for a container.
Layer	A filesystem level within a container image.

Docker as a Sandbox

Docker is the fastest way to isolate an AI agent. A container starts in seconds and has minimal overhead. You control which files, networks, and permissions the container receives.

A typical command for a strong sandbox looks like this:

docker run -d \
  --name kisandbox \
  --read-only \
  --tmpfs /tmp \
  --cap-drop all \
  --cap-add chown \
  --network none \
  mein-agent-image

This command does several things:

• --read-only makes the root filesystem read-only.
• --tmpfs /tmp allows temporary writes only in RAM.
• --cap-drop all removes all special privileges.
• --cap-add chown adds back a single specific right.
• --network none disables network access entirely.

For files the agent should modify, use volumes. Be careful to expose only specific directories and never mount sensitive paths like /etc or /home. For more on Docker basics, see our guide to Docker fundamentals.

Virtual Machines

A virtual machine is the strongest sandbox option. It emulates complete hardware and boots its own operating system. Even if an attacker or buggy agent compromises the VM, your host system remains far better protected than with a container.

VMs make sense when you:

• Need to test high-risk tasks
• Require different operating systems
• Want a clear boundary between host and agent
• Plan to take snapshots before and after runs

The tradeoff is resources. Each VM runs its own operating system. On a home server with limited RAM, this becomes a bottleneck quickly. Tools like Proxmox, virt-manager, or VirtualBox simplify management.

To set up your own server, check out our Ubuntu guide.

Filesystem Isolation

Filesystem isolation is critical for AI agents that use tools to access files. By default, a container can access files within its own filesystem. Mounting volumes opens doors you must control.

Best practice is to use read-only volumes where appropriate:

docker run -d \
  -v /home/benutzer/daten:/data:ro \
  mein-agent-image

The :ro flag means read-only. The agent can read the files but cannot modify them. For output, define a separate writable directory the agent can write to but perhaps shouldn’t read from again, depending on your use case.

Running as a non-root user inside the container is also recommended. Add a user in your Dockerfile:

RUN useradd -m agent
USER agent

This way, even if a process breaks out of the container boundary, it won’t run as root on the host.

Network Isolation

Network isolation prevents an agent from sending data to the internet or querying internal services that shouldn’t be accessible. Docker offers several network modes:

• bridge: Default. The container has limited network access.
• none: No network.
• host: Container shares the host’s network stack. Avoid this.
• container:NAME: Container shares another container’s network.

For agents that don’t need internet access, none is often the best choice. If you need access to a local API endpoint, create a bridge network and allow specific ports only:

docker network create agent-net
docker run -d --network agent-net --name ollama ollama/ollama
docker run -d --network agent-net -e OLLAMA_HOST=http://ollama:11434 mein-agent-image

Now the agent communicates only with Ollama, not with the broader network or the internet.

Common Pitfalls

1. Running containers as root: The process inside the container should be its own non-root user. Root inside a container isn’t true root, but it’s still risky.
2. Granting too many capabilities: Using --privileged or ALL capabilities gives your agent far more permissions than necessary. Remove everything and add back only what you actually need.
3. Using the host network: --network host removes isolation. Avoid this mode for agents.
4. Mounting sensitive directories: Mounting /, /etc, or /home gives the container direct access to critical host files.
5. No resource limits: Without cgroup limits, a malfunctioning agent can consume all available RAM or CPU.
6. Pulling untrusted images: Not all images are secure. Use only trusted sources and scan images for vulnerabilities.
7. Forgetting snapshots: Before running important operations on a VM, create a snapshot. This lets you roll back quickly if needed.

Hardware, Costs, and Security

Docker containers run on nearly any hardware that supports Linux. A simple home server or VPS is sufficient for most agents. VMs require more RAM and disk space because each guest system operates independently.

Costs come mainly from hardware, not software. Docker and virtualization tools like Proxmox or virt-manager are free. Cloud VMs are billed by resource consumption.

From a security perspective, deeper isolation provides better protection at the cost of more resources. Containers are adequate for most home setups. VMs make sense if you’re running highly sensitive or untrusted code. Always combine sandboxes with human approval and guardrails to catch human mistakes.

Further Reading

• Secure Operations
• Agent Security Overview
• Human Approval
• Configuring Guardrails
• Tool Calling
• Docker Fundamentals
• Ubuntu Server Setup

FAQ

What is a sandbox?

A sandbox is a restricted execution environment where a process can access only defined resources.

What’s the difference between Docker and a VM?

Docker shares the host’s kernel and is lightweight. A VM runs its own operating system and offers stronger isolation, but consumes more resources.

Should I run an agent as root?

No. An agent process should always run as its own non-root user, both in containers and on VMs.

What are capabilities?

Capabilities are fine-grained special permissions on Linux. They define which actions a process can perform, even when it runs as root.

What is a read-only volume?

A read-only volume allows a container to read data from the host but not write to it.

Does my agent need network access?

Only if it needs to reach external APIs or models. For purely local tasks, you can disable networking.

What does --network none do?

This Docker option completely disables network access for the container.

Are containers secure enough for AI agents?

Yes, for most home and development environments. For highly sensitive or untrusted code, consider using a VM.

What is a snapshot?

A snapshot is a saved state that you can roll back to later. Most VM platforms offer this feature.

Can I run multiple agents in a single container?

Yes, but it’s better to isolate each agent in its own container. This prevents them from interfering with each other.

What is a Dockerfile?

A Dockerfile is a text file containing instructions that Docker uses to build an image.

How important are resource limits?

Very important. Without limits, a faulty agent can bring down your host. Cgroups and Docker flags help enforce them.

Sources

1. Docker Documentation - https://docs.docker.com/
2. Docker Security Cheat Sheet - https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
3. Linux Capabilities - https://man7.org/linux/man-pages/man7/capabilities.7.html
4. NixOS Wiki: Namespaces and Cgroups - https://wiki.nixos.org/wiki/Namespaces