AI agents that can execute code, browse files, or run shell commands are powerful - and risky. Docker sandboxes let you hand an agent real execution capability without letting it touch anything it shouldn't.
Disposable Containers as Agent Workspaces
When an AI agent needs to run code or interact with a filesystem, the naive approach is to let it run directly on the host. That works until it doesn't - a runaway loop, an unintended file deletion, or a dependency conflict can wreck your environment.
The better pattern is to spin up a fresh Docker container per agent task, give it only what it needs, and throw it away when the task is done. Each container provides an isolated workspace: it has its own filesystem, its own process namespace, and no access to host resources unless you explicitly grant them. The agent runs inside it, does its work, and the container is removed. If something goes wrong, the blast radius is one disposable container, not your machine or your production environment.
This pattern is especially useful for agents that use tool-calling (where the LLM triggers actual function execution) or code interpreter steps - any workflow where the model's output becomes a live command.
Real Example: Spin Up and Tear Down an Agent Sandbox
Here's a minimal pattern using the Docker SDK for Python to create a sandboxed execution environment for an agent task:
import docker
client = docker.from_env()
def run_in_sandbox(code: str) -> str:
container = client.containers.run(
image="python:3.12-slim",
command=["python", "-c", code],
mem_limit="128m",
network_disabled=True,
remove=True, # auto-delete after exit
stdout=True,
stderr=True,
)
return container.decode("utf-8")
output = run_in_sandbox("print(sum(range(100)))")
print(output) # 4950
A few details worth noting: network_disabled=True cuts off outbound calls from inside the container - critical if the agent-generated code might try to exfiltrate data or call external APIs unexpectedly. mem_limit prevents a runaway process from consuming host memory. remove=True means the container is deleted the moment it exits, so you're not accumulating stale containers.
For more complex agent setups (multi-step tasks, file I/O between steps), you can mount a temporary volume for the duration of the task and unmount it afterward, keeping the isolation intact while still allowing artifact passing between agent turns.
Key Takeaways
- Giving AI agents a throwaway Docker container per task limits damage from unexpected or malicious code execution.
- Disabling networking and capping memory are the two most important constraints to set from the start - not as an afterthought.
- This pattern works with most agent frameworks (LangChain, LlamaIndex, custom tool-calling loops) since it wraps execution at the infrastructure layer, not inside the framework itself.
Are you currently running agent-generated code directly on the host, or do you already have an isolation layer in place - and if so, what does it look like?
Sources referenced: HackerNews - Docker Sandboxes discussion (403 points, 258 comments)