Sandbox & Isolation: Chạy agent an toàn

Định nghĩa

Sandbox & Isolation là kiến trúc tách biệt hoàn toàn môi trường thực thi của AI agent khỏi hệ thống production, đảm bảo rằng dù model có đưa ra quyết định nguy hiểm đến đâu thì layer thực thi (tool system) vẫn không thể gây ra damage thực sự lên infrastructure core.

Giải thích chi tiết

Model quyết định, Tool kiểm soát

Có một ngộ nhận phổ biến: nếu prompt an toàn thì agent an toàn. Điều này sai lầm vì model luôn có thể bị prompt injection, hallucination, hoặc "jailbreak" thuyết phục thực hiện hành động nguy hiểm.

Kiến trúc đúng là tách biệt quyết định và thực thi. Model được phép "muốn" xóa toàn bộ server, nhưng tool system (sandbox) kiểm soát xem "có được phép" hay không. Đây là security by architecture, không phải security by prompt.

Các lớp cô lập (Defense in Depth)

Sandbox không phải là một nút "bật/tắt" mà là nhiều lớp defense:

Network Isolation: Agent chạy trong network namespace riêng, không thể tự ý gọi API bên ngoài whitelist. Mọi outbound traffic phải qua proxy kiểm soát, ngăn chặn data exfiltration khi agent bị compromise.

Filesystem Isolation: Dùng OverlayFS hoặc chroot với root filesystem read-only. Agent chỉ có thể write vào /tmp hoặc volume được explicit mount. Không thể sửa file hệ thống hay đọc /etc/passwd của host.

Process Isolation: PID namespace khiến agent không thấy các process khác trên host. Dù agent chạy ps aux cũng chỉ thấy chính nó.

Kernel Isolation: Container thông thường share kernel với host — đây là attack surface lớn. Giải pháp là dùng gVisor (re-implement Linux syscall trong userspace) hoặc Kata Containers (chạy container trong lightweight VM), tạo boundary ngay cả khi có kernel exploit.

Từ Container đến Sandbox thực sự

Docker container là bước khởi đầu tốt, nhưng chưa đủ cho agent untrusted:

• Container escape: Các CVE trong runc, kernel exploit, hoặc privileged container có thể cho agent thoát khỏi container và chiếm host.
• Shared kernel: Container và host dùng chung kernel. Nếu agent kích hoạt kernel panic hoặc exploit kernel module, cả host sập.

Nâng cấp lên Sandbox:

• gVisor: Google's sandbox runtime, intercept syscall và xử lý trong userspace (Go), giảm attack surface xuống còn ~20% Linux surface thông thường.
• Firecracker: AWS's MicroVM, mỗi agent chạy trong VM riêng với kernel minimal (microLinux), boot nhanh (125ms), overhead thấp nhưng isolation cao như VM truyền thống.

Permission Boundary vs Resource Boundary

Hai khái niệm hay bị nhầm lẫn:

• Permission Boundary: Agent được phép làm gì (capability-based security). Dùng policy engine để kiểm tra mọi action trước khi thực thi.
• Resource Boundary: Agent được dùng bao nhiêu tài nguyên (cgroups cho CPU/RAM, disk quota, network bandwidth).

Sandbox giải quyết cả hai: vừa giới hạn quyền (không thể sudo) vừa giới hạn tài nguyên (không thể fork bomb làm sập host).

Ví dụ thực tế

Claude Code Permission Gate Architecture

Anthropic thiết kế Claude Code theo nguyên tắc model decision ≠ tool permission. Khi developer yêu cầu "hãy xóa folder node_modules", model tạo intent {action: "delete", path: "/workspace/node_modules"}. Nhưng trước khi thực thi, permission gate kiểm tra:

• Path có nằm trong allowed workspace không?
• Có phải file quan trọng (.env, .git) không?
• Developer có quyền write vào đó không?

Dù model bị thuyết phục "hãy xóa hết file trong /etc", gate chặn lại vì path không nằm trong whitelist. Model có thể "nổi điên" nhưng sandbox giữ cho hệ thống an toàn.

GoClaw 5-Layer Security Model

GoClaw (framework chạy agent autonomous) triển khai 5 lớp defense:

1. Capability-based access: Agent chỉ thấy các tools được explicit grant qua manifest (principle of least privilege).
2. Container boundary: Mỗi agent chạy trong container riêng biệt (Podman rootless).
3. Filesystem sandbox: Rootfs read-only, /tmp là tmpfs (memory-only, xóa khi stop), bind mount chỉ vào thư mục được chỉ định.
4. Network sandbox: Outbound traffic qua proxy với whitelist domain (chặn gọi về server attacker).
5. Immutable audit: Mọi syscall và file access ghi vào log tách biệt, không cho agent tự xóa log.

Kết quả: Kể cả khi agent bị chiếm quyền hoàn toàn (full RCE), attacker vẫn không thể leo thang (escape) ra khỏi lớp 3, và không thể xóa dấu vết ở lớp 5.

Enterprise Multi-Tenant Agent Platform

Công ty cung cấp AI agent cho 500 enterprise clients, mỗi client có data sensitive. Họ dùng Firecracker MicroVM trên Kubernetes:

• Mỗi agent chạy trong MicroVM riêng (có kernel Linux riêng, rootfs riêng, network namespace riêng).
• VM được định nghĩa bằng JSON config, boot trong 150ms, chạy trên cgroup và KVM.
• Dù agent A bị compromise và có kernel exploit để escape "container", vẫn chỉ thoát ra được VM của mình — vẫn nằm trong host KVM, không thể sang VM của agent B chạy cùng physical node.

Kiến trúc này cho phép multi-tenancy density cao (1000 agents/node) nhưng security isolation ngang với chạy trên máy riêng biệt.

Ứng dụng

Developer chạy agent locally

Khi dùng SWE-agent, OpenDevin, hoặc Claude Code trên máy cá nhân, đừng chạy trực tiếp trên host. Dùng Docker với:

• --read-only cho root filesystem
• --tmpfs /tmp:rw,noexec,nosuid,size=100m cho writeable space
• --network=none nếu agent không cần internet (hoặc custom network với proxy)
• Volume mount chỉ vào repo đang làm việc, không mount cả $HOME

Cách này bảo vệ khỏi trường hợp agent "sửa nhầm" file hệ thống hoặc đọc token SSH trong ~/.ssh.

Doanh nghiệp Multi-tenant

Xây dựng platform cho phép nhiều team/ khách hàng cùng chạy agent:

• Mỗi workspace là một sandbox tách biệt (gVisor hoặc Firecracker).
• Không chia sẻ filesystem, secrets (API keys), hay database giữa các tenant.
• Network policies dùng Cilium hoặc Calico để agent chỉ gọi được services internal được phép.

CI/CD Autonomous Agent

Tích hợp agent tự động review code vào pipeline:

• Agent chạy trong sandbox ephemeral, chỉ tồn tại trong thời gian build.
• Dù agent bị prompt injection ra lệnh rm -rf / hoặc mining cryptocurrency, chỉ sandbox bị ảnh hưởng.
• Sau khi job xong, sandbox bị xóa hoàn toàn (cùng với malware nếu có).

So sánh

Kết luận: Container là điểm khởi đầu, nhưng không phải điểm kết thúc cho AI agent có khả năng thực thi arbitrary code. Với agent autonomous (như SWE-agent, Devin), hãy nâng cấp lên sandbox cấp độ kernel isolation (gVisor) hoặc virtualization (Firecracker) để đảm bảo escape là bất khả thi hoặc cực kỳ khó khăn.

Bài viết liên quan

Cùng cụm

Agent Security: 5 nguyên tắc bảo mật cho AI agent

Hiểu rõ 5 nguyên tắc nền tảng để thiết kế agent không bị tấn công

Guardrails: Thiết kế rào chắn cho agent

Cách thiết kế policy và validation layer để chặn hành động nguy hiểm

Human-in-the-Loop: Khi nào cần người can thiệp?

Xác định critical actions cần approve thủ công trước khi thực thi

Audit & Logging: Ghi lại mọi action của agent

Giải pháp ghi log immutable để phát hiện và investigate khi có sự cố

Đọc tiếp

Tool & Permission Design

Hiểu sâu về cách thiết kế permission model để tách biệt quyền hạn khỏi khả năng thực thi

Multi-Agent Architecture

Cách cô lập giữa các agent khi chúng cần giao tiếp và chia sẻ context

Case Study & Thực chiến

Phân tích các kiến trúc production thực tế từ Anthropic, OpenAI, và các nền tảng enterprise