Cagebox

Security model

How we isolate your agent

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.

Hardware-level VM isolation

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.

Jailer + seccomp-bpf

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.

VM-to-VM L2 isolation

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.

Secrets handling

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.

The one exception applies only if you connected a Discord bot to your agent: our host-side Discord relay has to hold the gateway WSS for that bot 24/7 — even while your VM is paused — so its Discord 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.

What we don't have yet

Honest list of gaps:

  • Agent disks are not encrypted at rest yet — disk encryption at rest is on our roadmap. Each disk is still reachable only from its own agent's machine.
  • No third-party security audit yet. Architecture review is welcome — write us at support@cagebox.dev.
  • No uptime guarantee (see terms). Don't run anything on Cagebox that can't tolerate downtime.