Docker Sandboxes – Disposable, isolated sandboxes for AI agents

Original Article ↗ Hacker News Discussion ↗

Docker’s new Sandboxes feature aims to run AI coding agents inside disposable microVMs with outbound firewalls and credential-injection, so untrusted tools can’t freely access a developer’s machine or secrets. Commenters welcome stronger isolation than traditional containers but heavily criticize the mandatory Docker login, closed-source tooling, and limited Linux support, arguing it undermines trust and long-term viability. Many point to a growing ecosystem of open-source VM- and container-based sandboxes, with some preferring to “vibecode” their own solutions tailored to specific workflows and threat models.

What Docker Sandboxes Actually Are

  • Multiple commenters clarify this is not a regular Docker container setup.
  • Each agent/session runs in a microVM (libkrun-style, own kernel) on the host hypervisor (Hypervisor.framework, WHP, KVM).
  • Provides stronger isolation than plain containers and allows the agent to run Docker inside the sandbox without compromising the host.

Security Model: VMs vs Containers vs OS Sandboxes

  • Many argue untrusted AI agents should not share a kernel with the host; VMs/microVMs are preferred over cgroups-based containers.
  • Others counter that unprivileged containers are “good enough” for most developers, and escapes are mostly about 0‑days and bad configs.
  • Some use layered defenses: VM + containers inside + outbound firewalls + limited mounts.
  • There’s active discussion around bubblewrap, nono, gVisor, libkrun, Kata Containers, Incus/LXC, Flatpak, etc., as alternative sandboxing primitives.

Login Requirement, Closed Source, and Governance

  • The mandatory Docker login for a local dev tool is widely disliked.
  • Some see it as a “garbage” UX and fear future paywalls/limits or rug pulls.
  • There’s an enterprise “AI Governance” product for centrally enforcing sandbox policies.

Credentials Injection & Network Controls

  • Credential injection at the proxy boundary (secrets stored in host keychain, injected only for matching hostnames/headers) is seen as a standout feature.
  • Debate on how robust this is against clever exfiltration attempts; some worry about ways to reflect secrets back to the agent.
  • Outbound firewalling / deny-by-default network policies are valued; some alternatives implement similar controls.

Linux Support & Platform Gaps

  • Confusion and frustration over Linux support: marketing page initially omitted it, docs and release artifacts indicate Ubuntu and some RPM-based distros are supported.
  • Some complain it’s not broadly available on all Linux distributions or architectures.

DIY and Open Source Alternatives

  • Huge number of users have built their own sandboxes (QEMU/KVM, Firecracker-like microVMs, Incus, devcontainers, bubblewrap, Apple Container, Tart, podman+libkrun, etc.).
  • Many link to OSS projects offering microVM-based agents, credential proxies, outbound firewalls, or better DX.
  • Several say they prefer investing in open, self-controlled setups rather than a proprietary, login-gated tool.