aisystemsagentssecuritydocker
Why I Give My AI Agents a Hardware-Isolated Sandbox
If you let an autonomous agent run shell commands, it needs a cage. Here's how I built a reproducible, hardware-isolated harness for agent research - and why a flaky Raspberry Pi pushed me to do it right.
3 min read
An autonomous agent that can run tcpdump, tshark, and arbitrary shell commands is exactly as dangerous as any other program that can run arbitrary shell commands. When I started letting agents do forensic work on their own for my research, the first real engineering problem wasn't the AI - it was containment.
The problem with "just run it"
My research needs agents to independently analyze packet captures and event logs - which means real tools, real filesystem access, real network utilities. Running that on my actual machine is a bad idea. Running it in a plain Docker container is better, but shares the host kernel. For an agent that might do anything, I wanted a stronger boundary.
Apple container: one VM per container
I moved the harness onto Apple's container tooling, which gives each container its own lightweight, hardware-isolated VM rather than a shared kernel. The agent gets a full Linux environment with all its tools, but it physically cannot touch the host. Crucially, the whole thing is captured as a standard Dockerfile, so it's portable and reproducible - anyone can rebuild the exact environment.
The bridge: no handholding
The interesting design constraint was making the agent genuinely autonomous. I built a deterministic tool-calling bridge: an open-source agent drives its own loop against a small OpenAI-compatible server that wraps a headless model. The model reasons the next step in plain words (RUN: <cmd> / FINAL: <answer>), and a regex in the bridge turns that into a real command - no second model, no GPU, no task hints baked in. The bridge only gives the agent the model and formats its output. Everything else, the agent decides.
Why the Raspberry Pi had to go
The first version ran on a Raspberry Pi. It kept killing long runs - resource exhaustion, thermal throttling, the occasional mid-run auto-update that broke the runtime. Debugging those failures taught me more about the runtime than the happy path ever did, but reproducibility was impossible on hardware that behaved differently every run. Moving to a committed Dockerfile + isolated VM made every run identical.
The payoff
Once containment and reproducibility were solid, I could actually measure things. Hand the agent two files (a pcap and a foreign event log) and one line - "co-source them" - and it decides and does everything itself. That only became a trustworthy experiment because the environment underneath it was boring, isolated, and identical every time.
If you're building agent harnesses, spend your first week on containment and reproducibility. The intelligence is the easy part to iterate on; the cage is what makes the iteration mean anything.