Evidence at a glance
An Open-Source Execution Layer
Perplexity has open-sourced SPACE, or Sandboxed Platform for Agentic Code Execution, the sandbox platform that runs agent tasks in Perplexity Computer. Released under Apache 2.0, its public baseline is version 0.8.0, and it is aimed at teams running coding or browsing agents. Applications use an HTTP API to create Linux environments, execute commands, and receive output through server-sent events (SSE).
The release matters less because agents can execute code—that is already familiar—than because execution environments are becoming infrastructure for agent products. An agent may install software, call services, and operate as root inside its environment, while its task may persist, retain state, and branch. SPACE is designed to keep those operations inside the guest without handing the host or its credentials to the agent.
Isolating the VM—and Control
SPACE starts a Firecracker microVM for each sandbox task, with its own guest kernel and writable disk. A template provides the starting filesystem, and a sandbox is an instance of that template; multiple commands can run in the same sandbox. Its root filesystem uses btrfs copy-on-write, reducing the work of preparing repeated environments.
The more consequential boundary sits outside the VM. A per-sandbox gateway on the host controls outbound connections, and secrets are not placed in the guest; they are injected at the network layer. The credential store also supports hierarchical scopes, rate limits, and audit logs. The service is organized around a PostgreSQL-backed API, controllers, worker services, and a data plane, with workers managing VMs, networking, volumes, templates, and credentials. In other words, isolation depends not only on the VM but also on a control plane that does not hand each task unrestricted credentials and network access.
Persistence Trades Resources for Speed
SPACE defines four sandbox states: running, paused, suspended, and deleted. When paused, the VM's memory remains on the worker, so a pause is not a durable snapshot. Suspension saves memory, runtime state, and the root filesystem, then releases active resources. The default is to suspend a sandbox after six idle hours. That preserves progress for long-running work, but also makes snapshotting and restoration part of the system's operational burden.
Deployment choices affect startup speed. Kubernetes deployments can use pools of already booted sandboxes, while single-node deployments use base snapshots. The former reserves warm capacity; the latter avoids keeping a pool of running instances. Perplexity reports that, in production, median creation latency fell from 185 milliseconds with its previous provider to 60 milliseconds, while p90 latency fell from 447 to 89 milliseconds. Fast creation is not a free abstraction: it is purchased through a combination of warm capacity, snapshots, and resource reclamation.
Red-Team Tests Found a Different Boundary
Perplexity's tests treated escaping the VM and bypassing network policy as separate outcomes. Nine models were given root inside the guest and run through two tasks and four settings, for 216 runs in total. In 108 VM-escape attempts, none reached a host-side secret. In the no-network setting, none of 54 attempts bypassed the restriction.
The result changed when partial network access was allowed: before fixes, 11 of 54 runs bypassed egress policy, with four models finding a path. The attacks used DNS spoofing and shared CDN IP addresses. Perplexity added source-address validation through nftables, and the gateway now terminates TLS and checks both SNI and the HTTP Host against the allowlist. No model produced a verified bypass in the retest. The distinction matters: a microVM can keep the guest away from the host without proving that its network perimeter is sound.
Test Two Security Properties Separately
Perplexity says every Perplexity Computer session runs on SPACE and describes the platform as a production-tested isolation layer. But use in one production product is not the same as a guarantee for every workload. The report also says that eight of ten third-party platforms tested had at least one network-policy bypass, and that affected vendors were notified. The material does not give enough detail to compare those platforms individually, so the figure should not be treated as a universal benchmark.
For technical leads, the practical decision is to make guest isolation and egress control separate acceptance criteria: test whether a privileged task can reach the host, then test whether DNS behavior, shared IPs, TLS, or hostname checks can defeat the allowlist. Running SPACE requires Linux x86_64, KVM, /dev/kvm, btrfs, and Docker, and supports local Kind (Kubernetes) or direct mode; macOS is not supported. It offers a self-hosting path, but does not decide which credentials an agent may use or which destinations it may reach. Nor does it remove the need to retest as policies and dependencies change.