Perplexity announced the open-source release of SPACE on October 15, 2026, according to its official news listing. For teams evaluating code-running agents, the useful question is not simply whether a sandbox exists. It is which boundaries the runtime enforces and what remains the operator's responsibility.
What developers can inspect
The SPACE repository describes an Apache 2.0 platform built around isolated Firecracker microVMs. Applications use an HTTP API to create Linux environments, run commands and retrieve output. SPACE supplies the execution environment; the application still chooses the work and retained results.
This makes the release relevant to teams building a code-running workspace, rather than teams merely selecting a conversational model. Our assessment: inspectable infrastructure is valuable when the deployment decision depends on where code runs, not only how well a model answers.
Host isolation is not network confinement
In its release announcement, Perplexity reports no VM-to-host escape in 108 attempts, while acknowledging network restriction bypasses. It says it fixed the weaknesses and that neither identified method worked in follow-up testing. These are company-reported findings, not a guarantee against future attacks.
The company also says it manages platform-held credentials and network access outside the untrusted sandbox. Our interpretation is that teams should review execution isolation, outbound access and credential handling as separate controls. A successful host-isolation test does not answer every question about what an agent can contact.
State recovery needs precise definitions
The architecture documentation distinguishes pause from suspend. Pause retains memory on the worker and is not a durable snapshot. Suspend snapshots memory, runtime state and the root filesystem while releasing active VM resources.
The same documentation separates an accepted lifecycle request from readiness, and readiness from a command's exit status. Host services still need privileges to manage VMs, networking and storage. These distinctions should shape both failure testing and operational ownership.
Local evaluation has infrastructure prerequisites
The local installation guide requires an apt-based Linux x86_64 host with KVM, specific device access, btrfs support and Docker capable of privileged containers. Its instructions do not run directly on macOS. This guide uses a Kind cluster; it should not be read as proof that every SPACE deployment requires Kubernetes.
Importantly, the guide warns that the local deployment uses development passwords and signing keys. It says to keep the environment private and avoid production credentials.
A bounded next step
We recommend evaluating a disposable workflow with synthetic files before connecting business systems. Record separately whether commands complete, forbidden destinations remain blocked and suspended work restores correctly. Assign an owner for host patching and configuration review before expanding the trial.
The practical value of this release is the ability to inspect and test a runtime. Treat adoption as an engineering decision with explicit acceptance criteria, not as a security certification supplied by an open-source license.