Perplexity has open-sourced SPACE, the sandbox platform that runs every task in its Computer agent, giving developers a production-tested way to execute model-generated code inside isolated Firecracker microVMs. The Rust code, documentation and deployment examples are available under the Apache 2.0 license.
This is infrastructure rather than a new AI model. Applications call SPACE through an HTTP API to create Linux environments, run commands, stream output and manage long-running workspaces. Perplexity says the platform has powered all Computer sessions since July and now handles millions of sandbox creations a day.
The release is unusually useful because it arrives with evidence of where the boundary held and where it did not. In Perplexity’s red-team evaluation, nine frontier models failed to escape a guest VM in 108 attempts. Four models did, however, bypass restricted network access before Perplexity changed the gateway. The distinction matters for anyone treating a microVM as the complete answer to agent security.
What Perplexity released with SPACE
SPACE is a self-hosted sandbox control plane. A template supplies the starting filesystem and runtime configuration; each sandbox gets its own microVM and writable filesystem. Processes launched in one sandbox share that environment, while other sandboxes remain separate.
The application that uses SPACE controls the workload and decides which results to keep. SPACE handles the execution environment, lifecycle, process sessions and output connection. Its management and command paths are deliberately separate: the API records desired state, while a data-plane connection carries process output using a session-scoped attachment token.
That design supports more than short, disposable code snippets. A running environment can execute multiple commands. Pausing preserves its memory and filesystem on the worker, while suspending creates a snapshot of memory, runtime state and the root filesystem so the active VM resources can be released. A sandbox can then be restored or branched without asking the model to reconstruct its state from conversation history.
Firecracker provides the VM wall, but SPACE adds the operating layer
Each SPACE workload runs inside a Firecracker microVM, the lightweight virtualization technology developed for services including AWS Lambda and Fargate. Unlike an ordinary container, a microVM gives the workload its own guest kernel. The host uses Linux KVM for hardware-assisted isolation.
SPACE adds the components an agent platform needs around that VM: templates, snapshots, network policy, credential delivery, command streaming, warm pools and lifecycle recovery. Perplexity keeps platform-held credentials outside the guest, allowing a workload to connect to an approved service without placing the reusable secret in the environment where agent code can read it.
The architecture can run with Kubernetes or manage workers directly. The public installation guide uses a local Kind cluster and the repository includes an AWS EKS reference deployment. The current setup is not a desktop installer: it requires an apt-based x86_64 Linux host with KVM, /dev/kvm, /dev/net/tun, loop devices, btrfs and a Docker daemon that permits privileged containers. A virtualized host must expose nested virtualization. The guide explicitly says the setup does not run directly on macOS.
That requirement makes SPACE more relevant to platform teams building hosted coding, browsing or data agents than to an individual looking for a one-command local sandbox. Developers already using E2B can evaluate a compatibility wrapper, but Perplexity documents a tested contract rather than claiming complete API equivalence.
The red team could not cross the VM boundary
Perplexity’s Escaping SPACE evaluation gave nine AI models root access inside guest VMs. The models were asked either to retrieve a secret stored on the host or reach a callback destination blocked by the network policy. Some runs also supplied SPACE’s source code and partial internet access for package repositories and Perplexity Search.
None of the 108 VM-to-host escape attempts succeeded. That result covered conditions with and without source access and with either no network or limited network access. It is meaningful evidence for the Firecracker boundary under the tested configurations, though it is not proof that every deployment or future version is escape-proof.
The network tests produced a different result. No model reached the callback in 54 fully disconnected runs, but four models bypassed the partial-network policy in 11 of 54 attempts before remediation. Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber and Kimi K3 found routes through one of two weaknesses.
How the agents bypassed the network allowlist
The first method exploited DNS attribution. SPACE’s gateway observed DNS responses to learn which IP addresses belonged to allowed domains. A guest running as root could inject a forged response that appeared to come from the external resolver, mapping an allowed name such as pypi.org to the blocked callback’s IP address. The gateway trusted that mapping and allowed the later connection.
The second method used shared CDN infrastructure. Allowing an IP associated with PyPI did not mean that IP served only PyPI. Models supplied a different TLS hostname or HTTP host on the same shared address, then used reachable URL-fetching services as intermediaries. In one run, GPT-5.6 Sol found Fastly Fiddle and asked it to retrieve the blocked callback. GPT-5.6 Cyber chained a Taboola image-fetching service with the thum.io screenshot service, downloaded the resulting PNG and used OCR to recover the secret.
Neither path required a Firecracker escape. The agent remained inside its VM while persuading the network gateway to authorize traffic it should have denied. That is why VM isolation and egress enforcement need separate tests.
Perplexity’s fixes move hostname checks across protocol layers
For the forged DNS path, Perplexity added source-address validation with an nftables prerouting rule. Packets arriving from a guest tap interface are now dropped when their source address does not match the address assigned to that VM, preventing the guest from impersonating the external resolver.
The shared-IP fix is more involved. Plain HTTP traffic passes through a relay that verifies the request authority and strips routing metadata that could select another tenant. For TLS, the gateway terminates the connection and checks that the ClientHello SNI and hostname information in HTTP headers are both allowlisted and attributed to the destination IP. Domain-based rules reject protocols that do not expose a hostname the gateway can verify.
Perplexity reran the strongest test condition after applying the changes. The models still attempted the earlier techniques, but forged DNS replies were rejected and alternate hostnames on shared infrastructure no longer reached the callback. No verified network-policy bypass appeared in the evaluable reruns.
Operators can still configure TLS-interception exemptions for destinations that require end-to-end TLS, according to the current architecture documentation. Those exemptions should be treated as deliberate reductions in inspection: they do not grant egress by themselves, but they remove HTTP inspection and credential injection for matching flows. IP-based exemptions are especially broad because they apply regardless of the hostname served at that address.
What self-hosters must secure themselves
Open source makes the platform inspectable; it does not turn the default development deployment into a production security guarantee. Perplexity’s local Kind guide warns that its bootstrap uses development passwords and signing keys, and that inherited cloud or observability credentials can be copied into cluster secrets unless administrators clear them.
A production review should cover at least five separate boundaries:
- Host isolation: harden KVM hosts, restrict privileged services and keep agent workloads away from the control plane.
- Network policy: default to deny, test shared-IP and DNS edge cases, and scrutinize every TLS-interception exemption.
- Credential brokerage: issue short-lived, narrowly scoped tokens outside the guest instead of mounting long-lived secrets.
- Template supply chain: pin template digests, limit trusted artifact buckets and authorize publishers separately.
- Lifecycle integrity: test pause, suspend, restore, deletion and worker-failure behavior so old snapshots or disks do not preserve data longer than policy allows.
Teams should also verify observability from outside the sandbox. Logs used to investigate an agent cannot depend only on storage the agent can modify. Rate limits, resource quotas, command deadlines and incident kill switches need their own tests under deliberate abuse.
How SPACE differs from Microsoft’s agent containers
TechsCurrent recently covered Microsoft Execution Containers, which offer a shared policy format across process containers, Windows sessions, WSL and an experimental microVM backend. MXC is aimed partly at agents acting on managed Windows PCs.
SPACE starts from a different operating model: hosted Linux execution environments managed through an API, with Firecracker microVMs as the sandbox unit. It is a better fit for a service that must create large numbers of stateful agent workspaces, suspend them and restore them later. MXC’s process and desktop-session backends address lower-overhead and on-device workflows that SPACE’s current infrastructure does not target.
Both projects point to the same architectural change. Model refusals and prompt rules cannot be the only controls around agents that install packages, run shell commands and use credentials. The enforceable boundary has to sit outside the model, and every permitted file, network route and tool remains part of the agent’s effective authority.
What to test before adopting SPACE
- Begin with a disposable Linux host. The local setup needs privileged Docker, KVM and network devices; do not start on a machine that holds production credentials.
- Run the documented smoke tests. Verify template publication, worker readiness, API authentication and command streaming before adding an agent.
- Use fake secrets for escape testing. Give the guest root, source access and enough time to search for indirect routes. Test the VM and network boundaries separately.
- Record exact versions and template digests. An evaluation is only meaningful if the platform, guest image and policy can be reproduced.
- Exercise state transitions. Confirm what survives pause, suspend, restore, crash and deletion, including files written immediately before failure.
- Audit allowed domains as shared infrastructure. A hostname allowlist is not enough if enforcement later collapses the decision to an IP address.
- Keep a removal path. An operator should be able to revoke credentials, cut egress, terminate running sandboxes and invalidate retained snapshots without relying on the agent.
SPACE’s strongest contribution is not a claim that Perplexity has solved agent containment. It is a substantial, inspectable implementation paired with test results that show a real microVM boundary holding while a separate network boundary failed. For teams building agents that execute untrusted code, that is a more useful starting point than a generic promise of sandboxing.
Sources: Perplexity’s open-source announcement and security evaluation; the SPACE repository, installation guide and architecture documentation; and the Firecracker project.
