# Containers and Dev Environments — AI Coding-Agent Guardrails

Source: https://www.geekswithgeeks.com/en/coding-agent-guardrails/fs-containers

> Run the agent in a container or VM with only the project mounted.

## 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.

```bash
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.

**Quiz:** What should be mounted into the agent's container?

- [x] Only the project folder
- [ ] The whole home directory
- [ ] The Docker socket
- [ ] Your SSH key folder

*Answer:* Only the project folder. Exposing only the project keeps credentials and unrelated files out of reach.