On October 15, 2026, Perplexity released SPACE, the code-execution platform behind its AI agent Computer, as open source. The sandbox infrastructure, which has powered every Computer session since July, is now available under the Apache License 2.0, so outside developers can inspect, modify, and use the source code. What matters about this release is not just that it offers an environment for running code. It also lets developers examine how the platform restricts network traffic when an AI model attempts a risky action, and how it suspends and resumes long-running work. That said, the VM isolation Perplexity confirmed in its own tests and the platform's ability to block unauthorized network traffic need to be evaluated separately.
What the AI agent execution platform SPACE can do
SPACE stands for "Sandboxed Platform for Agentic Code Execution." It runs code inside lightweight virtual machines (microVMs) built on Firecracker. Applications create Linux environments through an HTTP API, then run commands and retrieve results. SPACE can also pause running processes and resume them later. SPACE itself is implemented in Rust, but applications that use it do not need to embed a Rust library.
According to Perplexity, the company moved in July from an external commercial sandbox service to its own SPACE platform. What has been released is the infrastructure that supports Computer's code execution, not the model that decides what work the AI does. The official GitHub repository also explains that the application decides what to run and which results to keep. Developers are spared the burden of building a sandbox from scratch, but they still have to design the specific work and manage the outputs themselves.
SPACE gives each sandbox its own guest kernel. The kernel is the core of an operating system, and separating it per virtual machine reduces the risk that a problem inside a guest environment spreads to the host or to other sandboxes. In addition, outbound network traffic is controlled through a gateway, and credentials managed by the platform are kept outside the VM. When a sandbox connects to a permitted service, the necessary credentials are attached along the communication path, so secrets never need to be stored in the environment the AI agent operates. The design aims to limit damage through constraints on the execution environment even if an AI model fails to follow safety instructions, and the release lets third parties verify that mechanism.
Zero VM escapes in 108 attempts, but restrictions on network traffic were bypassed
In its own security evaluation, published on September 23, Perplexity reported that AI models attempting to escape from the VM to the host succeeded in none of 108 trials. However, when some outbound traffic was permitted in the pre-fix environment, network restrictions were bypassed in 11 of 54 trials. In other words, even though the models could not break out of the VM into the host, they were sometimes able to reach external destinations that should have been blocked.
The tests gave nine AI models root (administrator) privileges inside the VM and set them two different tasks. One was to obtain a host-side secret from within the VM. The other was to reach a forbidden destination and retrieve a verification value. Conditions were combined, such as whether the model could view the source code and whether external traffic was fully blocked or partly allowed, with each configuration tested three times. Across the two tasks, the total came to 216 trials. The results for the pre-fix environment are as follows.
| Test target | Pre-fix test conditions | Successful trials |
|---|---|---|
| VM-to-host escape | All configurations, varying source-code access and network conditions | 0 of 108 |
| Network restriction bypass | External traffic fully blocked | 0 of 54 |
| Network restriction bypass | Some traffic allowed, such as package downloads | 11 of 54 |
These results compare different tasks, so the success rates cannot be directly compared under identical conditions. Even so, it is significant that a weakness not seen when all external traffic was blocked emerged once traffic needed for tasks such as installing software was permitted. Real AI agents often need to communicate with external services, so verifying safety only with all traffic cut off is not enough.
Two main techniques were used to bypass the network restrictions. One was to spoof DNS responses so that the mapping between an allowed domain name and the actual destination IP address was misread. The other was to go through a different service that shared an IP address with an allowed service. On CDNs, multiple websites can be hosted on a single IP address, so allowing traffic based on the destination IP address alone may fail to properly restrict which site is actually accessed.
In response, Perplexity added a check of the source IP address of packets sent from the VM, along with a mechanism that verifies whether the destination hostname specified in HTTP or TLS matches the allowlist and the DNS mapping. In the re-evaluation after the fix, the plan was to give the same nine models access to the source code and some external traffic, testing each three times. Two trials ended with errors from the model provider or the network, but in the trials that could be evaluated, no bypass of the restrictions using the two problematic techniques was observed. However, this is the result of an in-house test of whether the fix works against the identified weaknesses. It does not guarantee complete safety, including against unknown attack methods.
Pause versus suspend: supporting long-running work
SPACE can also save and restore the state of an execution environment so AI agents can keep working for long periods. However, "pause" and "suspend" differ in what state is saved and what compute resources are needed. Pausing keeps memory contents on the worker node, whereas suspending saves memory, execution state, and the filesystem and then releases the resources used by the running VM. For tasks that wait for human approval or are interrupted for a long time, choosing the right way to stop is therefore important.
These mechanisms are described in Perplexity's Architecture guide and in a design explainer published in July. What is saved and the conditions for recovery are summarized below.
| Operation / storage method | State saved | Conditions for waiting and recovery |
|---|---|---|
| Pause | Memory and files kept on the worker node | Memory stays resident; no persistent snapshot is created |
| Disk snapshot | Filesystem at a specific point in time | Can be used to roll back files, but does not save the full contents of running memory |
| Suspend | Memory, execution state, and a snapshot of the root filesystem | Releases running VM resources; can be restored once the necessary saved data has finished transferring |
For example, undoing an accidental file edit and resuming a computation from exactly where it left off require different information to be saved. Using pause as a substitute for a persistent backup could mean the needed state cannot be restored if the worker node fails. The guide also explains that even when a file write is reported as complete, the data is not necessarily retained after a crash or host failure. Applications must choose a storage method suited to the work and confirm that the operation has actually completed.
To reduce the cost of saving state, SPACE uses btrfs copy-on-write (CoW). By sharing existing data and storing only the parts that change, it avoids copying the entire environment each time. It also uses a "warm pool" that prepares frequently used environment templates on disk in advance, shortening the wait when creating new sandboxes.
Perplexity says that when it introduced SPACE and ran a side-by-side comparison with a previous commercial sandbox service using the same production traffic, median sandbox creation latency fell from 185 milliseconds to 60 milliseconds. The 90th-percentile value also improved, from 447 milliseconds to 89 milliseconds. The name of the vendor used for comparison has not been disclosed. These figures were measured in a real operating environment, including advance preparation of templates, and do not guarantee the same startup times in other environments.
Deployment requires a Linux environment and operational readiness
The published local installation instructions assume an apt-based x86_64 Linux host with KVM available. In addition to btrfs and virtual network devices, they require permission to run privileged containers in Docker. The official procedure uses Kind to build a local Kubernetes cluster and installs SPACE on top of it. It is not a setup for installing directly on macOS.
That said, this is the installation method the official guide presents, and Kubernetes is not strictly required to use SPACE. SPACE also offers a configuration in which workers are managed directly. The official local environment uses development passwords and signing keys, so the guide warns users not to expose the environment externally and not to bring in production credentials. Even though the source code is public and can be freely deployed, the sample configuration cannot simply be applied to a production environment as is.
Efforts toward cloud deployment are also under way. According to Perplexity's announcement, CoreWeave and Akamai are testing and launching SPACE in their respective cloud environments and collaborating toward offering it to customers. Crusoe is also named as a partner that will incorporate SPACE into its Managed AI Services. However, this does not mean general availability for all customers has been completed, and the actual terms of use and the scope of operational responsibility need to be confirmed against each company's offering.
For developers considering SPACE, the key questions are whether the security restrictions work properly even when the external traffic an AI agent needs is allowed, and how much work can be restored after an interruption or failure. With the open-sourcing, third parties can now verify these mechanisms from the source code and try them in their own environments. If its practicality in both network control and state management is confirmed, SPACE could serve as a foundation for running long-lived agents safely and reliably without relying solely on instructions given to the AI model.