Docker vs VM for Sandboxing AI Agents: Which Security Approach Actually Works?

Mar 11, 2026

Problem

When I wanted to sandbox Claude Code for security, I faced a choice: Docker container or Virtual Machine? I assumed VMs were more secure because they provide hardware-level isolation.

I was wrong. The isolation technology matters less than the network configuration.

Environment

Consideration: Docker vs VM for AI agent isolation
Concern: Preventing AI agents from accessing host resources
Goal: Security without excessive overhead

What Happened?

A Reddit user tried to sandbox Claude Code in a VM. During the first prompt, Claude accessed Chrome on the host machine through the network bridge.

This incident revealed a key insight: the vulnerability wasn’t VM-specific. As one commenter noted:

“I’m sure a dockerized Claude would have had the same ability.”

The same network misconfiguration (bridged networking with localhost-bound services) would affect both Docker and VMs.

How to Solve It?

Docker Approach (Recommended for AI Agents)

Docker provides adequate sandboxing for AI agents when properly configured:

version: '3.8'
services:
  claude-sandbox:
    image: claude-code:latest
    container_name: claude-isolated
    # Critical: Use bridge network with no host access
    networks:
      - isolated-network
    # Disable network if possible
    # network_mode: none  # Maximum isolation
    # Or restrict to specific hosts only
    extra_hosts:
      - "localhost:127.0.0.1"  # Block real localhost
    # Read-only filesystem where possible
    read_only: true
    # Drop all capabilities
    cap_drop:
      - ALL
    # No privilege escalation
    security_opt:
      - no-new-privileges:true
    # Resource limits
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G

networks:
  isolated-network:
    driver: bridge
    internal: true  # No external access

Network Isolation Levels

The security level depends on configuration, not the technology:

Level	Docker Config	VM Config	Security
Maximum	`network_mode: none`	Internal-only vSwitch	Agent cannot reach any network
High	Internal bridge network	NAT with firewall rules	Cannot reach host directly
Medium	Default bridge + iptables	Bridged with host firewall	Requires careful rule setup
Low (Dangerous)	Host network	Bridged networking	Full host network access

Performance Comparison

Docker offers significantly better resource efficiency:

Metric	Docker	VM
Startup Time	~1-2 seconds	30-60 seconds
Memory Overhead	~10-50MB	512MB - 2GB
CPU Overhead	~1-2%	5-15%
Disk Usage	Layer sharing, minimal	Full disk image per VM
Snapshot Speed	Instant (layers)	Minutes
Density	100s per host	10-20 per host

When to Use VM Instead

VMs are appropriate for specific scenarios:

# VM is appropriate when:
# 1. Running untrusted code with kernel-level exploit risk
# 2. Need different OS kernel (Windows on Linux host)
# 3. Compliance requires hardware-level isolation
# 4. Testing kernel modules or drivers

For AI agents, the attack surface isn’t kernel exploitation. It’s:

Network services on localhost
File permissions and credentials
Environment variables and secrets
API endpoints and webhooks

Docker handles these equally well to VMs with proper configuration.

The Reason

I think the key insight is understanding the actual threat model.

Docker Security Model:

Kernel sharing (same OS kernel)
Namespaces for isolation (PID, NET, MNT, UTS, IPC, USER)
Cgroups for resource limits
Seccomp for syscall filtering
Capabilities for privilege management

VM Security Model:

Hardware-level isolation
Separate kernel per VM
Hypervisor enforcement
Hardware virtualization (VT-x, AMD-V)

For AI agents like Claude Code, the security concern isn’t kernel escape - it’s network misconfiguration and credential exposure. Docker namespaces and network isolation handle these concerns effectively.

Common Mistakes

Mistake 1: Assuming VM = Automatic Security

# WRONG: VM with bridged network exposes host services
# The Chrome extension was accessible because:
# - VM used bridged networking
# - Extension listened on 0.0.0.0 or localhost
# - VM and host shared IP address space

Mistake 2: Using Default Docker Network

services:
  claude:
    image: claude-code
    # No network config = can reach host

Mistake 3: Forgetting Environment Variables

environment:
  - ANTHROPIC_API_KEY=sk-ant-xxxxx  # Visible to agent

# CORRECT: Secrets mounted at runtime
volumes:
  - ./secrets:/run/secrets:ro

Mistake 4: Not Using Built-in Sandbox

Claude Code has a built-in sandbox mode:

claude-code --sandbox

# Or configure custom rules
claude-code --sandbox-config ./sandbox-rules.yaml

Summary

In this post, I compared Docker containers and VMs for sandboxing AI agents. The key point is that network configuration matters more than the isolation technology itself. A misconfigured VM is as vulnerable as a misconfigured container.

Docker provides effective sandboxing for AI agents when configured with proper network isolation, offering 10-100x better resource efficiency than VMs. Use Claude Code’s built-in sandbox mode first, then layer Docker with internal: true networking for defense in depth.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit Discussion: Claude Escaped My VM Sandbox

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!