Is Docker enough isolation for an AI agent with shell access?
Docker helps package an agent, but it is not automatically enough isolation when the agent has shell access and you care about blast radius across projects or clients.
Containers share a kernel and often share a host. Misconfiguration, privileged mounts, or a breakout path matter more when the workload can run arbitrary shell commands. “It runs in Docker” answers packaging. It does not always answer “can this agent touch another project’s files or secrets?”
What people usually mean by isolation
For AI agents with shell access, buyers typically want:
- Separate filesystems and processes per project or client.
- Credentials and connectors scoped so one agent cannot use another’s keys.
- A clear machine boundary, not only a container label on a shared host.
Docker can be part of a safe setup. Alone, on a shared machine with loose mounts and shared env files, it often is not.
Isolation that matches agent risk
Agents with shell access can install tools, read paths, and call APIs. The safer default for many teams is one isolated cloud machine (or box) per project, with a known runtime snapshot, rather than many agents sharing one host “because Docker.”
How Cloudrun fits
Cloudrun deploys each AI agent to its own isolated cloud machine, with a single fleet canvas. Isolation is at the machine and project boundary: each project gets its own box and baked runtime snapshot. That is a stronger default than packing every client agent into containers on one shared host.
That model matters for agencies and multi-project fleets. See How do agencies host separate AI agents per client without shared blast radius?.
Related
Pillar: Deploy an AI agent to an isolated cloud machine.
Next step
Run agents on isolated cloud machines at usecloudrun.com.