Every team I’ve talked to that’s tried letting an agent open its own PRs in CI has hit the same wall within a week: the agent needs real autonomy — install a package, spin up a database for integration tests, run arbitrary shell commands — but a GitHub-hosted runner with that much freedom also has the full blast radius of your repo secrets, your network, and whatever else is reachable from that box. You either lock the agent down until it’s useless, or you give it a runner and hope. Docker’s new Sandboxes integration for GitHub Agentic Workflows, shipped in the gh-aw CLI extension in July 2026, is the first mainstream answer to that problem that doesn’t require you to adopt a third-party sandbox API.

The actual isolation model

The core idea is simple to state and annoyingly hard to build correctly: each sandbox is a dedicated microVM — its own kernel, its own filesystem, its own network stack — not a shared-kernel container. Inside that microVM, the agent gets a completely private Docker daemon. That’s the specific fix for the classic Docker-in-Docker trap: normally, giving a process in CI real container-build capability means either privileged mode or mounting the host’s Docker socket, both of which are a straight line to host compromise if the process misbehaves. Here, the agent gets root and a full Docker daemon inside the VM, with zero path back to the host daemon or filesystem except an explicit, shared workspace directory (your repo checkout).

Network access goes through a host-side proxy that intercepts all sandbox traffic, blocks calls to localhost and cloud metadata endpoints (the classic SSRF-to-credential-theft path), and — this is the part I like — auto-injects auth headers for allowed outbound calls, so the agent process itself never actually holds the raw token. There are three policy tiers: Open (everything allowed, for prototyping), Balanced (deny-by-default with curated allowlists for AI APIs, package registries, and code hosts — this is the sane default), and Locked Down (nothing except explicit entries).

What it looks like in a real workflow

gh-aw workflows are authored as Markdown with YAML frontmatter, then compiled into a standard Actions .lock.yml. Here’s a trimmed version of the pattern Docker documented:

---
name: "sandbox-explorer"
on:
  workflow_dispatch:
runs-on: ubuntu-24.04
permissions:
  contents: read
  copilot-requests: write
engine: copilot
network:
  allowed:
    - defaults
    - github
    - containers
    - java
sandbox:
  agent:
    id: awf
    runtime: docker-sbx     # this is the whole integration point
    sudo: true
tools:
  edit:
  bash: ["*"]
safe-outputs:
  create-pull-request:
    title-prefix: "[docker-sbx sample] "
    draft: true
    protected-files: blocked
    allowed-files:
      - "src/**"
---

Notice what’s split apart here. The agent runs inside the sandbox with broad tool and shell access — it can genuinely fix things, run tests against a real Testcontainers Postgres instance, whatever the task needs. But PR creation happens in a separate safe-outputs job, running outside the sandbox, with its own scoped-down GitHub token, forced to draft: true, and restricted to touching src/**. The agent can do almost anything inside its box; it cannot decide, unsupervised, what gets proposed to your main branch or which files that touches. That’s the right boundary — permissive execution, narrow output.

Docker’s worked example — a Java 21 service with a Testcontainers-backed integration test, agent finds and fixes an email-normalization bug — completed end to end in 11 minutes 16 seconds on a stock ubuntu-24.04 GitHub-hosted runner. No special infrastructure required beyond the gh-aw extension and a couple of secrets (DOCKER_USERNAME, DOCKER_PAT) for pulling the sandbox template.

Where I’d actually use this — and where I’d wait

If your team is already running agent-driven CI workflows on GitHub-hosted runners, this is close to a no-brainer swap for anything that touches real infrastructure (containers, databases, package installs) rather than pure text edits. The safe-outputs + draft-PR + path-restriction pattern is honestly worth stealing even if you don’t use Docker Sandboxes specifically — it’s the right shape for “let the agent work broadly, but narrow what humans have to review.”

Two things I’d flag before rolling this out fleet-wide. First, this landed in gh-aw in July 2026 — it’s new, and self-hosted runners need KVM-capable Linux hosts to run the microVM layer at all, which rules out a chunk of typical self-hosted fleets without extra work. Second, Docker hasn’t published cold-start or throughput benchmarks, and at least one independent write-up flagged performance degradation on larger projects as an open question — worth load-testing against your actual repo size before you trust the timing numbers in a demo repo.

The governance angle matters too: Docker AI Governance, sold as a separate layer, is what gives you org-wide network/tool policy and audit logging (which client hostnames got called, which policy decisions fired) across repos. The base sandbox runtime alone is a per-workflow control, not a fleet-wide one — plan for that gap if you’re rolling this out past a handful of pilot repos.

Source: Docker Blog — Running AI Agents in GitHub Actions with Docker Sandboxes