Containers Were Step One — Agent Sandboxes Are Step Two
A few weeks ago I wrote about the container-only philosophy — the idea that your host machine should stay clean and everything should run inside containers. Development tools, databases, runtimes — all of it.
That post was about developers running software.
But something has changed. The thing running your software is increasingly not a developer at all. It’s an AI agent.
And agents need sandboxes even more than developers do.
Why Agents Can’t Just Run on Your Machine
When a developer runs rm -rf node_modules they know what they’re doing. When an AI agent runs it, it’s because a language model predicted that sequence of tokens was likely to be helpful.
That’s a fundamentally different trust model.
Developers operate with intent. Agents operate with probabilistic confidence. They are correct most of the time and catastrophically wrong occasionally. The gap between “usually right” and “always right” is exactly where sandboxing becomes non-negotiable.
Consider what a modern AI coding agent actually does:
- Reads and writes files on your filesystem
- Executes shell commands
- Installs packages
- Makes network requests
- Spawns subprocesses
Now imagine that agent hallucinating a curl command that pipes to bash. Or deciding that a “clean build” requires deleting your home directory. These aren’t hypothetical scenarios — they’re failure modes that have already happened.
Container Patterns Map Directly to Agent Execution
The principles that make containers work for development environments apply perfectly to AI agent execution:
Immutability
Containers start from a known image. Every run is identical. For agents, this means every task starts from a clean, predictable state. No accumulated garbage from previous runs. No mystery state that makes one execution behave differently from the next.
Isolation
A container can’t reach the host filesystem unless you explicitly mount volumes. An agent running inside a container can’t accidentally delete your SSH keys, read your .env files, or modify system configurations. The blast radius of any mistake is bounded by the container boundary.
Resource Limits
Containers support CPU limits, memory limits, and network policies. An agent that enters an infinite loop burns through its allocated 2GB of RAM and gets killed — instead of consuming your entire machine and crashing everything else.
Disposability
When an agent finishes a task, you destroy the container. No cleanup required. No lingering processes. No orphaned temp files. The environment simply ceases to exist.
This is not theoretical. This is how you should be running agents right now.
What’s Actually Happening in Practice
The industry is converging on this model, even if the terminology isn’t unified yet.
OpenAI’s Codex runs agent tasks in sandboxed cloud containers. Each task gets a fresh environment with the repository cloned in, network access disabled by default, and a strict timeout. The agent can install packages, run tests, write code — all inside a disposable box.
Anthropic’s Claude Code takes a different approach with local execution but includes a permission system that acts as a software-level sandbox. Commands are classified as safe or dangerous, and the dangerous ones require explicit approval.
OpenClaw (which I run on my own Mac Mini) executes agent tasks with configurable isolation — from full container sandboxes to permission-controlled local execution depending on the trust level of the task.
Daytona, E2B, and similar platforms provide cloud-based development sandboxes specifically designed for AI agents. Spin up an environment, let the agent work, destroy it when done.
The pattern is the same everywhere: give the agent an environment it can’t escape from.
What’s Still Missing
Despite the progress, the current state of agent sandboxing has real gaps.
No Standard for Agent Environment Specifications
We have Dockerfile and docker-compose.yml for defining development environments. There is no equivalent standard for defining what an agent needs. What tools should be available? What network access is required? What files should be mounted? Every platform invents its own format.
State Persistence Is Awkward
Agents often need to maintain state across tasks. A coding agent that learns your project’s conventions should remember them. But if the sandbox is destroyed after every task, where does that knowledge live? We need a clean pattern for separating ephemeral execution state from persistent agent memory — and it doesn’t exist yet.
Networking Policies Are Too Binary
Most agent sandboxes either allow full network access or none at all. But agents often need something in between: access to npm install but not to arbitrary URLs. Access to your internal API but not to the public internet. Fine-grained network policies for agent containers are still immature.
GPU Access Complicates Everything
For agents that need local inference (running models on your own hardware), GPU passthrough into containers adds significant complexity. NVIDIA Container Toolkit exists, but the developer experience is far from the simplicity of a regular docker run.
The Container-Only Philosophy, Extended
If the original container-only philosophy says:
If a tool is needed, run it in a container. Do not install it.
The extended version for the agent era says:
If an AI agent needs to execute anything, it executes inside a sandbox. No exceptions.
This isn’t about distrusting AI. It’s about applying the same engineering discipline we already use for every other untrusted workload.
We don’t run third-party code without isolation. We don’t deploy applications without resource limits. We don’t give CI/CD pipelines unrestricted access to production systems.
Why would we give an AI agent — which is, at its core, a probabilistic system executing arbitrary code — anything less?
The Practical Setup
For engineers who want to start running agents in containers today, the setup is simpler than you might think.
A basic pattern:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
services:
agent:
image: node:20
working_dir: /workspace
volumes:
- ./project:/workspace
mem_limit: 4g
cpus: 2.0
network_mode: none
security_opt:
- no-new-privileges:true
read_only: true
tmpfs:
- /tmp:size=1g
This gives the agent:
- A clean Node runtime
- Access to the project files
- 4GB RAM, 2 CPUs
- No network access
- No privilege escalation
- A read-only root filesystem with a writable
/tmp
The agent can read your code, write to temp, and execute within strict bounds. It cannot install global packages, modify the runtime, or phone home.
Obviously this is a starting point. Real agent workloads need more nuance. But the default should always be restrictive, with explicit openings for what the agent actually needs.
Where This Is Heading
Containers gave us a universal primitive for running software reproducibly.
Agent sandboxes will give us the same for running AI workers safely.
The technology is mostly there. The missing piece is convention. We need an agent.yml that describes the execution environment, the permission model, and the resource limits — the way Dockerfile describes a build and docker-compose.yml describes infrastructure.
Whoever builds that standard wins.
Because every engineering team deploying AI agents is about to face the exact same question:
How do I let this thing work without letting it break everything?
Containers already answered that question once.
Now we just need to apply the answer to the next generation of workers.