Containers and Dev Environments

Make the blast radius small

The strongest practical guardrail is where the agent runs. In a container, dev container or VM you can mount only the project folder, run as a non-root user, keep your home directory, SSH keys and cloud credentials out, drop capabilities and set CPU and memory limits. Even if the agent is fully tricked, it can only damage a disposable environment. Remember a container is a strong boundary but not a perfect one, so keep it updated and avoid privileged mode.

A locked-down container

Only the project is mounted; the root filesystem is read-only; no extra Linux capabilities; limited memory and processes. Adjust to your toolchain; the image name is a placeholder.

docker run --rm -it \
  --user 1000:1000 \
  --read-only --tmpfs /tmp \
  --cap-drop ALL --security-opt no-new-privileges \
  --memory 2g --pids-limit 256 \
  -v "$PWD":/workspace -w /workspace \
  my-agent-image:latest

Never mount the Docker socket or your home

Mounting /var/run/docker.sock gives the agent control of the host, and mounting ~ exposes SSH keys and tokens. Mount only the project, and mount it read-only where the agent need not write.

Quick check: What should be mounted into the agent's container?

• Only the project folder
• The whole home directory
• The Docker socket
• Your SSH key folder