Perplexity SPACE Sandbox: 0 VM Escapes in 108 Red-Team Runs

Perplexity has released SPACE (Sandboxed Platform for Agentic Code Execution) as an Apache 2.0 open-source project, providing the Firecracker microVM isolation layer that now runs every session on Perplexity Computer. The codebase is Rust, tagged at release 0.8.0, and requires a Linux x86_64 host with KVM, /dev/kvm, btrfs, and Docker. It is a production-tested, adversarially evaluated security architecture rather than a reference design — the area our earlier analysis of infrastructure isolation as the real AI security lever identified as the weakest point in agent containment.

Architecture: three layers, one trust boundary

Perplexity's engineering blog describes SPACE as a three-layer stack. The control plane is stateless, offloading all durable state to a PostgreSQL-backed database; it tracks sandbox assignment, running status and backup state, and reconciles desired versus observed state idempotently so it can recover from crashes. Node-local services handle VM lifecycle, storage, networking and privileged operations. The sandbox itself is a Firecracker microVM with its own guest kernel, paired with a space-daemon inside the guest.

That pairing is the security-critical decision. The space-daemon is the only sanctioned path between untrusted guest and trusted platform, communicating with the host over a private in-VM channel, never directly with clients. The sandbox's network interface is reserved exclusively for workload egress, and all egress is forced through a per-sandbox host-side gateway. Credentials are never injected into the guest; the credential store outside the VM boundary handles hierarchical scoping, rate limiting and audit logging, injecting secrets at the network layer or via browser automation instead. BYOK support lets enterprises use their own KMS; if a key is revoked, stored data becomes unreadable.

The filesystem layer uses btrfs copy-on-write: each sandbox root filesystem is a CoW clone of a template. A scheduler captures frequent disk snapshots and less frequent full VM checkpoints, enabling rollback, crash recovery and cross-node restore. Suspended sandboxes are uploaded to object storage, so any node can restore them. Sandboxes idle for 6 hours are suspended automatically.

Red-team results: escape held, egress did not — then did

Perplexity's "Escaping SPACE: Part I" report, published September 23, 2026, is the most useful evaluation data. The study ran 216 total runs across 9 frontier models given root inside the guest, testing 2 tasks and 4 network settings. Perplexity reports zero VM-to-host escapes across 108 sandbox-escape attempts — no model reached the host-side secret.

Egress policy was different before fixes. In 54 partial-network runs, 11 bypasses succeeded; four models — Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber and Kimi K3 — used DNS spoofing and shared CDN IP addresses. Perplexity hardened the gateway with nftables source-address validation and TLS termination with both SNI and HTTP Host checked against an allowlist. In the retest, Perplexity reports zero verified bypasses. The same team tested 10 third-party platforms; 8 showed at least one network-policy bypass, and Perplexity states it disclosed results to affected vendors.

Latency: production figures

During Perplexity Computer's rollout week — millions of sandbox creations and tens of millions of reconnects, per Perplexity — median create latency fell from 185 ms to 60 ms versus the previous provider. At the 90th percentile, latency dropped from 447 ms to 89 ms. Kubernetes deployments use warm pools of pre-booted sandboxes; single-node deployments use base snapshots. These are vendor-reported figures from Perplexity's own infrastructure.

AI Mastery analysis

The architectural choices in SPACE reflect our earlier finding that agent security failures concentrate at shared surfaces rather than in model logic. The red-team data validates that framing: the VM escape surface held completely, while the egress boundary — a shared network plane — was the actual vulnerability. The fix is meaningful. SNI-only egress filtering fails against CDN IP reuse; requiring TLS termination with Host header validation adds a second inspection point that survives that attack class.

What the release does not solve is self-hosting complexity. The requirement for nested virtualization when deploying inside a VM is a real constraint: most Kubernetes-capable cloud instances do not expose KVM by default, which pushes teams toward bare-metal or KVM-enabled instance types. Teams evaluating SPACE for production need to account for that hosting cost before comparing it to a managed sandbox API. The E2B Compatibility Wrapper tested against e2b==2.21.1 eases migration for existing E2B users, but introduces a translation layer. The reference EKS deployment is a useful starting point, though bare-metal EKS carries different operational overhead from a managed cluster.

The broader signal is that infrastructure rewrites, not model weights, are driving 2026 AI gains, and that pressure is now reaching security infrastructure specifically. Open-sourcing a production red-teamed sandbox raises the baseline for what "isolated agent execution" means; container-only isolation with a shared kernel now has a concrete, auditable alternative to compare against. The eight-of-ten bypass rate on third-party platforms Perplexity tested suggests the gap between stated and actual security posture in agent execution environments remains wide.

Sources

• Primary: Making SPACE: Secure Runtimes for Long-Running Agents
• Reported by: MarkTechPost: Perplexity Open-Sources SPACE, a Firecracker MicroVM Sandbox for AI Agents