Docker Sandboxes for AI Agents: Secure Execution Without Sacrificing Speed

February 2026 • 10 min read

AI coding agents execute arbitrary commands on your machine. They install packages, run scripts, modify files, and interact with system services. When everything works correctly, this is powerful. When an agent hallucinates a destructive command or a malicious dependency sneaks in through a supply chain attack, the consequences range from lost work to compromised credentials.

Docker sandboxing solves this by giving each AI agent an isolated environment where it can do its work without access to your host system. The agent thinks it has a full Linux environment. In reality, it is running inside a container with strict boundaries on what it can touch.

The Threat Model for AI Agents

Before setting up sandboxes, it helps to understand what you are protecting against. AI coding agents face three categories of risk.

Traditional Docker containers address the first two categories well. With additional configuration -- specifically network policies and volume restrictions -- you can address the third.

Basic Docker Sandbox Setup

The simplest approach is running Claude Code inside a Docker container with your project mounted as a volume. Here is a minimal Dockerfile:

FROM node:20-slim

# Install Claude Code
RUN npm install -g @anthropic-ai/claude-code

# Create a non-root user
RUN useradd -m -s /bin/bash agent
USER agent
WORKDIR /workspace

# Entry point
CMD ["claude"]

Run it with your project directory mounted:

docker run -it \
  -v $(pwd):/workspace \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  --name claude-sandbox \
  claude-sandbox

This gives the agent access to your project files but nothing else on your system. No SSH keys, no other project directories, no system configuration files. If the agent runs a destructive command, it affects only the mounted directory.

Zero-Trust Isolation with gVisor

Standard Docker containers share the host kernel. A sufficiently sophisticated exploit can escape the container. For true zero-trust isolation, use gVisor -- a user-space kernel that intercepts all system calls from the container and implements them in a sandboxed environment.

# Install gVisor runtime
sudo apt-get install -y runsc

# Configure Docker to use gVisor
sudo cat > /etc/docker/daemon.json <<EOF
{
  "runtimes": {
    "runsc": {
      "path": "/usr/bin/runsc"
    }
  }
}
EOF

# Run with gVisor runtime
docker run -it --runtime=runsc \
  -v $(pwd):/workspace \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  claude-sandbox

With gVisor, even if the agent finds a container escape vulnerability, it hits another layer of sandboxing. The performance overhead is roughly 5-10% for most development workloads -- negligible compared to the time spent waiting for API responses.

Filesystem Snapshots for Rollback

One of the most practical sandbox features for AI agent workflows is filesystem snapshotting. Before the agent makes changes, take a snapshot. If the changes are wrong, roll back instantly.

# Create a snapshot before agent runs
docker commit claude-sandbox claude-snapshot-pre

# Let the agent work...

# If something goes wrong, restore
docker stop claude-sandbox
docker rm claude-sandbox
docker run -it --name claude-sandbox \
  claude-snapshot-pre

For a more automated approach, use Docker volumes with overlay filesystems:

# Create a named volume for the workspace
docker volume create agent-workspace

# Copy project files into the volume
docker run --rm \
  -v $(pwd):/src:ro \
  -v agent-workspace:/dest \
  alpine cp -r /src/. /dest/

# Run agent against the volume (original files untouched)
docker run -it \
  -v agent-workspace:/workspace \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  claude-sandbox

Your original project files remain untouched. The agent works on a copy inside the Docker volume. Once you review the changes, you can apply them to your real project selectively.

Network Policies: Preventing Data Leaks

By default, Docker containers have full network access. An AI agent running curl or making HTTP requests can send data anywhere. For sensitive codebases, you want to restrict network access to only what the agent needs.

# Run with no network access
docker run -it --network=none \
  -v $(pwd):/workspace \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  claude-sandbox

The problem: Claude Code needs network access to reach the Anthropic API. The solution is a custom network with restricted egress:

# Create a restricted network
docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.enable_ip_masquerade=true \
  agent-network

# Run with restricted network
docker run -it \
  --network=agent-network \
  -v $(pwd):/workspace \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  claude-sandbox

Then use iptables rules or a proxy container to allow only traffic to api.anthropic.com and block everything else. This prevents the agent from reaching package registries (stopping supply chain attacks), external services, or data exfiltration endpoints.

Running Claude Code Safely in Containers

Here is a production-ready Docker Compose configuration that puts all the pieces together:

version: '3.8'
services:
  claude-agent:
    build: ./docker/claude-sandbox
    volumes:
      - ./project:/workspace
      - agent-output:/output
    environment:
      - ANTHROPIC_API_KEY
    networks:
      - agent-restricted
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:size=512M

volumes:
  agent-output:

networks:
  agent-restricted:
    driver: bridge

This configuration enforces: read-only root filesystem (the agent can only write to /workspace, /output, and /tmp), CPU and memory limits (prevents runaway processes), no privilege escalation, and an isolated network.

Multi-Container Agent Orchestration

For multi-agent workflows, run each agent in its own container with its own sandbox boundaries:

services:
  implementer:
    build: ./docker/claude-sandbox
    volumes:
      - ./project:/workspace
    # Full read-write for implementation

  reviewer:
    build: ./docker/claude-sandbox
    volumes:
      - ./project:/workspace:ro
    # Read-only: can review but not modify

  tester:
    build: ./docker/claude-sandbox
    volumes:
      - ./project:/workspace:ro
      - ./tests:/tests
    # Read-only project, write to tests only

Each agent has precisely the access it needs and no more. The implementer can modify project files. The reviewer can only read them. The tester can read the project and write test files. This is the principle of least privilege applied to AI agents.

Monitoring Sandboxed Agents with Beam

Running AI agents in Docker containers means their output lives inside the container's terminal session. Without tooling, you are limited to docker logs and docker attach -- useful for one container, unmanageable for three or four running simultaneously.

Beam connects to each container's terminal session and displays them in organized panes within a single workspace. You configure each pane to attach to a specific container, and Beam handles the connection management. The result: a dashboard showing every sandboxed agent's activity in real time.

When an agent in the implementer container finishes a feature, you see it immediately. When the reviewer container flags a security issue, it appears in the adjacent pane. When tests pass or fail in the tester container, the results show in the third pane. All visible at once, all isolated from each other and from your host system.

When to Sandbox and When Not To

Docker sandboxing adds setup complexity. Not every workflow needs it. Here is a practical decision framework:

• Always sandbox when working with production credentials, customer data, or proprietary code that must not leak
• Always sandbox when running agents in fully autonomous mode without human approval of each command
• Consider sandboxing for open source projects or personal experiments where the risk is lower but you want clean isolation
• Skip sandboxing when using Claude Code's built-in permission system (it asks before executing commands) and you are actively supervising the session

The supervised, human-in-the-loop workflow with Claude Code already provides a layer of safety -- you approve every file edit and command execution. Docker sandboxing adds defense-in-depth for scenarios where that human oversight is insufficient or impractical.