How does CubeSandbox configure an isolation environment for AI Agent: concurrent execution, permissions and cost trade-offs

Sun, 12 Jul 2026 10:35:00 +0800

When an AI agent needs to run code, install dependencies, access web pages, call tools, or continue to perform long tasks, the question is no longer just “can it run?” but “where should this untrustworthy or incomplete instruction run, what can be accessed, and how to stop and roll back after an error occurs.” CubeSandbox is a sandbox service for Agents, focusing on fast startup, high concurrency and KVM hardware-level isolation.

It is suitable for separating the execution surface of the Agent from the host and production environment. It’s not about making everything automatically secure: mounted directories, network exits, injected credentials, image templates, and scheduling quotas still need to be explicitly configured by the team.

First determine whether you really need CubeSandbox

Not every Agent requires a microvirtual machine. You can choose by risk and task type:

Scenario	More appropriate way	Reason
Read-only code Q&A, static search	Local read-only tools or restricted MCP	No need to start a standalone execution environment
Run unit tests, install dependencies, and execute generated code	CubeSandbox or other strong isolation sandboxes	Code and dependencies may not be trusted and will be written to the file system
High-concurrency Agent evaluation, batch tasks, browser automation	CubeSandbox cluster	Need to quickly create, recycle and isolate multiple execution units
Operate production database, send emails, and deploy	Manual approval and controlled dedicated system	Sandbox cannot replace business authorization and change process

If the agent only needs to retrieve files and propose patches, start with read-only permissions and diff review. Only when the task really needs to execute untrusted code or a large amount of concurrency, introduce a complete sandbox to avoid using infrastructure complexity to solve a problem that can be handled by permission policies.

What is the isolation model of CubeSandbox?

CubeSandbox is based on RustVMM and KVM, providing an independent Guest OS kernel for each sandbox. Its goal is to reduce the scope of impact caused by container escapes compared to ordinary containers that share the host kernel; the repository also provides components such as eBPF network isolation, egress control, auditing, and credential vaults.

These concepts need to be understood separately:

Computing Isolation: Restricts Agent to run code in its own sandbox and does not directly obtain host process and kernel permissions.
File Isolation: Determines which mounted directories, templates, and persistent volumes the sandbox can see.
Network Isolation: Decide which domains, APIs, and internal services it can access.
Identity Isolation: Determines whether credentials go directly into the environment, log, or model context.
Business Isolation: Determine whether the Agent has the right to modify real data, send messages, or trigger deployment.

KVM can improve the first four layers, but cannot automate the last layer. Even if the code is executed in an independent virtual machine, obtaining a high-privilege production token may still cause real business impact.

Basic conditions before deployment

Official Quick Start requirements x86_64 Linux environment with KVM support. It supports single-node deployment and can also be expanded to a multi-node cluster; the development environment solution can be used when there is no KVM, but it is officially marked as having poor performance and should not be directly used as a high-concurrency production benchmark.

When preparing the environment, first confirm:

CPU virtualization is enabled in the BIOS and host system, and KVM devices are available.
The responsibilities of control nodes, compute nodes, and storage locations are divided so that the control plane is not mixed with business data.
The source of the image or template is traceable and contains a fixed version of the runtime, package manager and basic tools.
Logs, indicators, and audit data have independent storage and retention policies, and do not rely on the Agent to explain what happened.
The ability to stop individual sandboxes, stop queues, or cut off exits on exceptions, rather than just stopping the entire cluster.

After the installation is complete, the official web console uses the :12088 port of the control node by default. The console should be placed in a restricted network and not directly exposed to the public network; set independent identity authentication and network access rules for administrators.

How to plan for concurrency

One of the advantages of CubeSandbox is its rapid creation and high-density operation. The official benchmark describes cold start as an average single concurrency of less than 60ms, and gives a basic memory overhead of less than 5MB for small-sized instances; however, these are performance data in a specific environment and should not be directly equated to your business capacity.

When planning concurrency, split the capacity into four variables:

Variables	Questions to ask	Common misunderstandings
Queue length	How many Agent tasks are waiting to be executed at the same time?	Only look at average request volume, not peak bursts
Single task resources	What are the CPU, memory, disk, and running time of each task?	Only model tokens are evaluated, compilation and dependency installation are not evaluated
Template hits	Does the task use preheated templates or frequently reinstall dependencies?	All tasks start from an empty image
External Bottlenecks	Can the network, LLM API, database, or browser service tolerate concurrency?	If the sandbox is fast enough, the entire link is considered fast enough

It is recommended to start with a small amount of concurrency, use real tasks to measure creation latency, execution time, failure rate, memory peak, and egress request volume, and then set upper limits per tenant, per project, and per task type. Don’t understand “can run a large number of instances on a single node” as meaning that it can accept unlimited external requests.

Permission configuration should follow the minimum scope

The safest default state is: no mounts, no credentials, no network exits, and no persistence. Then add capabilities one by one on a task-by-task basis.

An executable permission hierarchy can be:

Read-only analysis sandbox: Read-only code snapshots, no network, no keys, allows static analysis and test planning.
Build and Test Sandbox: Writable temporary working directory, allows downloading dependencies from internal product sources, and does not mount the host project directory.
Controlled Integration Sandbox: Only allows access to whitelisted test APIs, credentials are injected by the vault on request and a minimum validity period is set.
Manual Approval Task: When outsourcing, production data, paid resources or infrastructure changes are involved, first pause and require approval to prevent the Agent from directly obtaining capabilities.

Do not mount the entire user home directory, Docker socket, SSH private key directory, cloud credentials directory, or production configuration. The mount is more decisive than the prompt word: once a directory is writable, Agent-generated code or tools may affect everything in it.

How network exits and credentials are handled

CubeSandbox provides CubeEgress for domain name filtering, credential injection and access auditing. The goal is to prevent API keys from entering the sandbox, model context or ordinary logs directly. You still need to verify your own policies when using them, rather than treating the “credential vault” as an audit-free flag.

Suggestions:

The external network is denied by default and only the domain names and ports necessary for the task are allowed;
Whitelist the package repository, model API, test service and internal documentation respectively;
Use least privilege, short-lived, revocable credentials for each type of task;
Record the request target, time, task ID and result code, but do not record the complete key or sensitive request body;
Automatically stop and alert tasks when unknown domain names, abnormal traffic, or repeated authentication failures occur.

The network allow list can reduce irrelevant external connections, but it cannot determine whether the service request is correct. For payment, user data and production control planes, authentication, approval and rate limiting should still be implemented on the business system side.

How automatic pauses, snapshots and rollbacks reduce costs

Long tasks do not mean keeping each environment running forever. CubeSandbox provides automatic pause/resume, as well as snapshot, clone and rollback capabilities, which can be used to reduce idle costs and speed up the startup of similar tasks.

Reasonable usage is:

Set automatic pause for idle development or evaluation environments;
Make templates or snapshots after installing stable dependencies and configuring the runtime;
Use clones to launch concurrent copies of the same task instead of repeatedly installing from scratch;
Roll back to a known checkpoint when an exception occurs in Agent modification;
Calculate storage costs separately for snapshots, logs, persistent volumes, and long-pause environments.

Automatic suspension will save computing resources, but will bring recovery delays; snapshots and persistent volumes improve reproducibility, but also increase storage and life cycle management burden. The cost model should include both compute, storage, network egress, template building, observation, and manual review time.

The safe execution process of an Agent task

High-risk tasks can be run in the following order:

After receiving the task, classify it first: read-only, build test, controlled integration, or requires approval.
Select a minimum template, resource quota, validity period, and network whitelist for the task.
Create an independent sandbox and record the task ID, template version and policy version.
Run commands within the sandbox and collect standard output, exit codes, resource usage and network audits in real time.
Pause and request approval for actions that write to external systems, use sensitive credentials, or exceed budget.
Output results, diffs, test records, and citation sources instead of just “done”.
Recycle the temporary sandbox; pause or save the snapshot according to the policy when reuse is needed.

This process also applies to [How to recover after long task interruption of AI Agent] (/en/2026/07/10/ai-agent-long-task-resume-guide/): When recovering, first verify whether the snapshot, task input and permission policy are still valid, and do not blindly continue execution from the old state.

Common misunderstandings

“With KVM, there is no need for permission control”

Error. KVM primarily isolates the computing environment; mount, network, credentials, and business API permissions are still determined by your configuration. The most dangerous combination is often a strongly isolated VM coupled with over-authorized production tokens.

“The higher the concurrency, the lower the cost”

Not necessarily. High concurrency will amplify the pressure on the LLM API, database, bandwidth, image pull, and logging systems. Set quotas, queues, and backoff strategies first, and then gradually stress test instead of trial and error on real user tasks.

“There is no cost after automatic suspension”

A paused environment may still consume snapshots, persistent volumes, logs, and control plane resources. Expiration cleanup rules should be set and recovery frequency statistics should be used to avoid turning short-term caches into permanently idle assets.

Summary

CubeSandbox is suitable for execution environments that need to run untrusted code, tool calls, or high-concurrency agents. Its value lies in hierarchically isolating compute, files, networks and credentials, and controlling startup and resource costs with pauses, templates, snapshots and clones. A truly secure configuration is not to “open a sandbox”, but to set minimum permissions, observable execution, clear approval and recyclable life cycles for each type of task.

Official warehouse: https://github.com/TencentCloud/CubeSandbox

KVM on KnightLi Blog