Container Isolation¶

Docker and container technologies provide namespace-based isolation with minimal overhead. Containers share the host kernel but restrict what processes can see and do.

Docker for Agent Isolation¶

Containers isolate through Linux kernel features:

Mechanism	Function
Namespaces	Separate filesystem, PIDs, network, users
cgroups	Limit CPU, memory, disk I/O
seccomp	Filter allowed system calls
Capabilities	Restrict root privileges

An agent running in a container sees its own filesystem root, process table, and network stack. It's isolated from the host and other containers.

Shared Kernel¶

Containers don't run their own kernel:

┌────────────────────────────────────────┐
│              Host Kernel                │
├──────────────┬──────────────┬──────────┤
│ Container A  │ Container B  │ Host     │
│ (Agent 1)    │ (Agent 2)    │ Process  │
└──────────────┴──────────────┴──────────┘

Milliseconds to start (no kernel boot)
Low memory overhead since the kernel isn't duplicated
But kernel exploits can affect all containers on a host

Container escapes exist. They're patched, but the attack surface remains. For trusted development workloads, this risk is fine.

Basic Docker Isolation¶

Running an agent with minimal exposure:

docker run --rm -it \
  --network none \
  --memory 4g \
  --cpus 2 \
  --read-only \
  --tmpfs /tmp \
  -v $(pwd):/workspace:rw \
  -w /workspace \
  ubuntu:latest \
  bash

The container has no network access, memory and CPU limits, a read-only root filesystem, and only the project directory is writable.

Docker Sandboxes¶

Docker's purpose-built isolation for AI agents extends the container model:

# Create isolated workspace
docker sandbox run myagent

# Agent operates in isolated environment
# Changes mirror back to host directory

Key features: automatic mirroring of local directories into the sandbox, native support for Claude Code and Gemini CLI, and simplified setup without manual volume mounts or network configuration. Docker built this for agent isolation needs.

Security Hardening¶

Beyond basic resource limits, containers can be hardened:

Seccomp Profiles¶

Restrict system calls to a safe subset:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "names": ["read", "write", "open", "close", "stat", "fstat"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

AppArmor/SELinux¶

Mandatory access control beyond discretionary permissions:

docker run --security-opt apparmor=docker-default ...

No New Privileges¶

Prevent privilege escalation:

docker run --security-opt no-new-privileges ...

Container Use Cases¶

Scenario	Container Appropriate?
Local development with trusted code	Yes
CI/CD with controlled inputs	Yes
Internal tools, known codebase	Yes

Can you accept the (small but nonzero) risk of container escape? For developer machines running trusted code, it usually works.