Originally published on NextFuture
Agent của bạn vừa tự chạy một script mà không ai kiểm tra kỹ, và nó có quyền đọc file .env, gọi API production, thậm chí xoá dữ liệu. Nếu agent chạy trực tiếp trên máy hoặc server của bạn, một lệnh sai — do agent tự sinh ra hoặc do prompt injection từ một trang web nó đọc — có thể biến trợ lý AI thành một vụ rò rỉ dữ liệu thật. Bài này so sánh 4 cách cô lập agent bằng sandbox — Docker, E2B, Modal, Fly Machines — để bạn chọn đúng công cụ cho use case của mình.
Vì sao agent cần sandbox, không phải venv
Mọi framework agent nghiêm túc — từ AutoGPT, CrewAI đến LangGraph — sớm muộn cũng cần thực thi code: viết script, chạy, đọc output, quyết định bước tiếp theo. Thực thi code nghĩa là có shell access, và shell access nghĩa là agent làm được bất cứ điều gì tài khoản đó làm được. Bài viết gốc kể lại hai sự cố (theo lời tác giả, chưa kiểm chứng độc lập): một agent scraping web vô tình DDoS một trang đích vì retry liên tục trong vòng lặp; một agent khác làm theo chỉ dẫn giấu trong trang web nó đọc — không phải từ người vận hành — và chạy lệnh exfiltrate biến môi trường chứa API key.
Một venv chỉ cô lập package Python, không cô lập hệ thống. Docker container thông thường cô lập process nhưng vẫn tồn tại lâu dài, có network access, và tích luỹ state. Sandbox thì khác: ephemeral, cô lập, hạn chế theo mặc định.
Docker Sandbox làm được gì
Theo mô tả của Docker, mỗi task của agent được cấp một container riêng, ephemeral, với bốn đặc điểm chính: không có quyền đọc filesystem của host (agent không đọc được SSH key, file .env, hay config database của bạn); không có network access theo mặc định — bạn phải whitelist rõ host/port muốn cho phép; giới hạn resource — CPU, memory, và execution time đều bị cap, nên agent kẹt trong vòng lặp vô hạn không ăn hết tài nguyên server; và cleanup tự động — khi task xong hoặc timeout, container bị destroy, không còn process hay state sót lại.
Docker vs E2B vs Modal vs Fly Machines
Công cụCách hoạt độngĐiểm khác biệt
Docker SandboxContainer ephemeral tích hợp sẵn trong DockerKhông cần thêm vendor mới, dùng luôn tool đã có trong stack
E2B (e2b.dev)Sandboxed code execution dạng servicePre-warm container sẵn, giảm cold-start latency
ModalContainer ephemeral, tối ưu cho serverlessTập trung vào workload serverless execution
Fly MachinesVM boot nhanhGần với một VM thật hơn là một container nhẹ
Docker sandbox khởi động "cold" mỗi lần, còn E2B pre-warm container trước — đây là đánh đổi latency đáng cân nhắc nếu agent của bạn cần phản hồi tức thời cho người dùng cuối.
Đánh đổi cần biết trước khi triển khai
Cold start: mỗi sandbox cần boot, cài dependency, khởi động runtime — thêm latency so với chạy code trực tiếp.
State management: sandbox ephemeral nên mọi state agent tạo ra mất khi container bị destroy — cần persist ra S3, database, hoặc volume nếu muốn giữ lại.
Monitoring khó hơn: không SSH vào container sau khi xong được, phải log hành vi agent trước khi container biến mất.
Chi phí: chạy hàng trăm container ephemeral có resource cost thật, cộng dồn nhanh ở hệ thống throughput cao.
Bắt đầu từ đâu
Nếu bạn đang chạy nhiều agent cùng lúc hoặc để agent tự thực thi code không giám sát, việc cần làm trước tiên là audit xem agent hiện tại đang có network access và filesystem access nào. Sau đó chọn một trong bốn công cụ trên theo mức latency và chi phí bạn chấp nhận được — công cụ cụ thể ít quan trọng hơn nguyên tắc: agent nên chạy trong môi trường cô lập, ephemeral, và bị giới hạn resource. Thiếu điều đó, bạn không có một trợ lý AI mạnh — bạn có một sự cố an ninh đang chờ xảy ra.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)