Perplexity Open-Sources SPACE Sandbox Platform: A Dedicated MicroVM for Every AI Task

Perplexity recently announced the open-sourcing of its internal sandbox platform SPACE, which is used to run every task in Perplexity Computer. According to the official tweet, SPACE allocates a dedicated Firecracker microVM for each agent task and centrally controls credentials and outbound traffic from outside the VM. The project has been open-sourced under the Apache 2.0 license.

What SPACE Is: Task-Level Isolated Sandbox Infrastructure

SPACE is not an end-user product, but rather the underlying execution environment that Perplexity developed while building the Computer feature. Its core design can be summed up in one sentence: one microVM per task.

Traditional agent execution environments often use process-level or container-level isolation, where multiple tasks share the same kernel or network stack. SPACE chooses Firecracker microVMs, meaning each task has its own independent kernel and virtualization boundary, and tasks are separated at the hardware abstraction layer. This choice directly improves fault isolation and security boundaries—malicious code or anomalous behavior in one task can hardly affect other tasks on the same host laterally.

According to the official description, the platform has actually run every task in Perplexity Computer, indicating that it has been tested under real production workloads rather than being a lab prototype.

A Firecracker microVM is a lightweight virtualization solution based on KVM, open-sourced by AWS. It is not a complete virtual machine in the traditional sense; it trims unnecessary device emulation and retains only the minimal feature set required to run containers, thereby compressing startup time to the sub-100-millisecond level and reducing per-instance memory overhead to a few MB. Each microVM has an independent kernel, communicates with the host through virtio devices, and relies on the jailer mechanism for resource and permission constraints. Unlike containers, which share the host kernel, microVMs provide an isolation boundary at the hardware virtualization layer, making it harder for untrusted code to break out to the host or other tenants. Firecracker was originally designed for AWS Lambda and Fargate and has now become a common choice for securely executing untrusted workloads in multi-tenant environments.

The Key to the Security Architecture: Credentials and Traffic Control Outside the VM

The more noteworthy detail of SPACE lies in its security model: credential management and outbound traffic control are both completed outside the virtual machine.

This means that when an agent executes code inside the VM, it does not directly hold long-lived keys. Credentials are injected or proxied by an external control plane, and outbound requests also pass through an external policy layer. This "separation of data plane and control plane" approach is consistent with the principle of least privilege in cloud-native security: even if the agent inside the VM is manipulated by prompt injection, what the attacker can obtain is only a controlled short-term channel, not an exposed API key.

For teams building agent products, this design provides a reference paradigm—security boundaries should not rely solely on the model's own judgment but should be pushed down to the infrastructure layer.

Prompt injection refers to an attacker using carefully crafted input to induce a large language model to deviate from its original instructions and perform operations it should not perform. In agent scenarios, models are often given the ability to call tools, access APIs, or read and write files. Once injected, attackers may use this to steal credentials, initiate unauthorized requests, or move laterally. Because models themselves cannot reliably distinguish instructions from data, defense that relies solely on model judgment is unreliable. The industry therefore advocates pushing security boundaries down to the infrastructure layer—for example, restricting the network egress accessible to agents, using short-term tokens instead of long-lived keys, and enforcing policy validation at an external proxy layer—so that the actual impact can still be constrained even when the model is manipulated.

Why Choose Firecracker

Firecracker is a lightweight virtualization technology open-sourced by AWS, originally designed for Lambda and Fargate and known for fast startup and low memory overhead. SPACE builds its task sandbox on it, striking a compromise between isolation strength and scheduling efficiency.

Compared with traditional virtual machines, microVMs typically start in the sub-100-millisecond range, enough to support task-oriented workloads with high-frequency creation and destruction; compared with containers, they retain stronger isolation. For agent scenarios that need to execute untrusted code, this combination is relatively pragmatic.

Containers and virtual machines differ fundamentally in isolation strength: containers share the host kernel, and if the kernel has vulnerabilities or is misconfigured, the risk of escape is relatively high; traditional virtual machines provide stronger isolation but start slowly and have high overhead. microVMs attempt to strike a balance between the two—retaining the hardware virtualization boundary while compressing startup time and resource usage to a level close to containers. For scenarios such as agent tasks that require frequent creation and destruction and execute untrusted code, microVMs can provide sufficiently strong isolation without dragging down task throughput due to scheduling latency, making them a pragmatic choice.

What Apache 2.0 Open Sourcing Means

SPACE is released under the Apache 2.0 license, allowing commercial use, modification, and redistribution. For the ecosystem, this lowers the barrier for teams to build their own agent sandboxes: they can directly reuse its architectural ideas or adapt it to their own cloud environments.

As a supplement, what is open-sourced is the sandbox platform itself, not the complete product logic of Perplexity Computer. For developers who want to study the question of "how agents can securely execute code," SPACE provides a reference implementation from a production environment.

Apache 2.0 is a permissive open-source license that allows users to freely use, modify, and redistribute software, including for commercial purposes, without requiring derivative works to be disclosed under the same license. It includes explicit patent grant clauses, which to some extent protect users from patent litigation. Unlike copyleft licenses such as GPL, Apache 2.0 does not require modified code to be open-sourced, making it more friendly for enterprise integration. For infrastructure projects, this license lowers the adoption barrier and helps foster a toolchain and community ecosystem around the project.

Signals for the Agent Infrastructure Track

Competition in agent products is extending from model capabilities to execution environments. Whether tasks can run securely and audibly, how credentials are managed, and how outbound traffic is constrained are becoming key to product deployment. By open-sourcing its internal infrastructure, Perplexity both showcases its own tech stack and promotes a set of reusable engineering practices. For teams focused on AI agent security and infrastructure, SPACE is worth following and studying.

Note: This article is based on Perplexity's official tweet and public technical information, and does not include specific performance data that did not appear in the original text.

One-line Summary

Perplexity open-sources SPACE sandbox, allocating a dedicated Firecracker microVM for each agent task with externalized credential control.

Paragraph Summary

Perplexity announced the open-sourcing of its internal sandbox platform SPACE under the Apache 2.0 license. The platform has been used to run every task in Perplexity Computer. SPACE's core design is "one microVM per task," providing each agent task with an independent kernel and virtualization boundary based on AWS Firecracker microVMs, offering stronger fault and security isolation than container-level isolation. Its security model places credential management and outbound traffic control outside the virtual machine, so agents inside the VM do not directly hold long-lived keys; even if prompt injection occurs, attackers can only obtain a controlled short-term channel. Firecracker's sub-100-millisecond startup and low memory overhead make the solution suitable for high-frequency task workloads. What is open-sourced is the sandbox platform itself rather than the complete product logic, providing a production-grade reference implementation for secure code execution by agents.