Agent sandboxing
Somewhere safe for coding agents to work
I run a fleet of coding agents against my own production systems every day. That's taught me what they need: a place to run with no credentials, a short list of things they can reach, and a way to measure whether they did the job. I build the same for other teams.
What I build
- Ephemeral runner pods: offline, credential-free, deleted after each run, with a deadline.
- Egress allowlists, so the package mirror is reachable and the open internet isn't.
- FIFO leases, so one writer touches a shared resource at a time.
- Production changes only through GitOps. Agents open merge requests; nothing applies changes by hand.
- One typed wait per condition instead of polling.
- A Kubernetes operator for agent benchmarks.
Most of it is the boundary you'd draw for a new contractor on day one. The difference is that an agent works around the clock and retries a blocked call without getting bored.
Where I've done it
My benchmark operator has stored 38,150 attempts across 4,752 model-and-task cells, with infrastructure failures counted separately from the agent's own mistakes.
The rules I run my own fleet by are written up in three posts: how I fence the agents, why they wait instead of polling and why re-reviews read only the delta.
Case studies and write-ups
Questions people ask
Which agents?
I've benchmarked two harnesses (OMP and Factory's Droid) across models from several vendors.
Does Docker-in-Docker mean privileged pods?
In my benchmark cluster it does: the sidecar runs privileged so task environments can use Docker Compose, and those jobs run on their own nodes. If that's not acceptable, gVisor or Kata Containers are the usual next step.
Do agents get production credentials?
Not in the sandbox. Credentials stay behind a broker, and changes reach production through reviewed merge requests.
Get in touch
If something here sounds like your problem, send me a few lines about what you're running.