Docker vs VM for AI Agent Sandboxing: Which Is Safer?

Mar 12, 2026

Cowrie

Dev @ Bswen

Problem

I recently read a Reddit post that made me reconsider my assumptions about AI agent sandboxing. A user reported that Claude “escaped” their VM sandbox during the first prompt. The culprit? Network bridging misconfiguration that allowed network access despite the VM isolation.

This incident taught me something important: the isolation technology (Docker vs VM) matters less than how I configure it.

I had assumed virtual machines provided inherently stronger isolation than containers. But the Reddit thread revealed that both Docker containers and VMs can fail through the same vulnerability - network misconfiguration. The VM wasn’t compromised through a hypervisor exploit; it failed because network bridging exposed the host.

So I wanted to understand: When should I use Docker vs VMs for sandboxing AI agents like Claude Code? What actually matters for security?

Why Sandboxing AI Agents Matters

AI agents like Claude Code have powerful capabilities:

• File system access (read, write, create, delete)
• Code execution through shell commands
• Network requests (web fetch, API calls)
• Tool invocation that can modify systems

Without sandboxing, an AI agent can access sensitive files like .env files, SSH keys, and credentials. It can exfiltrate data via network requests. It can modify system configurations or execute unintended commands.

The question isn’t whether to sandbox - it’s how to do it effectively.

Docker Container Isolation

Docker containers share the host kernel but provide isolation through several mechanisms:

1. Namespaces - Process, network, mount, and user isolation
2. Cgroups - Resource limits (CPU, memory, I/O)
3. Seccomp - Syscall filtering to block dangerous syscalls
4. AppArmor/SELinux - Mandatory access control
5. Capabilities - Dropping privileged capabilities

Here’s how I configure a hardened Docker container for Claude Code:

Dockerfile.sandbox

FROM python:3.11-slim

# Create non-root user - critical for security
RUN useradd -m -s /bin/bash claude
USER claude
WORKDIR /home/claude/workspace

# The container runs with dropped capabilities
# via docker-compose, not in the Dockerfile

docker-compose.yml

version: '3.8'
services:
  claude-sandbox:
    image: claude-sandbox:latest
    security_opt:
      - no-new-privileges:true
      - seccomp:seccomp-profile.json
      - apparmor:docker-claude
    cap_drop:
      - ALL
    cap_add:
      - CHOWN  # Only add capabilities you absolutely need
    read_only: true
    tmpfs:
      - /tmp:size=100M,mode=1777
    networks:
      - isolated
    environment:
      - CLAUDE_SANDBOX_MODE=strict

networks:
  isolated:
    internal: true  # No external network access - CRITICAL

The internal: true network setting is the most important line here. Without it, the container can reach the internet - and that’s how data escapes.

Docker advantages for AI agent sandboxing:

• Low overhead (shares host kernel)
• Fast startup (seconds)
• Built-in Claude Code sandbox mode compatibility
• Widely documented security practices
• Easy to configure and iterate

Docker disadvantages:

• Kernel-level vulnerabilities affect all containers
• Container breakouts are possible (though rare)
• Network isolation must be explicit
• Requires careful configuration to be secure

Virtual Machine Isolation

VMs provide stronger isolation at the hardware level:

1. Hypervisor isolation - Separate kernel per VM
2. Hardware virtualization - CPU/memory isolation
3. Nested page tables - Memory isolation
4. Virtual network devices - Network isolation

VM advantages:

• Kernel-level isolation (guest OS compromise doesn’t affect host)
• Hardware-enforced boundaries
• Stronger against kernel exploits
• Complete OS independence

VM disadvantages:

• High resource overhead (RAM, CPU, storage)
• Slow startup (minutes vs seconds)
• Complex networking setup
• More attack surface (hypervisor, guest OS)
• Network bridging errors can expose host - exactly what happened in the Reddit case

The Reddit Incident: What Actually Happened

The user’s VM “escape” wasn’t a hypervisor exploit. Claude simply used network access that was accidentally permitted through bridged networking. The VM was properly isolated at the kernel level, but the network configuration created an escape path.

This could happen with Docker too. The Reddit comments reflected this:

• “Not sure why anyone would use a VM to sandbox Claude, it’s totally not worth the overhead. There is an included sandbox mode in Claude Code.”
• “I’m sure a dockerized Claude would have the same ability” - referring to the network escape risk

The consensus: overhead vs security tradeoff favors Docker for most use cases. But both can fail through network misconfiguration.

Common Mistakes I’ve Seen

Mistake 1: Network Misconfiguration

network-config.sh

# WRONG: Bridged networking exposes host network
docker run --network=bridge claude-sandbox

# CORRECT: Internal network with no external access
docker run --network=isolated claude-sandbox

This is exactly what caused the Reddit incident. The network path, not the isolation boundary, was the vulnerability.

Mistake 2: Running as Root

user-config.dockerfile

# WRONG: Running as root gives full power
USER root

# CORRECT: Non-root user limits damage
RUN useradd -m claude && chown -R claude:claude /app
USER claude

Mistake 3: Not Dropping Capabilities

capabilities.yml

# WRONG: Default capabilities include dangerous ones
# (container has CAP_NET_RAW, CAP_SYS_ADMIN, etc.)

# CORRECT: Drop all, add only what's needed
cap_drop: [ALL]
cap_add: [CHOWN]  # Only if absolutely needed

Mistake 4: Allowing Privilege Escalation

privileges.yml

# WRONG: Allows setuid binaries to gain privileges
# (default behavior in Docker)

# CORRECT: Prevent privilege escalation
security_opt:
  - no-new-privileges:true

Mistake 5: Unrestricted Host Mounts

volumes.yml

# WRONG: Full host access - defeats sandboxing
volumes:
  - /:/host

# CORRECT: Specific paths, read-only where possible
volumes:
  - ./workspace:/workspace:ro

Security Comparison

Aspect	Docker Container	Virtual Machine
Kernel Isolation	Shared kernel	Separate kernel
Memory Isolation	Cgroups limits	Hardware-enforced
Startup Time	1-5 seconds	30-120 seconds
Resource Overhead	Low (MB)	High (GB)
Attack Surface	Container runtime + kernel	Hypervisor + guest OS
Breakout Difficulty	Medium	High
Network Isolation	Requires config	Requires config
Claude Code Support	Native sandbox mode	Manual setup

The key insight: both require proper network configuration. Neither is inherently “safer” - both fail when misconfigured.

When I Choose Docker

• Development and testing environments
• CI/CD pipelines
• Multiple isolated agents on one host
• Quick iteration is needed
• Claude Code’s built-in sandbox mode is sufficient

When I Choose VMs

• Production access to sensitive secrets
• Multi-tenant isolation requirements
• Compliance mandates VM-level isolation
• Running untrusted third-party agents
• Maximum security justifies the overhead

My Recommended Approach

For most Claude Code sandboxing, I use Docker with this configuration:

1. Network isolation (--network=internal or custom network with internal: true)
2. Non-root user (never run containers as root)
3. Dropped capabilities (drop ALL, add only what’s needed)
4. Read-only filesystem where possible
5. Resource limits (prevent resource exhaustion)
6. No new privileges (prevent privilege escalation)

The Reddit incident taught me that network configuration is often the real vulnerability, not the isolation technology itself. I focus on getting network isolation right, regardless of whether I use Docker or VMs.

Summary

Neither Docker nor VMs are inherently “safer” - both require proper configuration. The Reddit user’s VM sandbox failed not because VMs are insecure, but because network bridging was misconfigured. The same misconfiguration could affect Docker.

For AI agent sandboxing:

1. Start with Claude Code’s built-in sandbox mode - it’s designed for this
2. Use Docker containers with hardened security profiles for most scenarios
3. Reserve VMs for high-security, multi-tenant, or compliance-driven environments
4. Focus on network isolation - it’s the most common escape vector
5. Test your sandbox before trusting it with sensitive work

The best sandbox is the one I configure correctly and monitor continuously. The technology choice matters less than the implementation details.

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: Claude escaped my VM sandbox
• 👨‍💻 Docker Security Documentation
• 👨‍💻 Claude Code Sandbox Mode
• 👨‍💻 OWASP Container Security

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

Comments

Tags:

• devops
• ai
• ai-coding
• ai-agents
• security

How Does Signing a Message Prevent Tampering? (And Why Encryption Alone Isn't Enough)

Docker vs VM Sandboxing: Why Network Configuration Matters More Than You Think