If your AI agent can write code, it can write bad code. If it can call tools, it can call the wrong tool with the wrong arguments. The fix is not a smarter prompt. It’s an isolation boundary between the model’s output and the machine that runs it. CubeSandbox is one of the systems built for exactly that boundary, and it’s worth understanding what it does, how it compares to other approaches, and where it fits when your agents start touching real APIs and real data.
TL;DR
CubeSandbox is an open-source, hardware-isolated sandbox service from Tencent Cloud for running AI agent code. Each sandbox gets its own guest OS kernel via KVM, starts in about 60ms, and uses under 5MB of memory overhead. It’s Apache 2.0 licensed and is drop-in compatible with the E2B SDK.
Introduction
Agentic systems are now writing and executing code in production. A coding agent generates a Python script and runs it. A research agent scrapes a page, parses it, and pipes the result into another step. A data agent loads a CSV and runs transformations the model decided on at runtime. None of that code was reviewed by a human before it ran. That is the core problem agent sandboxing solves: you need to execute untrusted, model-generated instructions without giving them your host, your filesystem, your credentials, or your network.
This matters more as agents get autonomy. A model that’s wrong about a SQL query is annoying. A model that’s wrong about rm -rf or that follows an injected instruction inside a scraped web page is a security incident. Sandboxing draws a hard line: the agent can do whatever it wants inside a disposable, isolated environment, and nothing it does leaks out.
There’s a second, quieter problem. Agents don’t just run code; they call APIs and tools. Before you trust an agent to hit your payment API or your internal services from inside a sandbox, you need to know those APIs behave correctly and that the agent calls them the way you expect. That’s where API tooling earns its place next to runtime isolation. A platform like Apidog lets you mock and test the endpoints an agent will call, so you validate the contract before an autonomous system starts driving it in a sandboxed run. If you’re already thinking about agent architecture, our guide on agentic AI architecture covers how these execution and tool layers fit together.
The rest of this article explains what CubeSandbox is, why agents need a sandbox at all, how isolation models differ, and how this connects to testing the APIs your agents depend on.
What is CubeSandbox?
CubeSandbox is a security sandbox system for running AI agent code, open-sourced by Tencent Cloud under the Apache 2.0 license in April 2026. Its GitHub tagline describes it plainly: “Instant, Concurrent, Secure & Lightweight Sandbox for AI Agents.” It’s not just an SDK. It’s the full sandbox-as-a-service stack, written mostly in Rust, that you can deploy yourself.
The architecture is built on RustVMM and KVM, the same Linux kernel virtualization layer used by many cloud hypervisors. According to the project’s documentation and the official announcement, the system is split into several components:
- CubeAPI: a REST gateway that mirrors the E2B sandbox interface.
- CubeMaster: the cluster orchestrator that schedules sandboxes across nodes.
- CubeHypervisor and CubeShim: the KVM virtualization layer that boots and manages each microVM.
- Cubelet and CubeProxy: node-level agents that run and route to sandboxes.
- CubeVS: an eBPF-powered network layer that enforces inter-sandbox network isolation at the kernel level.
The headline characteristic is that each sandbox gets its own dedicated guest OS kernel. That’s a different and stronger isolation model than a container, which shares the host kernel. Tencent’s published numbers state a cold start of roughly 60ms at single concurrency (averaging 67ms with P95 around 90ms under 50 concurrent creations), under 5MB of memory overhead per instance, and the ability to run thousands of sandboxes on a single large host. The press materials cite a 96-vCPU server supporting more than 2,000 concurrent sandboxes. Tencent says CubeSandbox has run at scale inside its own infrastructure and that MiniMax has used it for large-scale agentic reinforcement-learning training across heterogeneous environments.
Some advanced features, like event-level snapshot rollback for checkpointing and restoring sandbox state, are described as still in development. Treat forward-looking items as roadmap, not shipped guarantees, and check the repository for current status. Public benchmark methodology beyond the vendor’s own figures is limited, so validate the performance claims against your own workload.
For the canonical details, the source of truth is the CubeSandbox GitHub repository and the official documentation site.
Why AI agents need a sandbox
It helps to be concrete about the threats, because “security” is too vague to design against. There are three failure modes that push teams toward sandboxing.
Risky generated code. A model produces code it believes is correct. Sometimes it isn’t. It deletes the wrong directory, exhausts memory in a tight loop, or writes a file where it shouldn’t. None of this is malicious; it’s just wrong, and wrong code with host access is dangerous. The agent has no concept of blast radius unless you give it one.
Untrusted tool calls. Agents call tools and APIs based on what the model decides at runtime. If the model is steered by a prompt injection buried in a document, a webpage, or a tool response, it may call a destructive tool, pass attacker-controlled arguments, or chain calls in a way you never intended. The model isn’t a trusted actor here; it’s an interpreter of whatever text reaches its context window. We go deeper on this in our piece on AI agents as the new API consumers, which covers why traditional API trust assumptions break with autonomous callers.
Data exfiltration. This is the one people underestimate. An agent with network access and access to secrets can be turned into an exfiltration channel. A poisoned instruction tells the agent to read an environment variable holding an API key and POST it to an external endpoint. Without egress filtering and credential isolation, the sandbox boundary is meaningless because the data walks out the front door. This is why CubeSandbox pairs kernel-level isolation with eBPF-based egress filtering through CubeVS; isolation of the process isn’t enough if the network is wide open.
The common thread: you cannot assume the agent will behave, because the agent’s behavior is partly controlled by whatever untrusted data it ingested. A sandbox lets you stop reasoning about whether the model is trustworthy and start reasoning about a boundary that holds regardless. For a hands-on view of probing these behaviors before they reach production, see how to test AI agents that call APIs.
How agent sandboxes work: the isolation models
Not all sandboxes isolate the same way, and the differences matter for both security and performance. There are four broad approaches you’ll see in the agent ecosystem.
Process-level isolation. Run the code as a restricted OS process with seccomp filters, dropped capabilities, namespaces, and cgroups. This is the lightest and weakest option. It shares the host kernel, so a kernel exploit means a host compromise. Fine for code you mostly trust; thin for arbitrary model output.
Containers. Docker-style containers add namespacing and resource limits and are operationally familiar. But containers share the host kernel by design. Container escape vulnerabilities are a real and recurring class of bugs, and “untrusted code in a shared-kernel container” is a known weak spot. Many teams start here because it’s easy, then hit the isolation ceiling.
MicroVMs. A microVM boots a minimal guest kernel inside hardware virtualization (KVM). The agent’s code runs against its own kernel, so a kernel-level exploit is contained to a throwaway VM, not the host. Firecracker popularized this model for serverless workloads, and CubeSandbox sits in this category, using RustVMM and KVM with a per-sandbox guest kernel. The historical tradeoff was startup time; microVMs were slower to boot than containers. Modern implementations attack that with snapshotting and resource pre-provisioning, which is how CubeSandbox reports sub-100ms starts.
Application kernels. gVisor takes a different path: it intercepts system calls in userspace and implements a Linux-like interface itself, so the workload never talks directly to the host kernel. It’s a strong isolation layer without a full VM, with some syscall-compatibility and performance tradeoffs.
Here’s how the approaches compare across the dimensions that matter for agents:
| Approach | Isolation strength | Cold start | Overhead | Kernel sharing | Examples |
|---|---|---|---|---|---|
| Process + seccomp | Low | Instant | Minimal | Shared host kernel | Restricted subprocess, nsjail |
| Containers | Medium | ~tens of ms | Low | Shared host kernel | Docker, containerd |
| MicroVM | High | ~50–150ms | Low–medium | Dedicated guest kernel | CubeSandbox, Firecracker |
| Application kernel | High | ~tens of ms | Low–medium | Intercepted in userspace | gVisor |
| Hosted sandbox API | High (managed) | Varies | Managed for you | Managed for you | E2B, hosted offerings |
There’s no single winner. The right call depends on how much you trust the code, how fast you need cold starts, whether you can run KVM, and whether you want to operate the infrastructure yourself or consume it as a service.
CubeSandbox in the landscape
CubeSandbox’s positioning is specific: hardware-level isolation with cold starts fast enough to feel like a container, deployed as something you run rather than a service you rent. That puts it in direct conceptual comparison with three reference points.
Versus containers. A container shares the host kernel; CubeSandbox gives each sandbox its own. For arbitrary agent-generated code, that’s the security argument. The cost is that you need a KVM-enabled x86_64 Linux host (a bare-metal server, a cloud VM that supports nested virtualization, or WSL 2 for local work). If your platform can’t expose KVM, microVM-based isolation isn’t available to you and a userspace approach like gVisor or a hosted API may fit better.
Versus Firecracker. Firecracker is the well-known microVM for serverless and is itself a building block, not an agent-sandbox product. CubeSandbox is also KVM/RustVMM-based but ships higher up the stack: an orchestrator, an E2B-compatible API gateway, and eBPF network isolation, so you’re deploying an agent sandbox service rather than assembling one. If you want primitives, Firecracker. If you want a sandbox service with an agent-shaped API, CubeSandbox aims at that.
Versus E2B and hosted sandboxes. E2B provides isolated sandboxes as a managed service; you call an API and the infrastructure is someone else’s problem. CubeSandbox’s notable design choice is E2B SDK compatibility. The documentation describes it as a drop-in replacement: point E2B_API_URL at your self-hosted Cube instance and existing code keeps working. That makes the real decision less “which sandbox” and more “managed service versus self-hosted infrastructure,” with data residency, cost at scale, and operational ownership as the deciding factors. It also natively supports the OpenAI Python SDK per Tencent’s announcement.
The honest summary: CubeSandbox is a credible entry in the agent-sandbox space with a clear thesis (strong isolation, fast starts, self-hosted, E2B-compatible). It’s also new and largely documented by its vendor, so independent benchmarks are thin. Prototype it against your workload and measure cold start, density, and isolation behavior before committing.
How this connects to testing the APIs and tools your agents call
Runtime isolation answers “what if the code is bad.” It doesn’t answer “what if the API the agent calls is bad, or the agent calls it wrong.” Those are different problems, and you need both covered.
Picture a sandboxed agent that books travel. The code runs safely inside CubeSandbox. But the agent still calls a flight API, a payment API, and an internal itinerary service. If any of those returns a malformed response, the agent may loop, hallucinate a recovery, or pass bad data downstream. If it calls the payment API with the wrong idempotency key, isolation won’t save you; the money still moves. The sandbox protects the host from the agent. It does not protect your systems from a confused agent making real calls to real services.
So the workflow that actually holds up has two layers working together:
- Isolate execution so model-generated code and tool invocations can’t harm the host or exfiltrate data. That’s the CubeSandbox layer.
- Validate the contract of every API and tool the agent can reach, before and during sandboxed runs. That’s the API-tooling layer.
For the second layer, mock the dependencies so the agent talks to a controlled stand-in while you’re testing behavior, then test the real endpoints for schema conformance, error handling, auth, and edge cases. With Apidog you can build a mock server that returns deterministic, schema-accurate responses, point the sandboxed agent at it, and watch how the agent reacts to both success and failure paths without touching production. When you’re ready, run the same scenarios against the live API to confirm the contract holds. Our walkthrough on sandbox testing covers the general practice of testing against isolated, controlled environments, which applies directly here.
This pairing matters because agents amplify contract drift. A human notices when an API response looks off. An agent often doesn’t; it ingests the response and acts on it. Tight API contracts, exercised with mocks and tests, keep an autonomous caller from compounding a single bad response into a cascade. If your agents speak Model Context Protocol, testing MCP servers with Apidog extends the same discipline to the tool layer. And if you’re designing APIs for agent consumers, designing APIs for AI agents covers the contract patterns that make autonomous calls predictable.
Real-world use cases
A few patterns where the isolation-plus-contract approach shows its value:
Coding agents and code interpreters. A model writes and runs code to answer a question, transform data, or generate a chart. This is the canonical sandbox use case and the one E2B-compatible APIs target directly. CubeSandbox’s per-sandbox kernel matters here because the code is fully arbitrary and changes every run.
Multi-tenant agent platforms. If many customers’ agents execute code on shared infrastructure, container-level isolation between tenants is risky. Hardware isolation per sandbox gives you a tenancy boundary that holds even if one tenant’s agent is hostile. The reported density (thousands of sandboxes per host) is what makes that viable instead of one-VM-per-tenant.
Agentic RL and training loops. Training agents with reinforcement learning means running enormous numbers of short-lived, untrusted rollouts. Tencent cites MiniMax using CubeSandbox for exactly this across heterogeneous environments. Fast cold start and low per-instance overhead are the difference between a training run that’s feasible and one that isn’t.
Tool-using research and data agents. An agent fetches external content, parses it, and calls downstream APIs. The fetched content is untrusted (prompt-injection risk), so parsing and generated code belong in a sandbox, while downstream APIs should be exercised against mocks first. This is where pairing isolation with API contract testing pays off most.
Untrusted plugin or extension execution. If users can supply tools or code that your agent runs, you’re executing third-party untrusted code by definition. A microVM boundary per execution is the appropriate posture, the same reasoning serverless platforms used when adopting Firecracker.
Conclusion
Agent sandboxing stopped being optional the moment agents started executing code and calling tools without human review. CubeSandbox is a concrete, open answer to the isolation half of that problem.
Key takeaways:
- CubeSandbox is real and specific: Tencent Cloud’s Apache 2.0 open-source sandbox for AI agents, built on RustVMM and KVM, with per-sandbox guest kernels.
- The isolation model is the point: a dedicated kernel per sandbox is stronger than container isolation for arbitrary model-generated code, with reported sub-100ms cold starts and under 5MB overhead.
- E2B compatibility lowers the switching cost: if you’re on E2B, the documented drop-in path reframes the choice as managed versus self-hosted, not a rewrite.
- Treat vendor numbers as a starting point: the performance and density claims come largely from Tencent; benchmark against your own workload, and check the repo for which features have shipped versus are in development.
- Isolation is necessary but not sufficient: a sandbox protects your host from the agent; it does not protect your APIs from a confused agent calling them.
- Pair runtime isolation with API contract testing: mock and test every endpoint an agent can reach so a single bad response doesn’t cascade.
If your agents call APIs you own or depend on, set up the contract layer alongside the isolation layer. Download Apidog to mock the services your sandboxed agents hit and test them for schema, auth, and error behavior before an autonomous system drives them in production.
