microVM isolation: how the boundary is enforced
An agent that writes code will run it. The only isolation worth describing on a marketing page is the kind you can point at afterwards — so here is the whole stack, layer by layer, including the parts that are not finished.
Why a container is the wrong shape for this
Containers isolate by agreement. Every tenant shares one host kernel, and namespaces, cgroups and a seccomp profile promise to keep them apart. That promise is fine for workloads you wrote. It is a different proposition for a workload that generates and executes new code every few seconds, where the threat model includes the workload itself.
A microVM moves the boundary down a layer. The guest gets its own kernel and its own memory, and the separation is enforced by the same hardware virtualisation your cloud provider already relies on for its own multi-tenancy. One session, one VM — an escape has to defeat the hypervisor, not a namespace.
The control stack
Isolation is not one mechanism. These five layers are in place today. The filesystem and network policies deny when their policy is absent. The seccomp filter does not, and we say so rather than folding it into a blanket “default-deny” claim: it is a targeted set of blocks.
Hardware boundary
Each session boots a Firecracker microVM on KVM with its own guest kernel. A guest kernel bug is contained inside that VM instead of reaching a kernel shared with other tenants.
isolation: firecracker microvm on kvm · own guest kernelFilesystem policy
Read-only and read-write paths are declared up front and fixed in the sandbox specification when the session is created. Where the guest kernel provides Landlock, the supervisor enforces that policy with it; the supervisor probes for it at startup rather than assuming it. Either way the declared policy cannot be widened from inside the guest.
fs: declared at create · landlock where the guest kernel provides itSyscall surface
A seccomp filter is installed before the workload runs and is fixed for the life of the sandbox. It is not a full allowlist: it blocks the escape-relevant calls — the ones that reach for other namespaces, load kernel modules or re-enter the supervisor — while ordinary build and test syscalls pass.
syscalls: targeted seccomp blocks · fixed at createNetwork boundary
Egress is deny-default: the baseline policy grants no destination at all. A session reaches only what its own configuration names at create time — the repository host, the model endpoint, configured MCP endpoints. That list is fixed for the life of the session. Enforcement sits on the host datapath, not in a proxy the workload could route around.
egress: deny-default · host datapath · destination list fixed at createCredential handling
Provider and source-control credentials are stored as encrypted vault references, never as material in our tables, and are never displayed again after saving. Injection into the session is plaintext environment material today, so the agent process can read what it is given.
credentials: vault reference · env injection into the session
What “closed by default” means in practice
A session starts with no route out. The destinations it can reach are fixed when the session is created: the repository host, the model endpoint, and any MCP endpoint its configuration names. Everything else is denied, and the list closes with the session. Editing that list yourself, per destination, is roadmap — today it follows from the configuration you picked.
Two mechanics carry that policy, and both sit outside the guest.
Name resolution is forced to a host resolver that answers only for the session's own list, so a name nobody granted never resolves. On top of that, a TLS connection leaving the guest is forwarded only when the host it asks for matches an entry on that list exactly — the match is on the name, and it is made on the host. A default-drop forwarding path carries the rest: cloud provider metadata endpoints are not reachable from a session, because nothing outside those two paths is forwarded at all.
Limits and open work
A security page that only lists strengths is a sales page. These are the current boundaries of the claim:
- Physical isolation is tier-dependent.
- Dedicated bare metal exists in the dedicated tier. On shared capacity the infrastructure is shared, and the isolation claim rests on the microVM boundary rather than on separate hardware.
- Encryption at rest does not protect a live compromise.
- Volumes are encrypted, but that control does not help against a compromised gateway while it is running.
- The agent process can read its own credentials.
- Provider and source-control keys are injected as environment material, so the credential is inside the process that uses it. Agent-blind injection, where the key never enters that process, is designed and not yet wired up.
- The enforcing layer is the host, not the guest.
- The guest supervisor carries its own egress policy as a second layer, but we do not claim the two lists are congruent today. The boundary you can rely on is the host datapath, which is the one we test.
- The event feed is live only, and not tamper-evident.
- A running session streams a structured feed. Persistence, export and retention, and anchoring the feed so it can be proven unmodified, are all open work.
Related
Have your security reviewer read this page
If something here does not survive their questions, we would rather hear it now. Design partners get the architecture detail behind every line above.