Making SPACE: Secure and Efficient Runtimes for Long-Running Agents

As agentic workflows grow longer and more autonomous, the environments that AI agents operate in matter as much as the models driving them. Agents need to do real work, such as running code, editing filesystems, and executing multi-step tasks over hours or days. Users want agents to have access to the tools and files they need to carry out these tasks, but also need to trust that their systems will stay secure even if agents are compromised. A sandbox is what makes all of this possible: an isolated environment where an agent can operate freely while the host, other tenants, and sensitive credentials stay protected. 

Traditional container-based sandbox approaches aren’t designed for these tasks. They typically assume short-lived, stateless jobs and have the kernel as a single point of failure. In contrast, agent sessions are long-lived and stateful: an agent accumulates hours of context, a working filesystem, and running processes that can't simply be thrown away and reconstructed from scratch. Moreover, the workload inside should be untrusted by default, necessitating stronger security measures. Long-running agent sessions need a substrate that can isolate a hostile guest, preserve its state, and still be operated at scale.

The main challenge in sandbox engineering comes from the tension that often arises between security, functionality, and efficiency. For example: 

• Granting broader access lets an agent accomplish more but exposes more of the system to a workload you don't trust.

• Sharing more between sandboxes makes creation faster but widens the attack surface.

• Snapshotting more frequently improves recovery and enables features like rollback but requires time and storage space.

Agentic sandboxes, like those required to execute code, use Agent Skills, or carry out Search as Code pipelines in Computer queries, need all three. We’ve been hard at work over the past few months engineering the next generation of agent infrastructure powering our products. Today we are introducing SPACE (Sandboxed Platform for Agentic Code Execution): a sandbox platform built for agentic workflows that’s secure, reliable, and efficient at scale. Last month, we began rolling out SPACE as the sandbox layer powering Perplexity Computer. Over the last week, it has securely supported millions of sandbox creations and tens of millions of reconnects, with spin-up times that are 3-5 times faster than our previous solution. 

This article presents the architectural and design decisions behind SPACE. As of today, 100% of Computer sessions now run on SPACE. We’re excited to deploy this platform across even more surfaces to deliver a best-in-class agentic runtime to our users and developers.

Architecture

At a high level, the system is organized into three layers. 

• The control plane is the brain of the system, deciding what should exist and where. It consists of the API gateway and cluster-level state management modules. 

• Node-local services are the local machinery required to execute the control plane’s plan. They own the sandbox lifecycle, storage, networking, and the privileged operations behind them.

• The sandbox is the isolated execution environment itself. It’s implemented as a virtual machine paired with the space-daemon: an in-guest background process that brokers filesystem, process, and network access for the workload.

SPACE’s architecture is split into three layers: the stateless control plane; node-local services that manage sandbox lifecycle, storage, and safety gates; and the sandbox itself. 

Control Plane 

The API gateway is the entrypoint. Incoming requests are authenticated and authorized, then translated into records of desired state. 

The control plane is stateless by design, with all durable information offloaded to a shared database. It tracks cluster-level information on sandboxes, such as which node they are assigned to, where they’re running, and whether they’ve been backed up to durable storage. It continually compares the desired state against the observed state and drives the two towards convergence. Operations are idempotent, so the control plane can recover automatically after any crash, restart, or partial failure. 

Node-Local Services

Node-local services do the actual work of preparing templates, starting sandboxes, wiring networking, and running host-side runtime services. Each node runs a small set of daemons that manage every sandbox placed on it, and the node is the source of truth for those sandboxes’ live states. 

The sandbox manager knows which sandboxes are running, paused, suspended, or stopped, along with their real resources. It runs unprivileged and delegates all privileged work to the node manager, the single root process that brokers the underlying primitives. Storage is handled locally and durably: snapshots of current sandbox states are saved on the node, and a volume manager moves snapshots and templates to and from object storage as needed to enable cross-node operations. Safety gates guard what a sandbox can reach: the credential manager governs credential injection under per-service authorization, and the network gateway enforces each sandbox's egress policy. 

Sandbox

The sandbox itself is a virtual machine (VM) with its own guest kernel, running the user's workload behind a hardware isolation boundary. Because each sandbox has its own kernel, a compromised workload cannot fall back on a shared host kernel as a single point of failure; even if it successfully exploits its guest kernel, that compromise is confined to the sandbox’s VM boundary rather than propagating across other workloads.  

A space daemon runs inside each virtual machine, serving as a lightweight agent that regulates every action or modification the platform performs inside the guest. It handles filesystem access and process management. It also reports guest readiness and tracks activity, so the platform knows when a sandbox has gone idle and can be paused or reclaimed. Crucially, the space daemon does not talk to clients directly but rather communicates with the host over a private in-VM channel. This keeps all guest interaction on a controlled path and reserves the sandbox's own network purely for the workload's outbound traffic.

Three Pillars: Security, Functionality, and Efficiency

Next, we dive into the key properties that SPACE must deliver across three pillars: security, functionality, and efficiency. As noted earlier, these three pull against each other. Yet we cannot compromise on any of them if we wish to support powerful agents that rise to today’s model capabilities. Security keeps an untrusted, possibly hostile workload from harming the host, other tenants, or a user's secrets. Functionality gives agents the rich lifecycle they need. Efficiency makes all of this affordable under finite memory, disk, and compute.

Security: Protecting Data and Systems

Sandbox platforms need strong security to ensure that erroneous or even malicious code run inside sandboxes can’t cause harmful effects elsewhere. Without enforcing tight egress control and keeping secrets out of the sandbox, a single bad step by an agent could leak a user’s keys or exfiltrate work.

SPACE enforces layered security by combining VM and host-level isolation with strictly controlled communication channels, credential management, and encryption. 

SPACE takes a layered approach to ensuring security for sandboxes. Sandbox isolation has two components, VM isolation and host OS process isolation. Both must be breached for cross-sandbox access. Communication with the sandbox is strictly controlled; processes can only communicate through dedicated channels. The network gateway forces all egress through it. The space daemon is the only sanctioned channel between the (untrusted) sandbox and the (trusted) platform. 

Credentials never live where an agent can steal them. The credential store sits outside the sandbox boundary and is responsible for the credential lifecycle. It stores and retrieves secrets via a pluggable vault backend, resolves credentials using hierarchical scoping, manages metadata such as injection method and expiry, and enforces rate limits and audit logging on all access. When needed, credentials are injected at the network layer or auto-filled by a browser agent, instead of entering the sandbox directly. 

Data is protected at rest. SPACE supports BYOK (Bring Your Own Key) to protect externally stored data. Encryption keys come from the customer's key management service and never enter the sandbox. If the enterprise revokes the key, their data becomes unreadable.

Functionality: Powering Agentic Workflows

To support agentic workflows, sandboxes need rich lifecycle support. They have to be created quickly and at scale, since an agent may spin up many at once and shouldn't wait for any of them to boot. They have to persist for an indefinite duration, since a session might last minutes or run for months. They have to pause cleanly, sometimes for long stretches, such as when a task is blocked on human input. And they have to support forking, rollback, and crash recovery, so a session can branch, undo a bad step, or resume after a fault instead of starting over.

SPACE supports all of the above. It models the full sandbox lifecycle as an explicit state machine, which is what makes operations like create, pause, resume, suspend, and restore possible. 

This core subset of sandbox states and state transitions enables rich lifecycle support. 

Snapshots are the mechanism underneath most of these capabilities. A scheduler ticks on regular intervals and captures two types of snapshots: disk snapshots (point-in-time copies of the filesystem) and full snapshots (checkpoints of the entire paused VM). Disk snapshots are captured frequently, while full checkpoints are less frequent. Everything stays on the node, and retention decays by tier. These snapshots can be used for in-session recovery; for example, disk snapshots can be used to roll the filesystem back to undo a destructive command, and full checkpoints let a crashed sandbox resume at a recent running point instead of a cold disk.

When a sandbox is suspended, the VM is paused, a full snapshot is taken, and the artifacts from the full snapshot are uploaded to object storage. A database row tracks the snapshot and only becomes restorable once every artifact has landed, so a partially uploaded snapshot can never be resumed into a corrupt state. Restore is the inverse of suspend. Because the snapshot lives in object storage rather than on the original node, any node can bring the sandbox back. The scheduler picks a node, that node downloads the artifacts, reapplies the filesystem delta on top of the template, and resumes the VM from its captured state.

Efficiency: Optimizing Time and Space

It’s not enough to implement the features above in a vacuum; they also need to be possible under tight resource constraints. Memory and disk on a node are finite, and users want agents to operate as quickly as possible, so lifecycle operations must be cheap in both time and space. We can't afford to copy a full machine image every time a sandbox is created, paused, or branched. 

A key design choice makes this possible: the filesystem. SPACE uses btrfs as the on-node filesystem for sandbox storage. Btrfs (B-tree filesystem) combines a copy-on-write filesystem with integrated logical volume management. This has a few benefits: 

1. Reflink copies are fast, since you share the underlying extents, so only metadata needs to be copied. 

2. Snapshots are atomic and fast, since you just make a new root.

3. Minimal storage is needed, since you only store what’s changed. 

As a result, 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. Giving that sandbox its own writable root filesystem is then a copy-on-write clone rather than a full copy. When no warm pod fits, we materialize the template on demand; we collapse concurrent requests for the same image into a single download, so a burst of identical requests doesn't turn into a burst of identical work.

The result is a sandbox runtime that is at once powerful, lightweight, and blazing fast. When we rolled SPACE out, we ran it alongside our previous sandbox provider on the same production traffic. Across the launch week, SPACE created sandboxes three to five times faster throughout the distribution. Specifically, median create latency fell from 185 milliseconds to 60 milliseconds (3.1x improvement), and the 90th-percentile latency fell from 447 milliseconds to 89 milliseconds (5.0x improvement). We observed similar order-of-magnitude improvements across other performance and resource usage indicators.

In a direct comparison, creation latency for SPACE sandboxes is up to 5 times faster than our previous sandbox solution. 

It also makes it easy to take rolling disk snapshots, as they’re fast, space efficient, and don’t require pausing the sandbox. And, efficient delta storage lessens the space needed to store these snapshots. 

Conclusion

When designing complex systems, it’s tempting to choose a single objective to optimize in isolation. But developers of frontier agents demand security, functionality, and efficiency in equal measure. With SPACE, we set out to achieve a Pareto improvement across all three pillars.

Each individual design choice can serve multiple goals at once, making this delicate balance possible. Per-sandbox VMs give each workload its own kernel, strengthening security through strong isolation while also providing the clean checkpoint boundary that snapshots rely on. Btrfs enables the efficient implementation of snapshotting, forking, and other operations essential to agentic runtimes. The space daemon keeps all guest interaction on a controlled host-side path, sealing the guest-host boundary while preserving agents’ freedom of maneuver. The central network gateway mediates egress and credential injection without ever exposing secrets to the guest.

The result of these and other design decisions is a platform that enables real-world agent orchestration at scale. SPACE provides the substrate on which long-running, stateful agents can securely tackle work of arbitrary complexity or duration, without sacrificing either performance or security.

Today, SPACE already powers millions of Perplexity Computer sessions. We intend for SPACE to serve as a unified layer for provisioning and controlling sandboxes in any setting: from Linux microVMs to Windows guests to a user’s own local machine. We’re working hard on pushing SPACE into these new settings, so that developers can ship AI products that work everywhere users work.

If you’re itching to shape the compute layer driving tomorrow’s frontier agents, we invite you to join our team.