Source: Docker — 2026-08-21
Summary
Docker shipped support for running AI coding agents directly inside GitHub Actions using Docker Sandboxes — isolated microVMs that give an agent full freedom to install tools, run containers, and execute code, while keeping the surrounding CI job's credentials and network access locked down. Instead of trusting a coding agent with the same GitHub token and network access as the rest of the workflow, the agent runs inside a disposable microVM with its own kernel and private Docker daemon; only a separately gated "safe-output" job is allowed to turn its work into an actual pull request.
Key Takeaways
- Each sandbox is a full microVM — its own kernel, filesystem, and network stack — not a shared-kernel container, so an agent can build and run its own containers without mounting the host's Docker socket.
- A host-side network proxy intercepts the sandbox's traffic, blocks access to the CI runner's own localhost, and auto-injects auth headers, instead of handing the agent raw network credentials.
- The workflow narrows access outside the sandbox to just what the job needs: an allowlisted set of network destinations, and a GitHub token scoped to read the repo and talk to Copilot — nothing more.
- Pull-request creation isn't done by the agent itself; it happens in a separate, gated "safe-output" job that only accepts a patch touching an allowlisted path (e.g.,
src/**), so a compromised or misbehaving agent can't push arbitrary changes. - This targets a real gap in agentic CI: an agent given a shell in a normal GitHub Actions runner effectively has the same blast radius as the pipeline itself — this design gives the agent the freedom it needs locally while keeping the pipeline's trust boundary intact.
Reel Script
Hook: Give a coding agent a shell inside your CI pipeline, and it inherits the same GitHub token and network access as your entire build. Docker just shipped a way to run that agent in CI without handing it the keys to everything else.
Core Concept: The core problem is a mismatch of trust. A CI job's GitHub token can push code, and its network access can reach your infrastructure — that's fine when the job is a fixed script you wrote, but risky when the job is an autonomous agent deciding what to run next. Docker's fix is to run the agent inside a microVM — think of it as a full miniature computer, with its own operating system kernel, that boots in seconds and then disappears. Because it has its own kernel instead of sharing the host's, the agent can install tools and run its own containers inside the sandbox — full freedom in there — while everything outside stays locked to a narrow, pre-approved surface.
Hands-On: The architecture splits into three trust zones. Inside the sandbox: the agent has root, its own Docker daemon, and can do essentially whatever it wants — run Testcontainers-based tests, try fixes, install packages. At the sandbox's edge: a network proxy on the host intercepts every outbound call, blocks the runner's own localhost so the agent can't reach back into the pipeline's internals, and injects authentication tokens itself rather than giving the agent raw credentials to hold. Outside the sandbox: the GitHub token available to the job is scoped down to reading the repo and talking to Copilot, and turning the agent's changes into a real pull request happens in a completely separate job, gated to only accept a patch that touches specifically allowlisted file paths. The agent never gets to open its own PR directly.
Takeaway: If you're letting a coding agent run unattended in CI today, the honest question is what it can touch if it goes wrong — and "the same token as the rest of the pipeline" is the wrong answer. This pattern (freedom inside a disposable microVM, a narrow proxy-mediated exit, and PR creation as a separately gated step) is worth copying even if you're not on Docker's stack specifically.