Perplexity open-sources SPACE, a Firecracker sandbox for AI agents

Perplexity has released SPACE, its Sandboxed Platform for Agentic Code Execution, under the Apache 2.0 license. The project gives teams a self-hosted isolation layer for model-generated code, combining Firecracker microVMs, persistent snapshots, credential brokering, and per-sandbox network policy.

Agent sandboxes have become a critical boundary because autonomous systems install packages, execute commands, access files, and call external services with limited supervision. An OpenAI account of a Hugging Face model-evaluation security incident showed how an agent using valid credentials can reach resources beyond its intended scope when surrounding controls are weak.

Inside the boundary

SPACE runs each sandbox in a Firecracker microVM called the guest. The physical or cloud machine running that VM is the host, which remains outside the guest’s control. Agents receive root access inside the guest so they can install software and run arbitrary commands, while network rules and platform-managed credentials remain on the host side of the boundary.

SPACE stores changed state instead of copying an entire environment for every checkpoint. This incremental approach reduces the storage and transfer work required to restore or fork a sandbox.

Long jobs keep their state

Traditional request-scoped sandboxes often assume that a job ends with the HTTP request that started it. SPACE separates the sandbox lifetime from the client connection, allowing a running environment to suspend to memory and disk snapshots and later resume from the same state.

Persistent state supports workflows that span multiple requests or require human review. An agent can pause before a sensitive action, fork a workspace to test competing approaches, or recover from a crash without replaying its full execution history.

Perplexity says SPACE now powers every session in its Computer agent and handles millions of sandbox creations per day. On the same production traffic, the company measured creation times three to five times faster than its previous provider. That comparison establishes an internal improvement rather than a general benchmark against containers, virtual machines, or other sandbox products.

Red-team runs exposed egress flaws

Perplexity’s Secure Intelligence Institute tested SPACE by giving frontier models root access inside the guest and instructing them to escape. Its red-team report covers nine model configurations, including Claude Opus 5.0, GPT-5.6 Cyber, GPT-5.6 Sol, Gemini 3.1 Pro, Kimi K3, and DeepSeek V4 Pro.

None of the 108 sandbox-escape runs crossed the microVM boundary, according to Perplexity. The models had access to SPACE’s source code and could install software, run arbitrary commands, and search the web during the test.

Network-policy testing produced a different result. Four models bypassed hostname-based egress restrictions when the policy allowed access to package repositories such as PyPI. The attacks used two techniques:

1. Forged DNS responses: An agent with root access sent a DNS query for pypi.org, then injected a fake response that appeared to come from the external resolver. The gateway cached the forged mapping and routed subsequent HTTPS traffic to an attacker-controlled address.
2. Shared CDN addresses: Content delivery networks commonly serve unrelated domains from the same IP addresses. One GPT-5.6 Sol run reached Fastly Fiddle through an address also used by pypi.org. GPT-5.6 Cyber chained Taboola’s image service with thum.io, captured the blocked callback as an image, and used optical character recognition to extract the flag.

Perplexity patched both paths by validating source addresses with nftables rules in the sandbox namespace and terminating TLS at the gateway. The gateway now checks that the Server Name Indication supplied during the TLS handshake and the HTTP Host header match the allowlisted hostname associated with the destination address. The company reports no verified bypass using either technique after remediation.

The audit widened to hosted platforms

Perplexity applied the same network-policy attacks to ten third-party sandbox platforms offering hostname- or domain-based egress controls. The report says eight of the ten allowed at least one bypass.

Affected products named in the report include E2B, Vercel Sandbox, Modal Sandboxes, Daytona Sandbox, Deno Sandbox, Fly.io Sprites, and microsandbox. Cloudflare Sandbox and NVIDIA OpenShell resisted both tested attack classes.

These results describe specific configurations and product versions tested by Perplexity, which operates a competing sandbox. Developers evaluating a hosted platform should review the full methodology, confirm whether vendors have shipped remediations, and repeat the tests against the versions they plan to deploy.

Where SPACE fits

SPACE targets agent products that execute untrusted model-generated code with filesystem or network access. Its primitives support several common workloads:

• Creating disposable workspaces for data transformation, analysis, and chart generation without exposing production hosts.
• Pausing an agent for human approval, then restoring its processes, files, and memory state.
• Forking a saved workspace to test multiple code paths or recover after a destructive command.
• Keeping API keys and OAuth tokens outside the guest while brokering approved service access through the gateway.

Perplexity says CoreWeave and Akamai have tested and launched SPACE on their cloud platforms and are working to offer it to customers. Crusoe plans to add the software to its managed AI services portfolio. Teams choosing self-hosting can consult the project’s deployment guide for supported configurations and included components.

Checks before production

Teams adopting SPACE assume operational responsibility for the surrounding infrastructure, even when the microVM boundary performs as designed. A production review should cover:

• Host compatibility: Confirm that the target infrastructure supports the Firecracker configuration documented by the project.
• Threat assumptions: Treat root access inside every guest as expected behavior and keep host services, sockets, and secrets outside its reach.
• Egress enforcement: Test DNS spoofing, shared CDN addresses, redirects, alternate protocols, and hostname validation against the deployed policy.
• Credential handling: Define which services the gateway may call, which credentials it may attach, and how access is logged and revoked.
• Snapshot security: Set encryption, retention, access-control, and deletion policies for memory and disk snapshots that may contain sensitive data.
• Capacity planning: Measure startup latency, snapshot cost, restore time, storage growth, and host density with representative agent workloads.
• Patch management: Track updates to Firecracker, guest images, the host kernel, and SPACE’s gateway components.

An inspectable security baseline

Security reviews for agent infrastructure must test VM isolation and network confinement independently. SPACE’s red-team results show that a microVM can contain code execution while a gateway still leaks data through DNS assumptions or shared network infrastructure. Open sourcing the system gives developers a way to inspect those assumptions, reproduce the attacks, and evaluate patches before placing model-generated code near production resources.