Docker Sandboxes can now provide the runtime for agents in GitHub Agentic Workflows. An agent receives a shell, administrative rights and a private Docker daemon inside a disposable microVM, while the host runner, network and GitHub outputs remain constrained.
The short answer
| Component | Role |
|---|---|
| GitHub Actions | Schedules the job, supplies permissions and stores logs. |
gh-aw | Compiles a Markdown task into a conventional Actions workflow. |
| Docker Sandbox | Runs the agent in a microVM with a private kernel and Docker daemon. |
| Safe outputs | Allows only selected file changes or pull-request operations. |
Integration has shipped in gh-aw since version 0.82.9. A self-hosted runner needs KVM and appropriate system access.
Why one container may not be enough
A useful coding agent installs packages, executes project code, starts databases and chooses shell commands dynamically. Mounting the host Docker socket often gives that agent extensive control over the runner.
Docker Sandboxes puts a private Docker daemon inside a microVM. The agent can use Testcontainers and launch containers without controlling the host daemon. The shared repository workspace remains the explicit bridge.
Broad privileges inside, narrow access outside
The model separates concerns: sudo and unrestricted shell access in the sandbox, but allowlisted network destinations, minimal GitHub permissions and restricted files on output. A fix can produce only a draft pull request touching src/**.
That boundary is stronger than repeated human confirmations. Operators eventually approve commands they cannot fully audit. A microVM limits damage from a mistake, but it does not prove that the resulting patch is correct or benign.
Secrets remain sensitive
A secret injected into the sandbox is available to the process working there. Use job-specific, short-lived credentials limited to one repository and unable to deploy directly to production. Block unnecessary network destinations to reduce exfiltration paths.
Pin actions and images used by the agent. A disposable environment does not fix supply-chain risk when a compromised dependency is deliberately given the workflow token.
Adopt it progressively
Start with a low-risk task: adding a test, diagnosing a failure or proposing documentation. Require a draft pull request, human review and the normal test suite. Observe commands, traffic and cost before granting more autonomy.
On self-hosted runners, also verify hardware isolation, shared-workspace cleanup and concurrent jobs. The microVM protects its own boundary, not a weak configuration around it.
Docker Sandboxes gives CI agents a credible boundary by granting freedom inside a disposable environment. Final security still depends on allowed network access, injected secrets and the outputs a workflow may publish.
Join the discussion
Comments
Loading comments…