GitHub's agent runner now has a trapdoor: Docker Sandboxes as a supported runtime

In July 2026, GitHub Agentic Workflows added Docker Sandboxes as a supported agent runtime, which means an AI coding agent in CI can hold sudo and start its own containers while the environment around it is an isolated microVM with a network policy and secrets injection ^[1]. Isolation advice for agents has been circulating for a while; this is the first version of it that a platform team configures rather than builds, and Docker says the integration works with no custom action configuration ^[2][11].

The division of labour is worth being precise about. GitHub Actions is still the CI system: it schedules the job, provides the Ubuntu runner, manages permissions and secrets, and records the result ^[3]. GitHub Agentic Workflows, or gh-aw, is an open-source GitHub CLI extension and compiler; you write a Markdown file whose YAML frontmatter holds execution configuration and whose body holds the agent's task, and `gh aw compile` turns it into a conventional Actions workflow with a `.lock.yml` suffix ^[4]. The `docker-sbx` runtime is part of gh-aw's agent runtime configuration, `runs-on` is still `ubuntu-24.04`, and the compiled workflow installs the sandbox tooling, authenticates it, checks the runner, starts the agent in the sandbox, and cleans up afterwards ^[5]. That integration shipped in gh-aw 0.82.9 ^[6].

The word "Docker" invites the assumption that the boundary is one application container. It is not. According to Docker's post, each sandbox is a dedicated environment with its own kernel, filesystem and network stack, and its own private Docker daemon, so the agent gets full root inside the VM without gaining control of the host's daemon ^[7]. The only bridge between the two is the explicit shared workspace of the repository ^[8]. The private daemon is the load-bearing part for testing: in Docker's sample the application runs Testcontainers the same way a developer would locally ^[9].

Outside the sandbox, the sample keeps the surface small. The `network` block allowlists only `defaults`, `github`, `containers` and `java`; the agent's token carries `contents: read` and `copilot-requests: write`; and pull request creation happens in a separate safe-output job that produces a draft PR whose patch may touch files only under `src/**`, with protected files blocked ^[12][13]. Inside, the three lines under `sandbox.agent` select the runtime and grant `sudo: true` plus unrestricted bash ^[10]. The demo itself is modest and honest about being a demo: the agent runs on a GitHub-hosted Ubuntu runner, enters the sandbox, runs a Java integration suite against PostgreSQL via Testcontainers, finds an intentionally seeded bug, fixes it, and opens a draft pull request ^[11].

Two things to watch. First, the microVM removes the runner's blast radius, not the repository's; what the agent can actually change is whatever the safe-output job is permitted to write, which in this sample is `src/**` and nothing else ^[13]. Teams copying the pattern should treat `allowed-files` and the network allowlist as the real policy, not the sandbox flag. Second, the evidence is currently one vendor's blog post about its own product, and it does not report sandbox startup overhead, minutes consumed, or cost ^[14]. MicroVM boot time and image pull time land on the same Actions bill as everything else, so the numbers matter before this becomes a default for every agentic job. Pin gh-aw to a known version while the runtime settles ^[6].