AI agents become much more useful when they can execute code, install packages, browse the web, and manipulate files. Those same abilities turn every generated command into a security boundary.
TencentCloud/CubeSandbox is an Apache-2.0 sandbox service designed for that boundary. It launches lightweight KVM microVMs with dedicated guest kernels, exposes E2B-compatible APIs, and adds cluster scheduling, network isolation, controlled egress, snapshots, templates, and a browser-based operations console.
The project aims to combine the startup speed and density associated with containers with stronger hardware-backed isolation. Its published bare-metal benchmarks report sub-60ms cold starts at single concurrency and less than 5MB of base overhead for sandbox specifications up to 32GB, with higher latency under concurrent creation. Those are useful design signals, not universal guarantees: hardware, deployment mode, templates, storage, and load all affect results.
What CubeSandbox Provides
CubeSandbox is a self-hosted execution platform for agents that need disposable or stateful compute. Its main capabilities include:
- KVM microVMs built with RustVMM components
- a high-concurrency REST API with E2B SDK compatibility
- single-node and multi-node deployment
- OCI-image-to-template workflows and a Template Store
- web management for nodes, templates, sandboxes, logs, and version health
- AutoPause and AutoResume for idle instances
- CubeCoW snapshots, cloning, and rollback
- eBPF-based per-sandbox network isolation
- domain allowlists, credential injection, and egress audit logs
- x86_64 KVM deployment paths plus newer ARM64 support described by the project
E2B compatibility is a migration aid, but the roadmap still lists remaining compatibility gaps. Validate the exact SDK methods and lifecycle semantics your application depends on before treating it as a universal drop-in replacement.
The Control and Data Path
An agent talks to CubeAPI, the Rust REST gateway. CubeMaster holds cluster state and schedules the request to a compute node. On that node, Cubelet manages the sandbox lifecycle, while CubeHypervisor and CubeShim connect KVM microVM management with the containerd Shim v2 interface.
CubeProxy routes E2B-compatible traffic to the right sandbox. CubeVS, an eBPF virtual switch, enforces kernel-level network policy. CubeEgress, built around OpenResty, adds application-layer domain filtering, credential injection, and auditing.
This separation matters because “run this code” is not one operation. It is admission, placement, boot, network setup, process execution, observation, and cleanup—each with distinct failure and security modes.
Why MicroVM Isolation Matters
Containers normally share the host kernel. Namespaces, capabilities, seccomp, and mandatory access controls can create strong boundaries, but kernel exposure remains shared. CubeSandbox gives each sandbox its own guest kernel inside a KVM microVM, reducing direct reliance on the host kernel for untrusted workloads.
Hardware virtualization is not a complete security program. Template provenance, hypervisor vulnerabilities, host configuration, API authentication, secrets, network policy, logging, patch cadence, and tenant cleanup still matter. The right claim is stronger isolation architecture—not “unbreakable code execution.”
Network and Credential Controls
Agent code often needs external APIs, but placing long-lived credentials inside a sandbox exposes them to generated code, prompt injection, logs, and filesystem snapshots.
CubeEgress addresses this by keeping credentials in a vault and injecting them at the outbound proxy. Domain allowlists constrain destinations, CubeVS policies make proxy bypass harder, and audit logs record access. Version 0.5 also adds per-sandbox traffic tokens and policy-routing hardening.
Operators must still protect the vault, define narrow allowlists, rotate keys, authenticate management APIs, and test DNS and alternate-protocol bypass paths. Egress control is only effective when every outbound route is covered.
Snapshots, Clones, and Agent Branching
CubeCoW provides copy-on-write checkpoints for running sandboxes. A workflow can save a known state, experiment, roll back after failure, or clone the state into parallel branches.
This maps naturally to AI-agent workloads: reproducible evaluation environments, reinforcement-learning rollouts, parallel solution attempts, browser sessions, and long-running assistants. AutoPause/AutoResume complements snapshots by suspending idle sandboxes and waking them on the next request.
Stateful features create governance questions too. Snapshots may contain source code, tokens, generated artifacts, or personal data. Retention, encryption, deletion, access control, and auditability should be designed before large-scale use.
Performance Claims in Context
The project reports an average cold start below 60ms on bare metal at single concurrency and under 5MB of base memory overhead for tested sandbox sizes up to 32GB. Its concurrency note reports an average of 67ms, P95 of 90ms, and P99 of 137ms for 50 concurrent creations.
These figures are impressive, but benchmark context matters. Cloud virtualization, nested KVM, storage, image preparation, network setup, host contention, guest size, and warm caches can change results. Reproduce tests on the intended infrastructure using the same templates, concurrency, and lifecycle operations as production.
Deployment Paths and First Run
The current documentation presents bare metal as the recommended path, a PVM path for ordinary cloud VMs, Terraform-based cluster deployment, and a QEMU development environment for evaluation when KVM is unavailable. The quick-start path still emphasizes Linux with KVM support; confirm architecture-specific requirements for ARM64 deployments.
After installation, the web console is available at:
http://<control-node-ip>:12088
The recommended sequence is to verify node capacity, install or build a READY template, then create a sandbox and inspect its live logs. Production deployments should add TLS, authentication, restricted administrative access, monitoring, backups for control-plane state, and upgrade testing.
Where CubeSandbox Fits
CubeSandbox is relevant for coding agents, browser automation, data-analysis sandboxes, evaluation harnesses, RL environments, digital assistants, and any system executing untrusted generated code at high concurrency.
It is less compelling when a hardened container is already sufficient, hardware virtualization is unavailable, or a fully managed service is preferred. Teams should compare operational complexity as carefully as startup speed.
The roadmap includes Kubernetes-native operation, persistent/shared volumes, cross-node resume, deeper E2B compatibility, control/data-plane separation, fault recovery, and richer scheduling. Those items should be treated as future direction until delivered and validated.
Final Take
CubeSandbox combines a thoughtful set of primitives for agent execution: microVM isolation, fast templates, cluster scheduling, network policy, out-of-sandbox credential injection, snapshots, and familiar SDK access.
Its most important contribution is architectural. Safe agent execution is not just a container-launch problem; it is a lifecycle and policy system. CubeSandbox makes those layers explicit, while leaving operators responsible for validating performance, hardening the deployment, and matching controls to the threat model.
