Security and isolation - Anona Compute

Layer	What it does
A microVM per sandbox	Each sandbox is a KVM virtual machine with its own guest kernel. Escaping it takes a hypervisor escape, not a container escape.
Network policy per sandbox	An eBPF filter (layer 3) and an egress proxy (layer 7) enforce the egress policy. Private ranges and cloud metadata are always blocked.
A gateway in front of everything	The engine’s own API is never exposed. Every byte to or from a sandbox passes the gateway’s sandbox edge, which checks a per-sandbox token.
Per-sandbox tokens	The `envd` access token and the traffic token are derived per sandbox; a token from another organization, or from a deleted sandbox that had the same ID, never matches.
Tenant isolation	A sandbox of another organization answers “not found”, the same as one that does not exist, so IDs cannot be probed.
Scoped API keys	Keys carry scopes (read, use, create, delete, usage, billing, integrations) and can be limited to a list of sandbox IDs. See API keys in CI.
Revocable sessions	Dashboard and CLI sessions can be revoked on the dashboard; the API stops accepting them within seconds.
Short-lived access	Live-view tokens last at most 10 minutes and can all be revoked at once; SSH certificates last 10 minutes and name one sandbox.

Inside the sandbox

Commands run as user (uid 1000), with passwordless sudo inside the VM. Root inside the VM is not root on the host.
Templates start no daemons at boot beyond envd and the Anona guest agent (which carries live view and SSH). The SSH server starts on first use and listens on loopback only.
Sandboxes have public DNS resolvers and no route to Anona’s internal network.

Credentials

Secrets passed as environment variables (envs=, or per command) live in the sandbox’s memory and disk like any other data, and a pause snapshots them too. For API tokens, use the credential vault instead: the egress proxy adds the token to requests to one host and the sandbox never sees it. See Networking.