Docker stress-tests container sandboxes
- Docker’s new Sandboxes documentation and blog posts lay out how its AI coding-agent environments isolate untrusted code inside micro virtual machines, instead of ordinary containers that share a host kernel. - The key design choice is a host-side proxy that injects API credentials into outbound requests, while blocking raw TCP, UDP and ICMP and keeping secret values outside the sandbox. - Docker is pitching the setup as a safer way to let agents run Docker, install packages and edit code locally, as companies look for guardrails around autonomous coding tools. (docker.com)
A container is like an apartment in a shared building: it has its own space, but it still depends on the same kernel underneath. Docker says its Sandboxes move AI coding agents into micro virtual machines, each with its own kernel. (docker.com 1) (docker.com 2) Docker’s docs say the primary trust boundary is that microVM, not the process permissions inside it. The agent can have sudo access inside the VM, while the host stays separated by the hypervisor boundary. (docker.com 1) (docker.com 2) That matters because ordinary containers share the host kernel, while Docker says each sandbox gets a separate Linux kernel and separate processes. The company says sandboxes also cannot reach the host filesystem outside the shared workspace, the host Docker daemon, or other sandboxes. (docker.com 1) (docker.com 2) Secrets are handled through a host-side proxy instead of being dropped into the sandbox as environment variables. Docker says the proxy intercepts outbound HTTP and HTTPS requests, adds authentication headers, and keeps the raw credential values on the host. (docker.com) (docker.com) Docker recommends stored secrets in the operating system keychain over shell environment variables, which it says are visible to other processes running as the same user. Its supported service list includes Anthropic, OpenAI, GitHub, Google, xAI and Amazon Web Services Bedrock endpoints. (docker.com) The network model is also narrow by default. Docker says all outbound traffic goes through an HTTP or HTTPS proxy, only allowed domains are reachable, and raw TCP, UDP, ICMP and direct DNS queries are blocked. (docker.com) (docker.com) For developers, the trade-off is convenience versus containment. Docker says the sandbox can still edit the shared workspace in real time, including files like Git hooks, CI configs, Makefiles and package scripts that may execute later on the host. (docker.com) (docker.com) The product is aimed at people who want agents to do more than autocomplete code. Docker says sandboxes can install packages, build images, run Docker Compose and keep their own Docker images and container state until the user deletes the sandbox with `sbx rm`. (docker.com) (docker.com) Docker’s pitch is that this gives autonomous agents “full Docker capabilities” without handing them the host machine. The company is also exposing live CPU, memory and outbound connection logs in its `sbx` dashboard so users can watch what those agents do. (docker.com) (docker.com) The bottom line is not that the agent is harmless inside the sandbox. Docker’s own docs say the VM protects the host, but any file or network access you explicitly share still needs review before you run what the agent changed. (docker.com)
