I read Anthropic's and OpenAI's agent devcontainers line by line. Here's what both leave open.

I run four agents at once on separate branches and worktrees and stopped reading every diff months ago. That only works if something other than my attention is holding the line, that is why I started to add security features to my dev containers.

It started with Anthropic's dev container. Its firewall lets DNS out to any server. So does OpenAI's, and their README says so plainly. Neither stops an agent shipping your keys out through a DNS query.

The detail, Anthropic's first. Line 29 allows UDP 53 to any server. Line 33 allows TCP 22 to any host. The allowlist rule on 117 has no port match, so it's any port on an allowed IP.

OpenAI's secure profile is better. Actual IPv6 default-deny, verified at startup, no SSH hole. DNS is still open though, UDP and TCP, lines 78 and 79. To their credit the README just says it:

The firewall does not apply its domain allowlist to DNS traffic, so code from an untrusted repository can exfiltrate data through DNS.

That never connects to the attacker. A resolver you're allowed to use walks the chain and hands it over. iptables sees a normal query to an approved resolver and lets it through.

Docker's sbx is the one that's actually a product: KVM microVM, its own kernel, a gVisor userspace netstack, rules that are per host and per port and secret injection. Stronger boundary than anything I've built, no argument. Needs a Docker account though, and on a fresh personal account with no org it told me my policy was "managed by unknown organization" and wouldn't create a sandbox at all. Can't debug, because it's closed source.

As an open alternative I devloped o3s, it merges security and rapid development: Firewall lives in a separate container. The workspace has no way out except through it. DNS goes to a dnsmasq on that gateway with no catch-all upstream, just the domains I listed, so anything else gets refused instead of forwarded. Those same lookups drop the resolved IPs into ipsets, which is what keeps it working when a CDN moves.

That secret line is the bit I use most. Key stays on the gateway, container gets a placeholder, gateway swaps in the real token on the way out for that host only.

Half of this isn't security though, and that's the half I actually notice day to day. Every repo and worktree in one workspace file, four agents on four branches, one source-control view for all of it. Rootless Docker and minikube inside so an agent can bring the whole stack up and wreck it. Everything installed is a devcontainer feature, so it's a list you edit rather than an image you're stuck with.

I also had the threat model wrong at first. I assumed the agent could just flush the firewall itself. It can't, sudo is scoped to that one script and a non-root process doesn't hold NET_ADMIN. So the problem was never escape, it's that the policy allows too much.

It won't stop exfiltration to a host you allowlisted, obviously. Push to your own GitHub repo and it's gone. And a container is a weaker boundary than a VM, so if you're running properly hostile code, go use sbx.