Perplexity SPACE: Sandbox platform for AI agents

What changed

Perplexity has open-sourced SPACE, the sandbox platform that powers agent execution in Perplexity Computer. The release arrived under the Apache 2.0 license on GitHub as version 0.8.0, representing a production-tested baseline. Each agent task runs inside its own Firecracker microVM, a lightweight virtualization layer that includes a full guest kernel with controlled boundaries.

Credentials and outbound traffic remain managed by the host system and never enter the guest environment. The codebase is written in Rust and provides access through an HTTP API with server-sent events for command output streaming. Organizations can self-host SPACE on a local Kind cluster or deploy it directly on Linux x86_64 systems equipped with KVM support.

The release includes documentation for installation, operator CLI tools, API reference, and a security audit report. The platform integrates with Kubernetes deployments and offers an E2B compatibility wrapper for teams using the E2B ecosystem, tested against Python package version e2b==2.21.1.

Why it matters

Teams building coding or browsing agents now have a production-tested isolation layer available for self-hosted deployment, removing dependency on third-party sandbox providers. The architecture addresses a critical requirement in agentic systems: agents execute arbitrary commands with root access inside the sandbox, yet the host and its secrets must remain protected from that untrusted environment.

For development teams, faster sandbox creation directly improves responsiveness. Perplexity reports that 90th-percentile creation latency dropped from 447 milliseconds to 89 milliseconds in production deployments. Teams using pre-booted sandbox pools on Kubernetes can achieve even quicker startup times.

The security validation supports production readiness. Perplexity tested the platform against 9 frontier models with root-level access inside the guest environment across a total of 216 runs. The research team also tested 10 third-party sandbox platforms and reported network-policy vulnerabilities to affected vendors.

However, potential adopters must account for infrastructure constraints. SPACE requires a Linux x86_64 environment with kernel-level KVM access, btrfs for copy-on-write filesystems, and Docker. macOS is not supported, and running SPACE inside a virtual machine requires nested virtualization capability. This substantially limits deployment options for some organizations.

What to test

Before committing SPACE to production agent workloads, organizations should validate several vendor claims:

• Performance baseline: Measure median and 90th-percentile sandbox creation times on your target infrastructure. Perplexity’s reported improvements reflect their previous provider, but actual performance depends on warm pool configuration, storage backend, and network latency specific to your deployment.

• Egress policy enforcement: Confirm that credential injection at the network layer functions correctly with your agent use cases. Perplexity’s red-team testing identified network-policy bypasses that were subsequently fixed. Test your agents against your intended egress rules to validate gateway behavior.

• Credential isolation: Verify that secrets remain external to guest environments under your specific threat model. Test with real credential stores and hierarchical scoping rules to ensure no data leakage occurs.

• Escape resilience under emerging attacks: Red-team results from testing show zero escapes, but new attack vectors may emerge. Plan for ongoing security audits, particularly if agents process untrusted user input or execute third-party code.

• Infrastructure costs: Firecracker microVMs consume fewer resources than traditional VMs, yet running hundreds of sandboxes still demands substantial CPU, memory, and storage allocation. Model your workload and calculate cost projections before scaling to production.

• Compatibility with your agent framework: If your agents derive from frameworks like Claude Dynamic Workflows, test integration with the SPACE API. The E2B wrapper provides compatibility, but edge cases may still arise.

The conclusion

SPACE addresses a genuine infrastructure need for teams developing autonomous agents. A production-tested, open-source sandbox platform with demonstrated isolation under red-team conditions provides measurable value. Zero successful escapes across 108 attempts and fixes that eliminated all network-policy bypasses from initial testing demonstrate serious security engineering.

The tradeoffs merit consideration. Organizations must commit to Linux x86_64 infrastructure, learn the Kubernetes-first operational model, and maintain warm pools or base snapshots to sustain low latency. SPACE is not a minimal deployment option.

For teams already operating Kubernetes and building agents requiring code isolation, SPACE merits evaluation against E2B and other alternatives. Smaller deployments or organizations without Linux infrastructure may find the operational overhead outweighs benefits. Validate performance and security claims against your specific agent workflows before moving to production.

Monitor updates to the egress policy architecture and any new red-team findings as adoption grows across production deployments. The platform released at version 0.8.0, so expect ongoing refinement in API stability, performance optimization, and operational tooling.

Related reading

• LFM2.5-24B-A2B: Fast on-device reasoning agents
• RTX Spark PC AI launches Oct 16 with local agents
• QwenGyre elastic RL framework trains long-horizon agents