Tencent Cloud describes CubeSandbox as an open-source sandbox service built on RustVMM and KVM, with a dedicated guest kernel per sandbox, E2B SDK compatibility, eBPF-backed network controls, and single-node or clustered deployment. It is released under Apache License 2.0.

Does MLX use CubeSandbox today?

No. There is no CubeSandbox integration in the current MLX repository. Evaluating it would require a real runtime adapter, capability policy, identity and secret handling, image supply-chain controls, network policy, lifecycle cleanup, observability, and workload tests.

Does CubeSandbox make the whole MLX stack run inside the customer perimeter?

No. A self-operated sandbox changes one execution boundary. Current MLX model routes still use external providers, and current MLX targets are managed deployments. Connector storage, model egress, runtime operation, and business-data governance must each be assessed separately.

CubeSandbox Lands: A Useful Signal for Customer-Controlled Agent Execution

Tencent Cloud's CubeSandbox repository describes an open-source sandbox service built on RustVMM and KVM for agent code execution.

The project reports:

a dedicated guest kernel per sandbox;
compatibility with the E2B SDK;
a headline average end-to-end cold start below 60 ms, with the detailed benchmark reporting 60 ms at single concurrency and 67 ms average under 50 concurrent creations;
less than 5 MB of per-instance memory overhead under its stated conditions;
eBPF-backed network isolation and egress filtering;
single-node and multi-node deployment;
an Apache License 2.0 release.

That is a useful new infrastructure option.

It is not proof that a finance agent is now customer-controlled end to end, and it is not a feature currently wired into MLX.

What a Sandbox Actually Controls

A general-purpose agent may run generated code, manipulate files, launch a browser, install packages, or execute a command-line tool. That work needs an isolation boundary.

A sandbox can help constrain:

filesystem and process access;
the lifetime of an execution environment;
resource consumption;
network destinations;
separation between concurrent workloads;
damage to the host or another tenant.

Those are execution concerns.

A sandbox does not decide:

which customer or organisation the user may access;
what “revenue” or “active customer” means;
whether source evidence is fresh;
which model provider receives context;
whether a connector may write;
which product and version support an answer;
whether a human has approved a business definition.

Calling the sandbox “the other half” of governed finance AI collapses several independent control planes into one component.

Why the Governed Twin Path Is Different

The direct governed Twin path does not ask a model to write arbitrary code or SQL.

The organisation approves a narrow business product with:

a stable published relation;
a versioned contract;
approved dimensions and measures;
organisation scope;
freshness and validation evidence;
an optional evaluation suite.

The agent submits a typed query intent. The runtime validates it and mechanically compiles a read-only query against the exact activated relation.

That path does not need a general-purpose MicroVM to make a finance query safe. Its primary defence is removing arbitrary execution from the model's tool surface.

A sandbox becomes relevant for a different class of task: explicit terminal, browser, file-processing, or code-execution capabilities. Those remain opt-in capabilities and need their own policy and evidence.

What the Official Claims Do and Do Not Establish

CubeSandbox's published numbers are specific to its test conditions. The repository notes that cold-start measurements were taken on bare metal, reports different results under concurrent creation, and qualifies memory overhead by sandbox size.

That is normal for infrastructure benchmarking. It means a buyer should reproduce the measurements on the intended target.

“E2B compatible” also needs workload testing. Protocol compatibility can reduce adapter work, but it does not prove identical behaviour for:

template creation;
filesystem semantics;
command streaming;
timeouts and cancellation;
network policy;
snapshots and rollback;
browser workloads;
concurrency and quota handling;
errors and retries.

The safe interpretation is “a potentially lower-friction migration surface,” not “change one URL and production is done.”

CubeSandbox Is Not a Current MLX Route

The current MLX repository has no CubeSandbox adapter or configured runtime route.

That matters because infrastructure support is more than a package reference. A production integration would need:

a typed runtime adapter and lifecycle contract;
explicit capability gating for code, terminal, browser, files, and network;
user, tenant, and organisation authority;
controlled base images and dependency provenance;
secret injection that does not leak into snapshots or logs;
default-deny network policy with reviewed egress;
CPU, memory, disk, time, and concurrency quotas;
cancellation and guaranteed cleanup;
structured runtime events and incident evidence;
target-specific isolation and escape testing;
upgrade, rollback, and vulnerability-response procedures.

Until those exist and are tested, CubeSandbox is an external technology to evaluate, not an MLX capability.

It Also Does Not Remove Model Egress

Running code in a customer-operated KVM sandbox does not determine where the agent model runs.

Current MLX model routes use external providers. The context sent to the selected model follows that provider path. Current MLX targets are also managed deployments; a customer-operated or on-premises target is not established merely by adding a self-hostable sandbox component.

A deployment map still needs to show:

where the control plane and worker run;
where connector evidence and canonical state live;
which model provider receives context;
where sandbox inputs and outputs are stored;
which operators can access the target;
how logs, snapshots, and backups are retained.

One in-boundary component does not make every arrow stay inside the boundary.

A Serious Evaluation Plan

If CubeSandbox is relevant to a future execution surface, evaluate it as infrastructure:

Reproduce performance

Measure cold start, tail latency, steady-state overhead, density, and teardown on the actual host class and concurrency profile. Include the real template image and workload.

Test isolation

Exercise filesystem, process, device, network, metadata-service, host, and cross-sandbox boundaries. Validate the KVM and eBPF configuration that will actually be deployed.

Test policy

Confirm default-deny egress, allow-listed destinations, DNS behaviour, quotas, cancellation, and cleanup. A sandbox that can reach every internal service is not an acceptable agent boundary.

Test compatibility

Run the calls and failure cases the application uses. Do not treat SDK import compatibility as behavioural equivalence.

Test operations

Prove image updates, vulnerability response, node replacement, cluster failure, metrics, logs, incident investigation, and rollback.

Test the agent boundary

Confirm which MLX capability would expose the sandbox, which users can request it, what data can enter it, and which evidence a completed run retains.

Where It Fits in the Product Story

CubeSandbox is relevant to customer-controlled execution. The Twin governs approved business meaning. Model routing controls a separate model path. Connectors and warehouse scope control the data path.

Those layers can complement one another, but none substitutes for the others.

The most credible MLX position today is therefore:

CubeSandbox is an interesting external project;
its official performance and compatibility claims deserve target-specific validation;
it is not currently integrated;
governed Twin answers already avoid arbitrary model-authored execution;
any future sandbox route would be an opt-in capability with its own implementation and acceptance gate.

That is a stronger architectural story than claiming the stack is complete because a promising repository shipped.

Model-layer counterpart: Kimi K2.6. Another market signal that should enter an evaluation queue, not be presented as a current route.

Deployment reality: On-Prem AI for Finance. The acceptance evidence required before calling any customer-operated topology production-ready.