Mọi team mình từng nói chuyện, khi thử để agent tự mở PR trong CI, đều đụng cùng một bức tường sau đúng một tuần: agent cần quyền tự chủ thật sự — cài package, dựng database để chạy integration test, chạy shell command tùy ý — nhưng một GitHub-hosted runner có quyền như vậy cũng đồng nghĩa với việc lộ hết secret của repo, network, và bất cứ thứ gì runner đó với tới được. Bạn hoặc phải khóa agent lại đến mức nó vô dụng, hoặc phải giao runner rồi cầu nguyện. Docker Sandboxes — tích hợp mới cho GitHub Agentic Workflows, ra mắt trong gh-aw CLI extension từ tháng 7/2026 — là câu trả lời đầu tiên ở quy mô mainstream cho vấn đề này, mà không bắt bạn phải chuyển sang một sandbox API của bên thứ ba nào khác.

Mô hình cách ly thực sự

Ý tưởng cốt lõi thì dễ nói nhưng khó làm đúng: mỗi sandbox là một microVM riêng biệt — kernel riêng, filesystem riêng, network stack riêng — chứ không phải container dùng chung kernel. Bên trong microVM đó, agent có một Docker daemon hoàn toàn riêng tư. Đây chính là cách sửa lỗi kinh điển của Docker-in-Docker: thông thường, muốn cho một process trong CI quyền build container thật sự thì phải bật privileged mode hoặc mount Docker socket của host — cả hai đều là đường thẳng dẫn tới chiếm host nếu process đó có vấn đề. Ở đây, agent có quyền root và một Docker daemon đầy đủ bên trong VM, không có đường quay lại daemon hay filesystem của host, ngoại trừ một thư mục workspace được chia sẻ tường minh (chính là checkout của repo bạn).

Network traffic đi qua một proxy phía host, chặn mọi kết nối tới localhost và cloud metadata endpoint (con đường kinh điển SSRF dẫn tới đánh cắp credential), và — phần mình thích nhất — tự động chèn auth header cho các call được phép, để bản thân process của agent không bao giờ cầm token thật. Có ba mức chính sách: Open (cho phép mọi thứ, dùng để thử nghiệm), Balanced (mặc định deny-by-default với allowlist đã được chọn lọc cho AI API, package registry, code host — đây là mặc định hợp lý), và Locked Down (không gì được phép ngoài những gì khai báo tường minh).

Trông như thế nào trong một workflow thực tế

Workflow của gh-aw được viết dưới dạng Markdown kèm YAML frontmatter, sau đó compile ra file .lock.yml chuẩn của Actions. Đây là bản rút gọn của ví dụ Docker đưa ra:

---
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     # đây chính là điểm tích hợp cốt lõi
    sudo: true
tools:
  edit:
  bash: ["*"]
safe-outputs:
  create-pull-request:
    title-prefix: "[docker-sbx sample] "
    draft: true
    protected-files: blocked
    allowed-files:
      - "src/**"
---

Để ý cách mọi thứ được tách bạch. Agent chạy bên trong sandbox với quyền tool và shell rộng — nó có thể thực sự sửa lỗi, chạy test với một Postgres thật qua Testcontainers, làm bất cứ gì task cần. Nhưng việc tạo PR lại diễn ra ở một job safe-outputs riêng, chạy bên ngoài sandbox, dùng GitHub token đã bị giới hạn quyền riêng, bắt buộc draft: true, và chỉ được đụng vào src/**. Agent gần như được làm mọi thứ trong “chuồng” của nó; nhưng nó không được tự quyết cái gì sẽ đề xuất lên nhánh chính hay đụng vào file nào. Đây đúng là ranh giới nên có — thực thi thoải mái, đầu ra thu hẹp.

Ví dụ thực tế của Docker — một service Java 21 kèm integration test dùng Testcontainers, agent tự tìm và sửa lỗi chuẩn hóa email — hoàn tất toàn bộ trong 11 phút 16 giây trên một runner ubuntu-24.04 tiêu chuẩn của GitHub. Không cần hạ tầng đặc biệt gì ngoài extension gh-aw và vài secret (DOCKER_USERNAME, DOCKER_PAT) để pull sandbox template.

Mình sẽ dùng cái này ở đâu — và chỗ nào nên chờ

Nếu team bạn đã chạy workflow CI có agent trên GitHub-hosted runner, đây gần như là một cú đổi “không cần suy nghĩ” cho bất cứ tác vụ nào đụng tới hạ tầng thật (container, database, cài package) thay vì chỉ sửa text thuần. Riêng pattern safe-outputs + draft PR + giới hạn đường dẫn thì đáng học theo dù bạn không dùng Docker Sandboxes cụ thể — đó là hình mẫu đúng cho “cho agent làm rộng, nhưng thu hẹp phần con người phải review.”

Có hai điểm mình muốn cảnh báo trước khi triển khai đại trà. Thứ nhất, tính năng này mới vào gh-aw từ tháng 7/2026 — còn khá mới, và self-hosted runner cần host Linux hỗ trợ KVM mới chạy được lớp microVM, loại trừ luôn một phần không nhỏ các fleet self-hosted thông thường nếu không đầu tư thêm. Thứ hai, Docker chưa công bố benchmark về cold-start hay throughput, và ít nhất một bài viết độc lập đã nêu vấn đề giảm hiệu năng trên project lớn — nên load-test với quy mô repo thật của bạn trước khi tin vào con số thời gian trong demo.

Góc độ governance cũng đáng lưu ý: Docker AI Governance — bán như một lớp riêng — mới là thứ cho bạn chính sách network/tool và audit log ở cấp tổ chức (host nào được gọi, chính sách nào đã kích hoạt) trên nhiều repo. Bản thân sandbox runtime chỉ là kiểm soát cấp từng workflow, chưa phải cấp toàn fleet — nên tính trước khoảng trống này nếu định triển khai vượt ra ngoài vài repo pilot.

Nguồn: Docker Blog — Running AI Agents in GitHub Actions with Docker Sandboxes

Xuất nội dung

Bình luận