Long-running AI agents create an infrastructure problem that ordinary code sandboxes were not designed to solve. The agent needs enough freedom to install software, execute code, manipulate files and communicate with external services, yet the environment doing that work must be treated as potentially hostile. It also has to remain useful after hours of execution, pauses, machine failures and restarts.
Perplexity’s answer is SPACE, short for Sandboxed Platform for Agentic Code Execution. A detailed July 16 analysis by Karo Zieminski highlighted the runtime behind Perplexity Computer, while Perplexity’s own technical introduction to SPACE describes the system as the sandbox platform it built after deciding that existing options forced unacceptable trade-offs among functionality, efficiency and security.
The architecture matters beyond Perplexity. Agentic search is moving from generating answers to operating computers, handling private files and maintaining tasks over hours or days. In that environment, the sandbox is no longer a background implementation detail. It becomes part of the trust boundary that determines how much autonomy an agent can safely receive.
SPACE is not Perplexity Spaces
The naming can cause confusion. SPACE is the execution runtime behind Perplexity Computer; it is not the former Perplexity Spaces collaboration product. Perplexity has since evolved Spaces into Projects, its shared workspace system for persistent files, memory and connectors.
SPACE solves a different problem. It determines where agent code executes, how that environment is isolated, how state survives after a sandbox disappears and how credentials and network access are controlled.
Zieminski’s July article reported that all Computer sessions were running on SPACE by July 15. Perplexity’s subsequent official material says SPACE is live in Computer for all users and has supported millions of sandbox creations and tens of millions of reconnects over measured periods.
The sandbox is disposable; the session is persistent
The central architectural idea is deceptively simple: Perplexity does not make the sandbox itself the durable object. The sandbox can remain ephemeral while the session persists.
SPACE creates sandboxes only for as long as they are needed to execute code, interact with files or perform other work. When a task is finished, the sandbox and its contents can be destroyed. For work that must survive longer, SPACE wraps the execution environment in a session that can be paused, resumed or branched.
This separation resolves a basic tension in agent infrastructure. Security benefits from disposable execution environments because compromised state does not need to live indefinitely. Users, however, expect an agent working on a multi-hour project to remember what it has already done. SPACE tries to provide both properties rather than choosing one.
Rolling snapshots turn an ephemeral VM into a durable workflow
Persistence comes from rolling snapshots. Perplexity says SPACE can capture the full session state, including live memory and files, as often as once per minute and retain the ability to go back in time for up to a week.
That means resuming a task does not require reviving the same physical sandbox. SPACE can restore the latest snapshot on another machine and continue from the preserved state. Pausing becomes stopping the current environment; resuming becomes restoring its snapshot.
The same mechanism enables forking. A single snapshot can be restored into multiple sandboxes, after which those branches can diverge independently. For agents, that opens the possibility of exploring alternative approaches without forcing every branch to share one mutable environment.
Every task executes inside a Firecracker microVM
At the innermost layer, SPACE uses Firecracker microVMs. Each task receives an isolated guest environment with its own operating system rather than simply running as an ordinary process alongside other agent workloads.
VM isolation creates a stronger boundary between the code the agent controls and the host infrastructure. Even if an agent has substantial privileges inside its guest environment, those privileges are not supposed to extend to the host or neighboring sandboxes.
Perplexity has begun testing that assumption adversarially. In a published evaluation, nine AI models were given root access inside SPACE guest VMs and asked to obtain a secret from the host. Perplexity reported no VM-to-host escape across 108 runs. The company separately found network-policy bypasses under limited-network conditions, patched one implementation weakness and emphasized that VM isolation and network confinement must be evaluated as distinct boundaries.
The Space Daemon keeps guest-to-platform communication narrow
Inside the sandbox, the Space Daemon is the process responsible for communicating with Perplexity’s control plane. Operational instructions such as start, pause and snapshot commands travel through that controlled channel.
This design limits the number of paths through which the guest can interact with the surrounding platform. Rather than exposing broad host functionality inside the VM, SPACE keeps orchestration behind a narrow interface that can be monitored and audited.
The principle is important for autonomous agents: useful execution freedom inside the sandbox should not imply unrestricted control over the infrastructure outside it.
Credentials deliberately stay outside the sandbox
One of SPACE’s strongest design choices is that platform-managed credentials are not placed inside the environment where untrusted agent code runs. Perplexity’s documentation says credentials are delivered from outside the sandbox only at the moment they are needed.
If an agent needs temporary access to a connected Google Account, for example, SPACE can mediate the authentication flow without exposing the underlying credential to the guest. Perplexity describes the objective plainly: a compromised agent should not inherit a reusable vault of secrets simply because it compromised its own execution environment.
This reverses a common implementation pattern in automation systems, where API keys or tokens are injected into environment variables and become visible to anything running inside the workload. For an agent capable of installing software and executing arbitrary commands, that convenience creates an obvious escalation path.
OAuth permissions still define what the agent is allowed to reach
External credential handling does not mean the agent receives unlimited access to a connected service. Perplexity says Computer begins with no connector access and relies on OAuth permissions to define what it can use.
For enterprise deployments, administrators can disable entire connectors or specific tools within them. That gives organizations a second layer of control beyond the VM boundary: even correctly mediated authentication should grant only the capabilities the task actually requires.
The distinction is important. Sandbox isolation limits what compromised code can do to infrastructure; authorization limits what an otherwise functioning agent can do with external services.
Network confinement is a separate security boundary
SPACE controls outbound traffic at the node level rather than trusting software inside the sandbox to police itself. The goal is to prevent a compromised guest from reaching destinations outside the scope permitted for the task.
Perplexity’s own red-team work demonstrates why this layer cannot be taken for granted. In tests where network access was fully blocked, the company reported no successful bypasses. When narrowly approved access to package repositories was permitted, however, four of nine tested models initially found ways around the intended restrictions using techniques involving DNS spoofing or shared-IP routing.
Perplexity says it fixed the DNS issue through source-address validation and adjusted defenses around shared-IP behavior, after which its reevaluation produced no verified bypass. The episode is more useful than a blanket claim that the sandbox is impenetrable: it shows that capable agents can actively probe infrastructure assumptions and that egress enforcement needs independent testing.
SPACE is organized into three security layers
Perplexity describes SPACE as a three-layer architecture. The Control Plane receives requests through a common API, tracks state, routes work to available backends and decides when sandboxes should be created or destroyed. Node-level services handle functions such as networking and credential delivery outside the guest. The in-sandbox layer contains the Firecracker microVM and Space Daemon.
Separating those responsibilities reduces the amount of privileged machinery exposed to agent-controlled code. It also supports backend portability: Perplexity says the Control Plane can route the same workload across different infrastructure while preserving a common interface.
The broader architectural principle is separation of concerns. The component executing arbitrary agent code should not also own every credential, network policy and lifecycle decision.
Snapshots make long-running agents resilient to infrastructure changes
Rolling snapshots are not only a convenience feature. They decouple task continuity from a specific machine.
If a sandbox needs to move to another backend, SPACE can restore the session state rather than requiring the original VM to remain alive. This can improve infrastructure utilization because idle long-running sessions do not necessarily need to occupy active compute indefinitely.
It also creates operational flexibility for agent platforms. Hardware can fail, instances can be reclaimed and workloads can be moved without forcing the user to restart a complex research or coding task from the beginning.
Perplexity is designing SPACE to run across different backends
Perplexity says SPACE was built to be backend-agnostic. Its Control Plane can decide where to route a sandbox, while the session abstraction preserves continuity above the underlying machine.
The company has reported an early test on NVIDIA Vera CPU in which Computer-style workflows ran roughly 1.5 times faster than its production reference and concurrent sandboxes started as much as 1.9 times faster. Those figures are Perplexity’s early internal results rather than independent benchmarks, but they illustrate why backend portability matters: the runtime can take advantage of different hardware without redefining the agent product.
Perplexity has also described ambitions for SPACE to span Linux microVMs, Windows guests and local machines. Its separate Portable Computer initiative already reflects the broader direction toward running agent workloads on user-controlled hardware while retaining sandboxed execution.
Enterprise customers can bring their own encryption keys
SPACE surrounds its untrusted sandbox with tenant separation and encrypted storage in addition to VM, credential and network controls. For enterprise customers, Perplexity says the platform supports customer-managed encryption keys.
If an organization revokes its key, new sandboxes protected by that key cannot boot and previously encrypted customer data can no longer be decrypted. Perplexity also says SPACE is designed to operate on-premises and fully offline for environments where data cannot leave controlled infrastructure.
Those capabilities push the sandbox beyond consumer-agent isolation into enterprise infrastructure governance, where control over encryption, identity and deployment location can be as important as model capability.
The security model assumes the agent itself may be compromised
The most useful conceptual shift in SPACE is that the sandbox is treated as untrusted by default. Security does not depend on assuming that the model will always follow instructions or that every package it installs will be benign.
Instead, Perplexity attempts to constrain the blast radius externally. Credentials stay outside. Network rules live outside. Tenant boundaries surround the guest. The VM limits access to the host. Persistent state can be restored from snapshots rather than trusting one environment forever.
This is increasingly necessary as agents consume untrusted web content. Prompt injection, malicious documents and compromised dependencies can all influence an agent after the user has delegated a task. The runtime therefore has to remain defensive even when the agent itself is behaving unexpectedly.
Long-running research agents need infrastructure persistence, not only model memory
Agent persistence is often discussed as a model-memory problem, but SPACE highlights another layer. A model can remember facts and still lose the files, installed packages, intermediate databases and process state created during a task.
Rolling snapshots preserve that computational context. An agent conducting a large research project can maintain artifacts and executable state independently of whichever model call happens next.
This complements the direction NetContentSEO has documented in persistent information agents that keep working beyond a single query. As AI systems become longer-lived, the infrastructure that preserves and isolates their work becomes part of the discovery stack.
Security can determine how much autonomy a search agent receives
For publishers and search marketers, VM architecture can sound far removed from visibility. It becomes relevant when search products move from retrieving pages to acting on information.
An agent that can safely maintain state, execute arbitrary code and use scoped credentials can perform much deeper workflows than a chatbot limited to generating text. It can fetch data, transform files, run analyses, revisit previous work and interact with connected systems.
That expands the distance between retrieval and the final user-facing answer. A source may enter an agent’s workflow early, be processed alongside many other artifacts and influence an action much later.
Perplexity Computer is becoming an execution environment, not merely an answer interface
Perplexity has described Computer as an environment with a filesystem, shell, browser, web access and connectors rather than simply another chat interface. SPACE provides the containment layer underneath those capabilities.
The result is a different architecture from conventional search. The visible prompt can initiate a durable session, the session can create disposable computers, those computers can execute code and access permitted services, and the entire workflow can be restored or forked through snapshots.
For agentic discovery, that means the unit of work is no longer necessarily a query-response pair. It can be a persistent computational process.
The sandbox is becoming part of the AI product
Perplexity built SPACE because long-running agents create requirements that short-lived code execution does not. The sandbox has to be disposable without making the work disposable. It has to give the agent useful tools without handing it permanent credentials. It has to allow network access without treating the internet as unrestricted. And it has to isolate arbitrary code strongly enough that a compromised guest does not become a compromised platform.
SPACE addresses those tensions with Firecracker microVMs, rolling snapshots, external credential delivery, node-level network controls, tenant separation, encrypted storage and a control plane that can move sessions across backends.
No sandbox architecture eliminates every risk, and Perplexity’s own network-bypass experiments demonstrate that containment requires continuous adversarial testing. But SPACE shows where serious agent infrastructure is heading: persistence is moving above the VM, while trust is moving outside it.
That is the sandbox behind Perplexity Computer—and increasingly, the kind of runtime required when an AI system stops merely answering questions and starts operating a computer for you.