Featured image: A server rack with multiple server units and storage devices. AI-generated image; not a photograph of the reported event.
Perplexity has open-sourced SPACE, the sandbox platform that powers every task in its Perplexity Computer system. The platform runs each agent task in a dedicated Firecracker microVM, ensuring isolation and security. This architectural choice reflects a growing trend in agentic AI systems: the need for robust, real-world tested isolation layers that prevent unintended access to host systems or sensitive data. Source: marktechpost.com.
What Is Perplexity SPACE?
SPACE stands for Sandboxed Platform for Agentic Code Execution. It allows applications to launch isolated Linux environments via an HTTP API. These environments run commands, install packages, and access services with root privileges, enabling full operational autonomy for AI agents without compromising system integrity.
Each sandbox uses a template to initialize a filesystem. The sandbox is a single instance of that template, with its own VM and writable disk. Multiple commands can run within one sandbox, but each task operates in its own isolated environment. This design supports long-running, stateful workflows—such as code generation, debugging, or web browsing—where agents must persist across multiple steps without affecting other tasks or the host system.
How Does SPACE Ensure Isolation?
Each sandbox runs as a Firecracker microVM with its own guest kernel. This means the host system remains outside the guest’s control, significantly reducing the risk of privilege escalation or lateral movement. Firecracker, a lightweight and efficient virtualization tool, is ideal for agent workloads due to its low overhead and fast boot times.
Outbound network traffic is enforced at the host level. A per-sandbox network gateway applies egress policies to every connection. This ensures that agents cannot access unauthorized services or data, even if they are granted root access within the sandbox. The gateway acts as a firewall, validating every outbound request against a defined policy before allowing it to proceed.
Credentials are never injected into the guest VM. Instead, they are delivered at the network layer through a credential store that operates on the host. This design prevents credential leakage and allows for fine-grained access control via hierarchical scoping, rate limiting, and audit logging. According to Perplexity’s July engineering post, the credential store supports policies that restrict access based on user roles, task types, or time-of-day, enabling dynamic and context-aware security.
Architecture and Operation
SPACE is built around four core components: a PostgreSQL-backed API, controllers, worker services, and a data plane.
- The API handles incoming requests and manages state, providing a RESTful interface for launching and monitoring sandboxes.
- Controllers manage workflows and routing, ensuring that tasks are directed to the appropriate execution environment.
- Worker services handle VM lifecycle, networking, volumes, templates, and credentials. These services operate in the background, managing the creation, destruction, and state transitions of sandboxes.
- The data plane manages execution and output streams, allowing real-time feedback from agent tasks through server-sent events (SSE).
Each root filesystem is created using btrfs copy-on-write. This ensures that changes are tracked and isolated, preventing unintended side effects across sandboxes. For instance, if an agent installs a package or modifies a file, those changes are confined to that sandbox and do not affect other running instances or the host system.
State Management and Lifecycle
Sandboxes move through four states: running, paused, suspended, and deleted.
- Paused: VM memory remains in memory but is not durable. This state does not save runtime state, making it suitable for temporary halts during long-running tasks.
- Suspended: The VM’s memory, runtime state, and root filesystem are snapshotted. Active resources are released, allowing the system to conserve memory and disk space.
- Idle default: After 6 hours of inactivity, sandboxes suspend automatically. This helps optimize resource usage in environments where agents may not be actively running.
For faster task launches, Kubernetes deployments use warm pools of pre-booted sandboxes. These pools maintain a set of sandboxes in a ready state, reducing the time needed to start a new task. Single-node setups rely on base snapshots instead, which are stored and reused for consistent initialization.
In production, the 90th-percentile create latency dropped from 447 ms to 89 ms. This improvement demonstrates the efficiency of SPACE in real-world deployments. All 100% of Perplexity Computer sessions run on SPACE, indicating its reliability and integration into core operations.
Security Testing and Red-Team Results
Perplexity conducted a red-team test involving 9 frontier AI models with root access inside the guest. The study ran 216 runs across two tasks and four settings, simulating realistic attack scenarios.
- 0 of 108 runs succeeded in escaping to the host-side secret. This result confirms that no model could access or extract sensitive host credentials.
- 0 of 54 runs bypassed network policies in full network scenarios. This shows that egress enforcement is effective under complete network isolation.
- 11 of 54 runs succeeded in partial-network bypasses before fixes. These attacks exploited DNS spoofing and shared CDN IP addresses, indicating vulnerabilities in network policy enforcement under certain conditions.
According to a report from Perplexity’s internal security team, models such as Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber, and Kimi K3 were able to discover bypass paths using DNS spoofing and shared CDN IP addresses. The team noted that these attacks were not due to flaws in the VM itself, but rather in how network policies were implemented under partial isolation.
Following the test, Perplexity implemented source-address validation using nftables. The network gateway now terminates TLS and validates both SNI and HTTP host headers against a strict allowlist. In a follow-up retest, no model produced a verified bypass, confirming the effectiveness of the update.
Additionally, the same research team evaluated 10 third-party platforms and found that 8 exhibited at least one network-policy bypass. Perplexity disclosed these findings directly to each affected vendor, emphasizing its commitment to transparency and collaborative security improvements.
Deployment and Requirements
SPACE is designed to run on a Linux x86_64 host with KVM, /dev/kvm, /dev/net/tun, loop devices, and btrfs support. These components are essential for virtualization, network interface access, and filesystem operations. The system does not support macOS, and deployment requires a native Linux environment with kernel-level access.
It performs best in a local Kind cluster. When running inside a VM, nested virtualization is required, which adds complexity but enables broader deployment flexibility. Teams already using E2B can leverage the E2B Compatibility Wrapper, which has been tested with the e2b==2.21.1 Python package. A reference AWS EKS deployment is available in the repository, offering a production-ready blueprint for enterprise use.
Comparison with Other Open-Sourced Sandboxes
SPACE differs from other open sandboxes by combining strong isolation with real-world performance and security testing. Unlike some lightweight sandboxes that prioritize minimalism or theoretical security, SPACE has been validated in live production environments with zero successful escapes in red-team tests after mitigation.
Its design includes production-level features such as egress policy enforcement, credential injection at the network layer, and robust state management. These features make it particularly suitable for enterprise-grade AI agent deployments where security and stability are paramount.
Why This Matters for Developers
For teams building coding or browsing AI agents, SPACE offers a production-tested, self-hostable isolation layer. It enables secure, scalable agent execution without relying on third-party infrastructure. Developers can deploy and manage agent tasks with confidence in security and stability.
Limitations and Open Questions
SPACE does not support macOS. It requires a Linux x86_64 host with specific kernel-level access, which may limit adoption in certain development environments.
While egress policy enforcement is strong, the red-team test showed that some models could bypass policies under partial network conditions before fixes. This underscores the importance of continuous monitoring and iterative security improvements.
Performance improvements are notable, but full scalability in distributed environments remains unverified beyond Kubernetes use cases. Future work may explore integration with container orchestration platforms and cloud-native environments.
The full technical details, including versioning and deployment guides, are available on GitHub. The red-team report is also published for transparency.
GitHub repository | Versioning documentation | Perplexity official post
SPACE represents a practical step forward in secure AI agent execution. It shows how open-source tools can deliver real-world security and performance in agentic AI systems.
