I read Anthropic's and OpenAI's agent devcontainers line by line. Here's what both leave open.
Heat trend
Collecting trend data
The percentage is based on available heat signal, not comment count or independent people.
A developer analyzed Anthropic's and OpenAI's agent devcontainers, highlighting potential security vulnerabilities. The analysis revealed that Anthropic's devcontainer allows UDP 53 and TCP 22 to any server or host, respectively. Additionally, a rule on line 117 permits any port on an allowed IP. The developer, who uses multiple agents simultaneously, emphasized the need for security features in dev containers to manage these risks, prompting a discussion among other agent users.
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.