Every Cagebox agent runs inside its own Firecracker microVM — the same hypervisor AWS Lambda uses for untrusted tenant code. The boundary between your agent and the next tenant's agent is a CPU virtualization boundary, not a Docker namespace.
Each agent gets its own kernel, scheduler, and address space. Escape from one agent into another would require defeating both the guest kernel and KVM itself — a category of bug Firecracker is purpose-built to minimise. The hypervisor footprint is ~50 kLOC of Rust, an order of magnitude smaller than a general-purpose hypervisor.
The Firecracker process for each VM runs under jailer — chrooted, dropped to an unprivileged uid, with its own cgroup and a seccomp-bpf filter that only allows the ~24 syscalls Firecracker actually needs. A compromised VMM process can't stat anyone else's filesystem or talk to the network outside its TAP.
All agent VMs share a bridge so we can route inbound webhooks through Caddy, but ebtables forbids any L2 frame whose source AND destination are both VM TAPs (ADR-0016). Two agents on the same host can't see each other's ARP, can't probe each other's HTTP, can't pretend to be each other's gateway.
Provider API keys (OpenAI, Anthropic, etc.) and Telegram / Slack tokens you paste in the wizard are not stored in our database. They travel straight from your browser to your VM's persistent disk at /data/.env, where the agent reads them at boot. Our control-plane keeps only the last 4 characters of each key as a UI preview so the Configure form can show you which fields are set.
Discord bot tokens are the one exception. Our host-side Discord relay has to hold the gateway WSS for your bot 24/7 — even while your VM is paused — so the Discord-side fields are kept on the control-plane, encrypted with AES-256-GCM, and decrypted in memory by the relay only when it needs to forward an event to your VM.
Honest scope: a database leak doesn't reveal your provider keys. A compromise of the host running your VM, or our control-plane host, would — at that point an attacker can already read your VM's disk directly. We don't claim "zero-knowledge" here; we just don't ask for more access than we need.
Honest list of gaps we'll close before GA: