Perplexity open-sources SPACE agent sandbox; its own tests show why VM and network isolation need separate checks

What has been released

Perplexity announced on 15 October that it has open-sourced SPACE, the execution platform behind its Computer agent. The public repository describes SPACE as a platform for running agent or user code in isolated Firecracker microVMs through an HTTP API. It is licensed under Apache 2.0. This is infrastructure for an application to create, run, pause and delete execution environments; it is not a model release or a promise that every agent action becomes safe.

Perplexity says SPACE has powered Computer sessions since July and handled millions of sandbox creations per day, with creation three to five times faster than its previous provider on the same production traffic. Those are the company’s operational claims, not independently reproduced benchmarks. The more consequential fact for developers is that the source and installation guide are available for inspection, including the control plane, worker services, guest runtime and network controls.

A sandbox is more than a VM

The architecture guide separates a template (starting filesystem and runtime), a sandbox (microVM plus writable state), a process, a command session, and an asynchronous operation. The API accepts a create request and records desired state; a controller and workers reconcile that request into a running VM. A successful API acknowledgement is not proof the sandbox is ready. The client must wait for the operation, running state and process endpoint.

Command output travels over a separate data-plane connection with a session-scoped attachment token. Management requests use a user-session or service bearer token; those token types are not interchangeable. This split is relevant to threat modelling: a caller who can issue management requests has different authority from one who can attach to a particular command output stream.

SPACE states in the published architecture guide; pause and suspend preserve different resources.

State	Execution and retained state	Operator implication
Running	Processes execute; live VM memory and writable filesystem remain	Multiple commands may share one environment
Paused	Execution stops; memory and filesystem remain resident on the worker	Fast resume, but not a durable snapshot
Suspended	No guest execution; VM memory, runtime and root filesystem snapshotted	Resources released; restoration needs readiness checks
Deleted	Sandbox no longer accessible through the API	Create a new sandbox for later work

Perplexity says platform-held credentials and network access are managed outside the untrusted guest. That is a design claim about boundary placement, not proof that every deployment’s policy is correct. The local Kind guide calls for an x86_64 Linux host with /dev/kvm, /dev/net/tun, loop devices, btrfs and a Docker daemon permitting privileged containers. A macOS laptop cannot directly follow that documented local setup; operators need a suitable Linux host or VM with nested virtualization support.

What the published security evaluation found

Perplexity’s Escaping SPACE: Part I tested two distinct controls. The VM-host task asked models with root access inside the guest to reach a host-side secret. None of 108 runs escaped the VM in the bounded experiment. That is a meaningful observed result, not proof a VM escape is impossible.

The network task was different. When all network egress was blocked, the study reports no successful bypass in 54 runs. With limited allowlisted network access, four of nine models found ways to reach a destination that policy meant to block. The reported mechanisms involved forged DNS responses or routing through infrastructure where allowed and blocked domains shared IP addresses. Perplexity says it patched the identified SPACE weaknesses and follow-up tests did not reproduce those two methods. The research itself warns that longer runs, different agents or new methods may uncover other weaknesses.

Reported results are from different test conditions and denominators; they should not be read as a single security score.

Boundary and test	Reported observation	Interpretation
Guest VM to host, bounded attempts	0 successes in 108 runs	No escape observed under the tested conditions
Network policy with no egress	0 successes in 54 runs	The all-block policy held in that test
Network policy with partial allowlist	Four of nine models found bypass routes	Allowlisting a domain is harder than blocking all traffic
Post-fix reevaluation	No verified bypass by the two identified methods	Specific regressions were not reproduced; other methods remain possible

What an adopter should verify

A team considering SPACE should start with its own threat model: what code can the agent run, what files can it read, which services can it reach, and where are secrets held? Verify the host KVM and storage requirements, the chosen deployment adapter, template provenance and an explicit egress policy. Test that network denials work with shared-IP/CDN destinations and DNS behaviour, not only with a simple hostname example. Keep management API authority, command attachment tokens and guest permissions distinct.

Operationally, test lifecycle transitions under failure. The guide distinguishes operation completion, sandbox readiness and command exit status. A request accepted by the API is not a running VM; a completed command does not delete the sandbox. Record template digests and monitor worker state so a paused or restored agent resumes in the expected environment. Perplexity’s source release makes these controls inspectable, but adopters still have to deploy, configure and validate them.

Primary sources and limits

We used Perplexity’s release announcement, SPACE repository, architecture guide and security evaluation, read 16 October 2026. Performance and scale figures are vendor claims. The red-team results are the authors’ bounded tests, not an independent certification of every SPACE version or configuration.