Perplexity has introduced SPACE, a new sandbox platform engineered to safely unlock the full capabilities of Perplexity Computer’s agentic AI stack while maintaining a high bar for security.
Mea culpa. I’m not a huge fan of agentic AI platforms. Sure, agents are powerful, but I find their security and the platforms that support them to be, shall we say, questionable. That’s why I like Perplexity‘s announcement that going forward, Perplexity Computer will only run its agents on its new sandbox, SPACE.
A sandbox, in this context, is not something your kids play in, but a mechanism that isolates running programs so that failures or exploits are contained and cannot spread to the operating system. In this case, SPACE is designed for long‑running tool‑using agents that need to execute code, manage files, and operate over extended sessions, without exposing underlying infrastructure or sensitive credentials.
SPACE does this by running every Computer task inside a Firecracker microVM sandbox. Firecracker is a virtual machine monitor that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs. It enforces least privilege at a level that goes beyond default operating system security. Each microVM boots its own dedicated Linux kernel with a minimal device model, reducing the attack surface. This minimizes the blast radius if something goes wrong.
To further protect you from bad agents or agents gone wrong, SPACE’s sandboxes only live as long as they’re needed for running code, interacting with files, or other tasks. When the task finishes, the sandbox and everything inside it are destroyed.
For jobs that need to survive restarts, SPACE wraps each sandbox in a session that can be d, resumed, or branched into multiple sandboxes. SPACE does this by using a rolling snapshot technology, which enables context to travel with the work, even though no individual sandbox does. SPACE is now Perplexity Computer‘s dedicated runtime layer. It’s optimized for agents that don’t just answer a single question but carry out multi‑step workflows over time. Instead of treating each interaction as a stateless request, SPACE allows agents to persist context, maintain intermediate artifacts, and coordinate repeated tool calls within a controlled environment. This design targets use cases such as deep research, complex data analysis, and autonomous report generation, where agents may run for minutes or hours, iteratively refining their output.
The Perplexity sandbox also uses a zero‑trust approach. Any code an agent executes is treated as untrusted and potentially adversarial. This is a smart approach. In SPACE, each session gets its own minimal compute environment rather than just a process on a shared host. This approach is meant to reduce cross‑tenant risk and side‑channel exposure and to keep misbehaving code from impacting other workloads.
SPACE also decouples agents from raw credentials and direct network access. When an agent needs to call external APIs or services, it does so through tightly controlled proxies that enforce destination policies and inject scoped tokens on its behalf. Agents never see underlying API keys or long‑lived secrets, and outbound connections can be constrained by origin, destination, and purpose. This makes it easier to figure out what an agent can and cannot do. It also gives operators a clear control plane for risk management and compliance.
According to Perplexity, SPACE is made up of three key layers. These are the Control Plane, which is responsible for orchestrating the sandbox’s lifecycle. It receives all requests through a single API, tracks the sandbox state, and decides in real time which backend to route them to. It determines when a task needs a new sandbox. It also decides when a task is complete, and its corresponding sandbox can be destroyed. Because the Control Plane is stateless and centrally hosted, the same API call works on any existing infrastructure, including a local machine.
Next, there are Node-level Services. These ensure that credentials never pass into the sandbox. Instead, they’re passed in from outside the sandbox only at the precise moment they’re needed. When an agent needs temporary access to a Google account, SPACE can handle the sign-in flow without exposing credentials within the sandbox. Outbound network traffic is also controlled at the node level. A compromised agent can’t reach anything outside its permitted scope.
Finally, the in-sandbox layer consists of the Firecracker microVM. Its SPACE Daemon is the only process that talks to Perplexity’s control plane. It carries operational signals like start, , and snapshot commands.
All these security layers may make you worry that SPACE could be really slow. The company claims it’s fast enough for interactive use. That’s because of its use of caching, Firecracker, and the Btrfs (B-tree filesystem). Btrfs combines a copy-on-write filesystem with integrated logical volume management. This means “sandboxes can be created and restored quickly. Instead of creating a sandbox from scratch each time, we keep a warm pool of pods that already have common templates materialized on disk, and satisfy a request by binding it to a pod whose template already matches.”
By formalizing SPACE as the sandbox platform behind Computer, Perplexity is saying that it views agentic AI as a first‑class architecture rather than a bolt-on feature.
Another way of looking at this approach is to treat AI agents less like chatbots and more like distributed applications that require the same rigor as traditional services. Perplexity is effectively offering a managed runtime for those applications, abstracting away low‑level isolation and security engineering while keeping the surface area where agents can act tightly defined.
This sounds promising to me. By making that runtime a core part of Perplexity Computer, it’s positioning Computer as a trustworthy platform for the next generation of agentic systems.