Perplexity Open-Sources SPACE, the MicroVM Sandbox Powering Perplexity Computer

By James Calloway

Perplexity has open-sourced SPACE (Sandboxed Platform for Agentic Code Execution), the Firecracker microVM sandbox that runs every task in Perplexity Computer, under an Apache 2.0 license on GitHub. The release comes with a red-team record that cuts both ways: 0 of 108 sandbox-escape attempts succeeded across 9 frontier models, yet before fixes, agents bypassed the egress policy in 11 of 54 partial-network runs.

For teams building coding or browsing agents, SPACE offers a production-tested isolation layer they can self-host. That matters because agent sandboxing has become a quiet battleground — Perplexity's own tests found at least one network-policy bypass on 8 of 10 third-party sandbox platforms.

What shipped, exactly?

The public baseline is release 0.8.0, a Rust codebase exposing an HTTP API with server-sent events. The host requirements are specific: Linux x86_64 with KVM, /dev/kvm, btrfs and Docker, deployed either into a local Kind (Kubernetes-in-Docker) cluster or in direct mode. There is no macOS support.

Each agent task gets its own Firecracker microVM — the same virtualization layer AWS built for Lambda — with its own guest kernel. The agent runs commands, installs packages and calls services as root inside the sandbox. The host stays outside the guest's control.

Two design choices carry the security argument. First, secrets never enter the guest: credentials are injected at the network layer, with hierarchical scoping, rate limits and audit logging, per Perplexity's July engineering post. Second, a per-sandbox gateway on the host enforces egress policy on every outbound connection.

In short: the code is real, shipped, and constrained to a specific Linux stack.

What do the performance numbers show?

In production, median sandbox-create latency fell from 185 ms to 60 ms versus Perplexity's previous sandbox provider. The 90th percentile dropped from 447 ms to 89 ms. Perplexity reports that 100% of Computer sessions now run on SPACE.

The speed rests on two mechanisms. Kubernetes deployments use warm pools — clusters of pre-booted sandboxes ready to hand out. Single-node setups use base snapshots instead. btrfs copy-on-write (a filesystem technique where new data is written without duplicating unchanged blocks) creates each root filesystem.

Sandboxes move through four states: running, paused, suspended and deleted. Pausing keeps VM memory resident on the worker but is not a durable snapshot. Suspending snapshots VM memory, runtime state and the root filesystem, then releases active resources. Idle sandboxes suspend after 6 hours by default — a design choice that reflects the reality that agent work is long-running, stateful and branching, and must survive restarts.

The takeaway: the latency gains are Perplexity's own measurements against its own previous provider, not an independent benchmark.

Did SPACE survive the red team?

Perplexity's "Escaping SPACE: Part I" report, published September 23, 2026, tested 9 models with root inside the guest across 216 runs, 2 tasks and 4 settings. The headline results:

• Sandbox escape: 0 of 108 runs reached the host-side secret.
• No-network bypass: 0 of 54 runs succeeded.
• Partial-network bypass: 11 of 54 runs succeeded before fixes, with 4 models finding a path.

Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber and Kimi K3 found the bypasses. The attacks exploited DNS spoofing and shared CDN IP addresses to slip past the allowlist.

Perplexity's response: source-address validation through nftables (Linux's packet-filtering framework), plus a gateway that now terminates TLS and checks both SNI and the HTTP Host header against the allowlist. In the retest, no model produced a verified bypass.

The caveat deserves emphasis. The clean post-fix numbers exist only because frontier models broke the original design first. Isolation held; the network layer did not, until it was patched.

How does it compare with other open sandboxes?

Perplexity tested 10 third-party platforms in the same red-team exercise, run August 31 to September 1, 2026. Eight showed at least one network-policy bypass. The company disclosed results to every affected vendor.

Against the open-source field:

• E2B Runtime: Firecracker microVM, Apache 2.0, written in Go. Perplexity's test found an HTTPS bypass; a mitigation is planned.
• microsandbox: libkrun microVM, Apache 2.0, Rust. Perplexity's test found HTTP and HTTPS bypasses; a fix shipped in v0.6.18.
• Daytona: dedicated kernel per sandbox, public repo unmaintained since June 2026. Perplexity's test found an HTTPS bypass; a mitigation was released.

SPACE also ships an E2B Compatibility Wrapper (ECW) so teams already on E2B can try it, with a tested baseline of the Python package e2b==2.21.1. A reference AWS EKS deployment is included in the repository.

Note the conflict of interest: the comparison table's security column comes from Perplexity's own tests of competitors, conducted by the company selling the alternative.

What are the deployment requirements?

The installation guide deploys SPACE into a local Kind cluster. The host needs /dev/kvm, /dev/net/tun, loop devices and btrfs. Running it inside a VM requires nested virtualization. Workers manage VMs, networking, volumes, templates and credentials, coordinated by a PostgreSQL-backed API, controllers and a data plane.

That dependency list narrows the audience to teams already running Linux infrastructure with hardware virtualization. This is not a laptop dev tool.

The bottom line: SPACE is a credible, production-hardened option in a market where most sandboxes failed Perplexity's own tests — but adopters should read the egress-bypass history before trusting the defaults.