Perplexity Open-Sources SPACE, the Firecracker Sandbox Behind Perplexity Computer

On October 15, 2026, Perplexity open-sourced SPACE, the sandbox platform that runs every task in Perplexity Computer, under the Apache 2.0 license. Perplexity's announcement on X says SPACE "gives each agent task its own Firecracker microVM and controls credentials and outbound traffic from outside the VM."

That is the interesting part. Most agent sandboxes ask you to trust a container. SPACE is a Rust, microVM-based agent sandbox that Perplexity already runs in production, and now you can read the code, run it, and fork it.

TL;DR: what shipped and what to ask first

If you only read one row, read this one: the code is open, the claims about isolation come from Perplexity, and the independent audit does not exist yet.

What is SPACE?

According to the README, SPACE is for the moment "your application needs a separate execution environment for an agent, a user workspace, or a code-running job." Your application decides what to run and which results to keep. SPACE manages the sandbox, its processes, and the connection that carries output.

The object model is small:

• Template: the starting environment.
• Sandbox: an instance of a template with its own VM and writable filesystem. You can run many commands in one sandbox.
• Lifecycle: create, keep, pause, suspend (and later wake), and delete.
• Operations: lifecycle changes are asynchronous. You get an operation ID and poll for completion.
• Output path: command output travels on a separate data-plane connection, authorized by a session-scoped attachment token.

The documented flow is: create a sandbox from a template, wait until ready, create a command session, attach to start the process, read output and the exit result, then keep, pause, suspend, or delete.

How does SPACE isolate an agent?

Two layers matter.

The VM boundary. Firecracker is the microVM monitor originally built at AWS for Lambda and Fargate. Each guest gets its own kernel, so a container-style kernel bug shared across tenants is not the first thing an attacker hits. The trade-off is a harder operations story than plain containers: you need KVM-capable hosts and a way to build and snapshot guest images.

The control plane outside the guest. This is the claim in Perplexity's announcement. If credentials live outside the VM and outbound traffic passes through a policy layer the guest cannot edit, then an agent with root inside the guest still cannot widen its own access. The README names "operator egress profiles" as named policy additions for sandbox creation, but the page I read does not detail credential handling. The deeper design is in the linked architecture guide, so read that before you rely on the claim.

This split matters because the failure mode is usually the network, not the hypervisor. In Perplexity's own red-team report, covered in Perplexity red-teams SPACE, models with root inside the guest made zero successful VM escapes in 108 runs. Four models did beat a partial-network policy in 11 of 54 runs, using tricks like DNS spoofing and CDN IP sharing, until Perplexity patched it. Open sourcing the egress code lets outsiders check that fix.

What is in the repository?

The README lists a clear layout:

Feature docs also cover warm pools (keep booted sandboxes ready on Kubernetes), base snapshots (restore on a single node, optionally with a node warm pool), observability, and the ECW compatibility layer. The generated API reference is served at /openapi-m1.json, and the hosted guide is at space.docs.perplexity.ai.

How do I try it today?

The README points to a local Kind cluster. The shape of the loop looks like this:

# Local development loop from the repo root
tilt up

# Operator CLI login (after the Kind deployment is up)
space-admin-cli login

Then follow the first-sandbox guide: create a sandbox, wait for readiness, create a command session, attach, read output. Examples in examples/ use plain Python and HTTP, so you can copy them into an agent harness without adopting an SDK.

Three practical notes before you spend an afternoon on it:

1. Read the installation guide's host prerequisites first. Firecracker needs hardware virtualization, and nested virtualization on a laptop or cloud VM is where most trials stall.
2. Treat incubating API fields as unstable. The README says they are outside the supported contract.
3. Plan for asynchronous calls. Lifecycle operations return an operation ID. Your agent loop must poll rather than assume a sandbox is ready.

What are people asking about SPACE?

Is this better than Docker or gVisor for agents?

It is a different bet. Containers share the host kernel, gVisor intercepts syscalls in user space, and a microVM gives each task a separate kernel behind a hardware boundary. The microVM costs more to operate, which is why warm pools and base snapshots are first-class features here. The recent Vercel KVM zero-day is a reminder that a VM boundary also depends on the hypervisor and host kernel being patched.

Can I use it instead of a hosted sandbox?

Maybe. If you already pay for a hosted sandbox, compare it with the Cloudflare Sandbox SDK and with what you would run yourself. Self-hosting SPACE trades a per-sandbox bill for a Kubernetes cluster, KVM hosts, and an on-call rotation. The ECW layer lowers switching cost if your code already speaks the E2B API, but its limitations are documented separately, so test your exact calls.

Does a sandbox make an agent safe?

No. A sandbox contains damage. It does not stop an agent from misusing credentials you hand it or from being hijacked by prompt injection inside a task. See OpenAI's argument that agent security is not just a sandbox and the AgentCorruption hijack of Bedrock AgentCore agents.

Why open source it now?

Perplexity has not given a single reason in the announcement. The context is clear, though. In September it joined the Rust Foundation and said it wants to improve how "people and agents build with Rust," covered in Perplexity joins the Rust Foundation. The same month NVIDIA launched a shared agent-safety effort, covered in NVIDIA's Open Agent Safety Platform. Publishing the code invites the outside review that safety claims need.

What did Perplexity's leaders say?

Posts on X around the release add context the README does not:

• Aravind Srinivas (co-founder and CEO): "While sandboxes are a commodity, serving millions of them under production-grade traffic requires a lot of detail to scale agents for businesses and consumers. We're open-sourcing the sandbox platform SPACE that powers all of Perplexity Computer to support the ecosystem."
• Denis Yarats (co-founder and CTO): SPACE is "the sandbox platform we use internally for secure agentic runtimes," and it powers Computer as well as Perplexity's reinforcement learning training and evaluation workloads.
• Srinivas on neoclouds: they "can't just lease GPUs." He argues they need to own the full agent inference platform, covering open-weight models (SGLang), fine-tuned models (Miles, River) and secure sandboxes (SPACE), and named CoreWeave, Akamai and Crusoe as partners to work with. Reporter Reed Albergotti also described those three as partners in the push.

The commercial reading: Perplexity wants SPACE to become the default sandbox layer for GPU clouds. That is a plausible strategy, but the partnerships are described in posts, not in the repository.

Earlier reporting adds context. SPACE launched publicly on July 15, 2026, and per The New Stack and Perplexity's posts has handled all production Computer traffic since June. Perplexity claims median sandbox creation fell from 185 ms to 60 ms and that it is 5x cheaper than Vercel with 5x faster tail latency. Those are company claims, not independent measurements. Perplexity's infrastructure VP said the hard problem was managing state across millions of sandboxes, not isolation itself.

What should builders do with this?

If you run agents that execute code, read the architecture guide and the egress and credential sections first. Even if you never deploy SPACE, the design is a useful checklist: secrets outside the guest, policy outside the guest, one VM per task, short-lived attachment tokens.

If you are choosing a sandbox, add SPACE to your shortlist and ask the same questions of every option: where do credentials live, who can change egress policy, what happens to a paused sandbox, and what was tested independently.

If you teach or learn agent engineering, the repository is a rare production-grade reference. The examples/ folder is the quickest way to see the sandbox lifecycle as plain HTTP calls. Our workshops cover agent containment patterns for teams moving past demos.

If your concern is agents taking dangerous actions regardless of where they run, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions. It sits at a different layer than a sandbox.

What do we not know yet?

• No independent audit. The red-team numbers come from Perplexity's Secure Intelligence Institute.
• Operational cost. Perplexity has not published what it costs to run SPACE at its scale.
• Support model. The repo shows 5 open issues and no tagged releases at capture time. Expect fast-moving code.
• Credential brokering detail. The README page I read does not spell it out. Verify it in the architecture docs and in the code.

Perplexity's wider agent product is covered in Perplexity Computer with GLM 5.2 as orchestrator if you want the user-facing side of what this sandbox runs.

Related reading

• Perplexity red-teams SPACE: 216 runs, zero VM escapes
• Perplexity joins the Rust Foundation to back SPACE
• NVIDIA Open Agent Safety Platform: OpenShell and Sentry
• Vercel KVM zero-day and agent sandboxes
• Cloudflare Sandbox SDK 1.0 for agents
• OpenAI on why agent security is not just a sandbox
• OpenAI and Hugging Face incident postmortem

Official sources: SPACE on GitHub, the SPACE guide, and the Firecracker project.

Repository details (stars, forks, issue counts, file layout) were captured on October 16, 2026 and will change.