# Sandbox không còn là tùy chọn: 4 cách cô lập coding agent an toàn

> Giải pháp cô lập coding agent giúp ngăn chặn thực thi mã độc, triệt tiêu rủi ro leo thang đặc quyền và bảo vệ an toàn tuyệt đối cho hạ tầng.

Nguồn: https://camnangai.com/ung-dung-ai/lap-trinh-vien/co-lap-coding-agent  
Xuất bản: 2026-10-14

Thực thi lệnh shell trực tiếp trên máy chủ cục bộ từ các tự động hóa mã nguồn tạo ra rủi ro hệ thống nghiêm trọng. Một chuỗi lệnh sai lệch hoặc bị can thiệp bởi prompt injection có thể xóa sạch dữ liệu hệ thống hoặc làm rò rỉ hạ tầng.


  Việc **cô lập coding agent** bằng các ranh giới thực thi đa tầng không còn là giải pháp tùy chọn
  mà là yêu cầu kiến trúc bắt buộc để bảo vệ mã nguồn và hạ tầng.


Để agent thực thi lệnh trực tiếp trên terminal khiến môi trường phát triển đối mặt với nguy cơ leo thang đặc quyền. Ngay cả khi áp dụng danh sách lệnh cho phép (whitelisting), các công cụ lập trình vẫn chứa nhiều ranh giới mong manh cho phép thực thi mã tùy ý ngoài tầm kiểm soát khi bạn [tự xây dựng coding agent](https://camnangai.com/ung-dung-ai/lap-trinh-vien/tu-xay-dung-coding-agent).


  Mọi câu lệnh do mô hình sinh ra phải được đẩy vào các ranh giới cô lập có khả năng kiểm soát thiệt
  hại và khôi phục tức thì.


![Các tầng ranh giới cô lập an toàn bảo vệ hệ thống khỏi coding agent](https://camnangai.com/articles/co-lap-coding-agent/01-infographic-vn.webp)

## Vì sao cấp quyền trực tiếp cho coding agent là cái bẫy bảo mật?

Cơ chế kiểm soát dựa trên danh sách lệnh cho phép (whitelisting) hoàn toàn vô hại trước phương thức vận hành của các bộ công cụ lập trình hiện đại. Bạn có thể giới hạn agent chỉ được chạy các lệnh xem chừng an toàn như `go test`, `dotnet test` hay `git commit`, nhưng chính các trình chạy kiểm thử này là con đường dẫn đến thực thi mã tùy ý (arbitrary code execution). Khi cần giải phóng dung lượng đĩa, agent có thể tự khởi tạo một tệp kiểm thử Go chứa đoạn mã `os.RemoveAll(homeDir)` rồi kích hoạt nó chỉ bằng lệnh `go test`. Tương tự, Git cho phép thực thi mã hệ thống thông qua các móc nối (hooks); agent chỉ cần ghi script shell vào `.git/hooks/pre-commit` rồi gọi lệnh `git commit` đã được cấp phép để chiếm toàn bộ quyền truy cập shell trên máy chủ.

![Các vector thực thi ẩn vượt qua danh sách lệnh cho phép của coding agent](https://camnangai.com/articles/co-lap-coding-agent/02-vn.webp)

Các rủi ro leo thang đặc quyền (privilege escalation) còn mở rộng sang hạ tầng kết nối xung quanh. Khi agent vận hành trong một container [Docker](https://camnangai.com/ky-thuat/docker-la-gi) nhưng được gắn (mount) socket gốc `/var/run/docker.sock` để phục vụ kiểm thử dạng Docker-in-Docker, nó có quyền quản trị root hoàn toàn trên máy host và dễ dàng khởi tạo container mới với đặc quyền cao nhất. Nếu bạn cấp cho agent quyền truy cập vào cơ sở dữ liệu staging với đặc quyền superuser, nó có thể thực thi câu lệnh SQL dạng `COPY PROGRAM` để gọi các lệnh hệ thống như `curl` tải payload từ máy chủ bên ngoài.

Bên cạnh nguy cơ can thiệp hệ thống, tiến trình thực thi của agent còn đối mặt với rủi ro rò rỉ chứng thư qua tệp nhật ký (log). Khi ứng dụng gặp sự cố hoặc khi agent tự động thực hiện các lệnh chẩn đoán (`printenv`, đọc tệp `.env`), các sự cố unhandled process crashes và verbose stack traces sẽ ghi lại các biến môi trường nhạy cảm như `AWS_SECRET_ACCESS_KEY` hay `GITHUB_TOKEN` vào stdout/stderr. Các chuỗi nhật ký này sau đó được truyền ngược về các endpoint LLM bên ngoài để phục vụ kiểm toán hoặc duy trì cửa sổ ngữ cảnh (context window), biến tập tệp nhật ký thành mục tiêu tấn công giá trị cao.

Về mặt kiến trúc, giải pháp triệt để là tách biệt giữa "Bộ não" (Brain) và "Đôi tay" (Hands) trong kỷ luật [harness engineering](https://camnangai.com/ung-dung-ai/lap-trinh-vien/harness-engineering). "Brain" là vòng lặp điều khiển dài hạn (control loop) đảm nhận việc duy trì bộ nhớ, ngữ cảnh và gọi API mô hình. "Hands" là không gian thực thi câu lệnh `bash -c` không đáng tin cậy. Vòng lặp control loop có thể vận hành trên máy tính cá nhân hoặc VPS, nhưng môi trường thực thi lệnh shell bắt buộc phải nằm trong một ranh giới cô lập cấp kernel (kernel-level boundary) riêng biệt, có thể bị tiêu hủy hoặc khôi phục bất kỳ lúc nào mà không ảnh hưởng đến trạng thái agent.

## Cách 1: Cô lập cấp hệ điều hành với Bubblewrap và Seatbelt

Cô lập ở cấp hệ điều hành tận dụng các nguyên mẫu bảo mật tích hợp sẵn trong nhân kernel để giới hạn phạm vi hoạt động của lệnh shell. Trên macOS, cơ chế này dựa vào khung làm việc Seatbelt. Trên Linux và WSL2, hệ thống kết hợp `bubblewrap` (`bwrap`) để cô lập hệ thống tệp, `socat` để điều hướng mạng và bộ lọc `seccomp` nhằm chặn các cuộc gọi hệ thống nhạy cảm như Unix domain sockets.

![Ranh giới cô lập cấp hệ điều hành và cơ chế proxy che giấu token bí mật](https://camnangai.com/articles/co-lap-coding-agent/03-vn.webp)

Tuy nhiên, việc triển khai trên Linux tồn tại các trường hợp biên quan trọng. Trên Ubuntu 24.04 trở lên, chính sách AppArmor mặc định ngăn chặn `bubblewrap` tạo unprivileged user namespaces (`sysctl kernel.apparmor_restrict_unprivileged_userns` trả về 1), yêu cầu quản trị viên phải cấu hình AppArmor riêng cho `/usr/bin/bwrap`. Nếu thiếu bộ lọc `seccomp`, các tiến trình bên trong WSL2 có thể thao tác với Unix domain socket tại `/mnt/c/` để kích hoạt các tệp nhị phân Windows nằm ngoài ranh giới cô lập.

Về mặt kiểm soát hệ thống tệp, tầng **cô lập coding agent** này chỉ cho phép ghi vào thư mục làm việc hiện tại và thư mục tạm thời (`$TMPDIR`). Toàn bộ các đường dẫn nhạy cảm khác đều bị áp đặt quy tắc cấm đọc/ghi ở cấp độ OS, bao gồm tệp cấu hình `.claude`, tệp khởi động shell (`.bashrc`, `.zshrc`), `.gitconfig`, cũng như thư mục `.git/hooks/`. Về mạng, các tiến trình trong Linux chạy trong một network namespace riêng biệt không có tuyến đường trực tiếp ra internet. Trên macOS, Seatbelt chặn mọi kết nối ngoại trừ lưu lượng được điều hướng qua một local proxy giám sát các tên miền cho phép (`allowedDomains`).

Cần lưu ý rằng Seatbelt trên macOS mặc định chặn các lưu lượng phi-HTTP như kết nối TCP trực tiếp tới cơ sở dữ liệu hoặc SSH. Đồng thời, các công cụ CLI viết bằng Go (`gh`, `gcloud`, `terraform`) thường gặp lỗi xác thực TLS dưới cơ chế của Seatbelt trừ khi được bổ sung vào danh sách loại trừ (`excludedCommands`) hoặc thiết lập proxy CA tùy chỉnh.

```json
{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws/credentials"],
      "allowRead": ["."],
      "allowWrite": ["/tmp/build"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}
```

## Cách 2: Container dùng một lần với Docker và OCI Sandboxes

Phương pháp cô lập bằng container sử dụng các môi trường container tạm thời (ephemeral container environment) nhằm loại bỏ nguy cơ tác động trực tiếp lên máy chủ. Trong các nền tảng như Docker Sandboxes hay Cloud Sandboxes, agent vận hành bên trong các microVM chạy container chuyên dụng có nhân kernel và Docker daemon hoàn toàn độc lập. Kiến trúc này mang lại khả năng thực thi Docker-in-Docker nội bộ an toàn mà không cần gắn socket gốc `/var/run/docker.sock` của máy host.

Mô hình này tối ưu hóa luồng làm việc kết hợp (hybrid workflow) cho lập trình viên. Bạn có thể tương tác với agent trên máy tính cá nhân để tinh chỉnh mã nguồn. Khi phát sinh các tác vụ kéo dài nhiều giờ như refactor toàn bộ dự án hay chạy chuỗi kiểm thử lớn, bạn chỉ cần thực hiện lệnh CLI (`sbx move my-project --to cloud`) để đồng bộ hóa overlay filesystem và process state sang hạ tầng đám mây. Bạn có thể đóng laptop, ngắt kết nối trong khi agent vẫn tiếp tục vận hành trên các microVM luôn hoạt động (always-on).

Vấn đề quản lý chứng thư được giải quyết thông qua TLS-terminating identity proxy. Các khóa API không bao giờ lưu trữ cố định trên đĩa của container. Thay vào đó, proxy dịch vụ sẽ tự động chèn credential vào từng yêu cầu HTTP outbound dựa trên tên miền được cấp phép. Ngoài ra, việc tích hợp [Giao thức Ngữ cảnh Mô hình (MCP)](https://camnangai.com/kien-thuc-ai/mcp-la-gi) Enterprise Gateway cho phép các container kết nối an toàn với các dịch vụ doanh nghiệp (Jira, Linear, Grafana, incident.io) qua các streamable HTTP endpoints dưới sự kiểm soát và quản trị tập trung.

## Cách 3: MicroVM ảo hóa phần cứng với Firecracker và Sprites

Ảo hóa phần cứng mức MicroVM (sử dụng Firecracker và KVM/libvirt) cung cấp ranh giới cô lập cấp kernel (kernel-level boundary) mạnh mẽ hơn container truyền thống. Bằng cách cấp cho mỗi phiên làm việc một kernel Linux riêng biệt, rủi ro tấn công leo thang đặc quyền qua các lỗ hổng của nhân hệ điều hành dùng chung bị xóa bỏ. Mọi hành vi can thiệp hệ thống từ agent đều bị triệt tiêu hoàn toàn bên trong ranh giới của MicroVM đó.

![Kiến trúc điểm kiểm soát CoW và khôi phục hệ thống tức thì trên MicroVM](https://camnangai.com/articles/co-lap-coding-agent/04-vn.webp)

Trái ngược với các container không trạng thái (stateless) bị tiêu hủy sau mỗi lần chạy, các kiến trúc sandbox trạng thái như Fly.io Sprites biến môi trường cô lập thành những máy tính đám mây bền vững. Mỗi Sprite sử dụng bộ lưu trữ NVMe gắn trực tiếp với tốc độ truy xuất cao, đồng thời tự động đồng bộ bất đồng bộ dữ liệu về bộ nhớ đối tượng (object storage) bền vững hỗ trợ lệnh TRIM. Cơ chế scale-to-zero billing tự động đưa MicroVM vào trạng thái ngủ sau 30 giây không hoạt động giúp giảm chi phí hạ tầng về mức tối thiểu.

Lợi thế đáng giá của kiến trúc này là cơ chế điểm kiểm soát (checkpoint) dựa trên công nghệ Copy-on-Write (CoW). Hệ thống có thể tạo một điểm kiểm soát toàn bộ trạng thái đĩa chỉ trong ~300ms. Nếu agent thực thi các câu lệnh phá hoại làm sụp đổ hệ thống (như xóa sạch `/root/app` hoặc các tệp nhị phân `/usr/bin/git`), hệ thống chỉ mất khoảng 9 giây để thực hiện rollback toàn bộ filesystem và bộ công cụ về đúng trạng thái nguyên bản. Về bảo mật chứng thư, các công cụ như `flyctl` chèn token xác thực động vào môi trường thực thi của từng lệnh đơn lẻ và xóa ngay khi lệnh hoàn tất, đảm bảo không có khóa mật mã nào tồn tại ở trạng thái nghỉ trên đĩa.

```bash
# Tạo điểm kiểm soát toàn bộ trạng thái đĩa trước khi chạy lệnh không tin cậy
sprite-env checkpoints create

# Khôi phục trạng thái hệ thống tệp trong ~300ms sau sự cố hỏng hóc
sprite-env checkpoints restore v1
```

## Cách 4: Nền tảng cloud sandbox chuyên dụng cho agent (E2B, Daytona)

Đối với các hệ thống vận hành swarm agent quy mô lớn, các nền tảng đám mây đa người dùng chuyên dụng như E2B hay Daytona cung cấp hạ tầng được tối ưu hóa cho tải công việc AI. E2B triển khai mô hình cô lập doanh nghiệp dựa trên các MicroVM Firecracker riêng biệt cho từng sandbox với cam kết không chia sẻ kernel hay bộ nhớ giữa các khách hàng, đáp ứng tiêu chuẩn SOC 2 Type II và HIPAA BAA. Cơ chế Bring Your Own Cloud (BYOC) cho phép triển khai đệm dữ liệu trực tiếp trong VPC (AWS, GCP, Azure) của khách hàng, phân tách rõ ràng giữa control plane (chỉ nhận cuộc gọi TLS và chỉ số telemetry ẩn danh) và data plane (chạy sandbox, lưu đĩa snapshot, log hoàn toàn trong VPC nội bộ).

![Phân tách Control Plane và Data Plane trong kiến trúc cloud sandbox doanh nghiệp](https://camnangai.com/articles/co-lap-coding-agent/05-vn.webp)

Ở khía cạnh mật độ tính toán và hiệu năng khởi chạy, thử nghiệm hạ tầng của Daytona trên phần cứng thế hệ mới cho thấy sự cách biệt rõ rệt về mật độ lõi CPU và băng thông bộ nhớ. Chip NVIDIA Vera có khả năng khởi tạo 1.000 sandbox cô lập chỉ trong 10.8 giây và 2.000 sandbox trong 27.4 giây. Trong khi đó, các dòng chip x86 như AMD EPYC 9575F mất 32.3 giây và EPYC 9755 mất 88.4 giây chỉ để khởi tạo 1.000 sandbox. Ngay cả khi tải hệ thống chạm mốc 2.000 sandbox hoạt động song song, hạ tầng dựa trên Vera vẫn duy trì ngưỡng thông lượng peak ở mức 13.3 tác vụ agent hoàn tất mỗi giây.

Các nền tảng đám mây này chuẩn hóa khả năng giao tiếp thông qua Model Context Protocol (MCP). Mọi công cụ tích hợp qua MCP đều được gán nhãn chú thích an toàn (safety annotations): phân định ranh giới rõ ràng giữa các thao tác chỉ đọc (read-only) và các thao tác có tính phá hủy hoặc thực thi hệ thống (`exec`, `service_start`), giúp hệ thống quản trị áp đặt chính sách phê duyệt tự động chính xác.

## Nên chọn tầng cô lập nào cho hệ thống agent của bạn?

Việc lựa chọn tầng cô lập đòi hỏi cân bằng giữa tốc độ khởi tạo, khả năng lưu trữ trạng thái, độ bền vững của ranh giới bảo mật và mật độ hạ tầng. Đối với công việc phát triển cá nhân trên máy cục bộ, giải pháp cô lập cấp OS đáp ứng tốt tốc độ và tài nguyên. Khi chuyển sang các hệ thống chạy tự động kéo dài, các mô hình đào tạo Reinforcement Learning (RL) hoặc hạ tầng phục vụ nhiều người dùng, việc nâng cấp lên Container, MicroVM hoặc Cloud Sandbox chuyên dụng là bắt buộc.

Bảng dưới đây hệ thống hóa các thông số kiến trúc giúp bạn lựa chọn giải pháp phù hợp:

| Tầng cô lập                   | Công nghệ cốt lõi                 | Mức độ bảo mật                        | Trường hợp sử dụng tối ưu                                              |
| :---------------------------- | :-------------------------------- | :------------------------------------ | :--------------------------------------------------------------------- |
| **Cấp hệ điều hành**          | Bubblewrap, Seatbelt, Local Proxy | Trung bình (Chung Kernel với Host)    | Phát triển local cá nhân, lệnh CLI ngắn, yêu cầu nhẹ.                  |
| **Container cách ly**         | Docker, OCI, Cloud Sandboxes      | Khá (Cô lập không gian tên & cgroups) | Chạy tác vụ dài hạn, luồng làm việc chuyển dịch Laptop-Cloud.          |
| **MicroVM ảo hóa**            | Firecracker, KVM, Sprites         | Cao (Kernel riêng biệt per session)   | Cho phép Agent tự do thử nghiệm, rollback khi hỏng hóc, lưu trữ state. |
| **Cloud Sandbox chuyên dụng** | E2B, Daytona (Vera/EPYC)          | Rất cao (Tách biệt VPC/Enterprise)    | Chạy swarm agent quy mô lớn, hạ tầng RL, yêu cầu tuân thủ SOC2/HIPAA.  |

## Tài liệu tham khảo

- [Why sandboxing coding agents is harder than you think — Martin Alderson](https://martinalderson.com/posts/why-sandboxing-coding-agents-is-harder-than-you-think/)
- [Configure the sandboxed Bash tool — Claude Code Docs](https://code.claude.com/docs/en/sandboxing)
- [Fly's new Sprites.dev addresses both developer sandboxes and API sandboxes at the same time — Simon Willison](https://simonwillison.net/2026/Jan/9/sprites-dev/)
- [Building Agents that Don't Break Themselves — The Fly Blog](https://fly.io/blog/building-agents-that-dont-break-themselves/)
- [Your Agent Speaks MCP. Give It a Computer — The Fly Blog](https://fly.io/blog/sprites-mcp/)
- [Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud — Docker](https://www.docker.com/blog/introducing-cloud-sandboxes-start-on-your-laptop-finish-in-the-cloud/)
- [Security — E2B: The AI Agent Cloud](https://e2b.dev/security)
- [When 2,000 Agents Share One CPU — Daytona](https://www.daytona.io/dotfiles/when-2000-agents-share-one-cpu)