Confining an agent takes more than a scheduler

Tensorlake recently shipped a 12x throughput improvement for sandbox scheduling by splitting their single replicated state machine into three independent Raft lanes. It is genuinely good systems work. It also has nothing to do with whether the sandboxes are actually safe to run untrusted agent code in. Those are different problems, and the field keeps conflating them.

Two problems that look like one

The scheduling problem: when an agent task arrives, which host do you place it on, how fast, and how do you keep that decision consistent across your control plane even when nodes fail? Tensorlake's Multi-Raft answer separates user intent (create/delete), scheduler placement, and dataplane status updates into three independent replication lanes, so a burst of 100,000 creation requests cannot block the heartbeats that tell the scheduler which hosts are healthy. That solves a real bottleneck, and the 12x number reflects it.

The confinement problem: once the agent is running inside that scheduled sandbox, what can it do? Can it reach internal infrastructure? Read secrets mounted into the VM? Exfiltrate data over an outbound connection? Talk to a host service that will hand it root? Scheduling says nothing about any of this. A fast, correct, highly-available control plane over insecure sandboxes is fast insecurity.

Scheduling answers: where does the agent run, and when? Confinement answers: what can the agent do while it is running? These are orthogonal, and a good answer to the first does not imply anything about the second.

What a microVM actually closes

Firecracker, Cloud Hypervisor, and similar VMMs give you hardware-virtualized guest execution: the untrusted code runs against its own kernel, on its own virtual disk, with its own process tree. The host kernel's attack surface is almost entirely removed. This is the strongest single primitive available to most teams and it is worth deploying. It closes two of the three isolation dimensions cleanly.

Dimension	What a microVM gives you	Residual gap
Process isolation	Separate guest kernel. No shared PID or mount namespace with the host.	Negligible with a well-configured VMM.
Filesystem isolation	Separate rootfs on a separate virtual block device. Host filesystem is not mounted into the guest.	Negligible with a well-configured VMM.
Network isolation	A virtual NIC with a route to the host, because the workload has to reach the internet to do anything useful.	Wide open by design. The guest can route to any host service it can address.

The first two walls are why people reach for microVMs. The third travels with them and gets assumed away. The iximiuz sandbox breakout challenge is a worked example of what the open network dimension enables: the microVM's strong isolation is not in question; the path out is the one the host left open for a different purpose entirely.

The canonical exit

Build hosts routinely expose the Docker daemon over TCP so that remote and docker-in-docker workflows can drive it. An unauthenticated Docker daemon is not a foothold; it is root on the host. The API will create a privileged container, mount the host root filesystem into it, and leave you writing the host as root. The microVM blocked the direct process and filesystem path. The network path routes around both walls in one API call.

Confinement is a stack, not a primitive

The question to ask of any sandbox is not "does it use microVMs." It is: what is the worst-case impact if I run fully adversarial agent code inside it? A correctly confined sandbox should make that answer "wasted compute inside the sandbox boundary, nothing else." Reaching that property requires assembling several layers, each covering what the previous one leaves open.

1 Kernel isolation The microVM. Separate guest kernel and disk, hardware memory boundary. Closes direct host kernel exploitation. A microVM handles this well.

2 Syscall filtering A seccomp-bpf profile on the agent process inside the VM. The guest kernel still has a syscall surface; filter it down to what the workload actually needs, so a compromised agent can't pivot via an obscure kernel interface inside the guest itself.

3 Capability stripping Drop all Linux capabilities from the agent process. Add back only what is explicitly required. Most agent workloads need none. CAP_NET_ADMIN, CAP_SYS_ADMIN, and CAP_DAC_OVERRIDE in a guest are foothold capabilities for lateral movement even inside the VM.

4 Network egress policy A strict allowlist for outbound connections. The default posture should be DROP; traffic is allowed only to explicitly enumerated endpoints. An agent that can reach arbitrary internet addresses, internal services, or host-bound listeners has not been confined; it has been given a clean environment to exfiltrate from.

5 Filesystem surface Read-only rootfs where possible. Scratch work on tmpfs, discarded at teardown. No writable path that outlives the sandbox unless that write is an explicit, logged, approved action.

6 Human-in-the-loop gates Any action with an effect outside the sandbox boundary requires explicit approval: outbound API calls, email, writes to shared storage, code execution with elevated privilege. The agent proposes; a human signs off. This is not a performance constraint; it is the only way to close the class of attacks where confinement is bypassed through legitimate-looking actions.

Most AI sandbox products today deliver layer 1 reliably and call it done. Layers 4 and 6 are where the actual risk lives, and they are the least commonly implemented.

Why the scheduling work matters but does not help here

Tensorlake's Multi-Raft architecture is worth understanding on its own terms. The core insight is that the scheduler's three traffic types, user intent, placement decisions, and dataplane heartbeats, have completely different latency and throughput characteristics. Forcing them through a single Raft log means a burst of creation requests blocks the lightweight status updates that tell the scheduler which hosts are healthy, which cascades into false-positive timeouts and scheduling failures. Separating them into independent replication rings, each running its own Raft consensus loop, eliminates the head-of-line blocking and gives each lane a clean performance envelope.

This is the same architectural insight that TiKV and CockroachDB apply at the storage layer: rather than one global consensus group, split the keyspace into independent Raft groups so writes to one range cannot stall reads to another. Tensorlake applied it to a control plane rather than a storage engine, which is a natural fit for a scheduling domain with distinct traffic classes that have no need for a global ordering guarantee between them.

None of that touches what happens inside the sandbox once it is placed. The control plane work scales how many sandboxes you can create and how fast. The confinement work determines whether creating them at scale is safe to do at all. Both problems need to be solved. Solving one well does not close the other.

The question every sandbox vendor should answer

Ask any provider offering "sandboxed" agent execution exactly one question: if I hand you a task prompt that instructs the agent to exfiltrate every file in the workspace to an external endpoint and then scan your internal network for open services, what stops it?

"We use Firecracker" answers the process and filesystem question. It does not answer the network question. A complete answer names the specific egress policy in place and the enforcement point: whether it is a kernel-level nftables rule on the host, a dedicated network namespace with no route to internal space, or a proxied egress that enforces an allowlist and logs every connection. If the answer is absent or vague, the sandbox's network dimension is unaddressed.

The microVM is the hardest wall to build. The network egress policy is the wall most teams skip. The agent will find the wall that is missing, because the agent has no incentive not to.

What a complete threat model looks like

Confinement is not binary. A useful threat model names the attacker capability at each layer and the control that closes it.

Attacker capability	Layer it targets	Control that closes it
Exploit guest kernel from agent process	Process	seccomp-bpf profile + capability stripping
Escape guest kernel to host kernel	Kernel	microVM (hypervisor boundary)
Read secrets on guest filesystem	Filesystem	Read-only rootfs; secrets injected per-task, not persisted
Reach host services over network	Network	Egress allowlist; host listeners bound to loopback or behind mTLS
Exfiltrate data to external endpoint	Network	Egress allowlist; logged proxied egress only
Take legitimate actions with external effect	Authorization	Human-in-the-loop gate on all actions with external reach
Persist across sandbox teardown	State	Ephemeral rootfs; no writable path that survives teardown except approved outputs

A sandbox that can answer this table with a named control at every row is a sandbox. A sandbox that answers the first two rows and leaves the rest blank is a microVM with an untested assumption that the agent will not look at the remaining rows.

The bottom line

Multi-Raft for sandbox scheduling is a real engineering advance. Firecracker-based microVMs are a real isolation advance. Both are necessary infrastructure for running agent workloads at scale. Neither one, nor both together, is sufficient for agent confinement. Confinement is a property assembled across kernel isolation, syscall filtering, capability stripping, network egress policy, filesystem surface control, and human-in-the-loop gates on external actions. The microVM handles the first; the rest are your problem.

Solve the scheduling problem by all means. Then come back and answer the threat model table above before calling the result a sandbox.