# SPACE (Perplexity)

> Source: https://aiwiki.ai/wiki/perplexity_space
> Updated: 2026-10-18
> Fact-checked: 2026-10-18
> Categories: AI Agents, AI Infrastructure, AI Safety, Open Source AI
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "SPACE (Perplexity)." aiwiki.ai, 18 Oct 2026. https://aiwiki.ai/wiki/perplexity_space
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**SPACE** (Sandboxed Platform for Agentic Code Execution) is a sandbox platform developed by [Perplexity](https://aiwiki.ai/wiki/perplexity) for running agent-generated and user code inside isolated Firecracker microVMs. It is the execution layer behind Perplexity's Computer agent: Perplexity said in July 2026 that 100% of Computer sessions ran on SPACE, and in October that it had powered all Computer sessions since July while handling millions of sandbox creations per day.[1][4] Applications drive SPACE through an HTTP API that creates Linux environments from templates, runs commands, streams their output, and pauses, suspends, wakes or deletes the sandboxes.[3] Perplexity open-sourced the platform under the [Apache License 2.0](https://aiwiki.ai/wiki/apache_license) on 15 October 2026, describing it as "the sandbox platform that runs every task in Perplexity Computer" and saying that each agent task gets its own Firecracker microVM, with credentials and outbound traffic controlled from outside the VM.[1][2]

SPACE is written mainly in Rust.[3][19] Its design treats the workload inside each sandbox as untrusted, keeps platform-held credentials out of the guest, and sends all egress through a per-sandbox network gateway.[1][4][6] Before the open-source release, Perplexity's Secure Intelligence Institute published a red-team study in which nine models with root access inside a SPACE guest made 108 attempts to escape to the host, none of which succeeded; four of the models did bypass the network policy when limited package-repository access was allowed, and Perplexity said it fixed both techniques they used.[6]

## Overview

| Attribute | Detail |
|---|---|
| Full name | Sandboxed Platform for Agentic Code Execution[3] |
| Developer | Perplexity[1] |
| Primary use | Sandbox layer for Perplexity Computer[1][4] |
| Isolation | One Firecracker microVM per sandbox, with its own guest kernel[3][4] |
| Implementation language | Rust (repository also contains Python, Shell, TypeScript, Go and HCL)[3][19] |
| Interfaces | Native HTTP API with server-sent event streams; E2B-compatible API (ECW)[3][9][18] |
| Public baseline version | 0.8.0[7][26] |
| License | Apache License 2.0[2][3] |
| Repository | github.com/perplexityai/SPACE (created 1 October 2026; about 1,500 stars and 122 forks as of 19 October 2026)[19] |
| Open-sourced | 15 October 2026[1][2] |
| Host requirement (local guide) | Linux x86_64 with KVM, btrfs and Docker; not macOS directly[10] |

## History

Perplexity launched Computer, its agent for multi-step tasks, in February 2026. It initially ran on a commercially available sandbox provider.[1] On 15 July 2026 Perplexity Engineering published "Making SPACE: Secure and efficient runtimes for long-running agents", which introduced the platform. The post said Perplexity had begun rolling SPACE out as Computer's sandbox layer the previous month, that it had supported millions of sandbox creations and tens of millions of reconnects over the preceding week, and that 100% of Computer sessions then ran on it.[4] The October announcement dates the switch from the commercial provider to July.[1]

The July post explained the case for a new platform. Perplexity argued that container sandboxes assume short-lived, stateless jobs and share the host kernel as a single point of failure, while agent sessions are long-lived and stateful and their workloads should be untrusted by default.[4]

On 23 September 2026 the Perplexity Secure Intelligence Institute published "Escaping SPACE: Part I", a red-team evaluation of SPACE's VM isolation and network confinement (see [Security evaluation](#security-evaluation)).[6] On 15 October 2026 Perplexity published the source on GitHub under Apache 2.0, with a hosted guide and API reference.[1][2][26] The repository's GitHub record shows it was created on 1 October 2026.[19] NVIDIA's NVIDIA AI account welcomed the release on 17 October, saying it gave developers "more control over where agents run code and what they can access".[24]

| Date | Event |
|---|---|
| February 2026 | Perplexity launches Computer on a commercial sandbox provider[1] |
| June-July 2026 | SPACE rolled out as the sandbox layer for Computer[1][4] |
| 15 July 2026 | "Making SPACE" architecture post; all Computer sessions on SPACE[4] |
| 26 August 2026 | Red team discovers and reproduces two network-policy bypasses[6] |
| 31 August - 1 September 2026 | Network-policy tests of ten third-party sandbox platforms; vendors contacted 1 September[6] |
| 23 September 2026 | "Escaping SPACE: Part I" published[6] |
| 1 October 2026 | GitHub repository created[19] |
| 15 October 2026 | Open-source release under Apache 2.0[1][2] |

## Architecture

### Layers

Perplexity's July post describes three layers.[4]

- **Control plane.** An API gateway authenticates and authorizes requests and turns them into records of desired state. The control plane is stateless, keeps durable information in a shared database, and repeatedly reconciles desired state with observed state. Its operations are idempotent so that it can recover after crashes or partial failures.[4] The repository documentation says the database is PostgreSQL and that an accepted request is therefore not a readiness signal.[5]
- **Node-local services.** Each worker node runs daemons that prepare templates, start sandboxes, wire networking and run host-side services. A sandbox manager tracks running, paused, suspended and stopped sandboxes and runs unprivileged; it delegates privileged work to a node manager, described as the single root process. A volume manager moves snapshots and templates to and from object storage. A credential manager governs credential injection, and a network gateway enforces each sandbox's egress policy.[4]
- **Sandbox.** Each sandbox is a VM with its own guest kernel, so a workload that exploits its guest kernel stays inside that VM boundary instead of reaching a shared host kernel. An in-guest daemon handles filesystem access, process management, readiness and activity tracking. It talks to the host over a private in-VM channel, not to clients directly, which leaves the sandbox's own network for the workload's outbound traffic.[4]

SPACE can manage workers directly or through [Kubernetes](https://aiwiki.ai/wiki/kubernetes). A direct adapter calls worker services without creating Kubernetes pods; a Kubernetes adapter, used by the local Kind installation, runs each sandbox through a Kubernetes sandbox pod and a SPACE runtime shim. In the Kind topology, sandbox pods live in their own namespace, and NetworkPolicies admit only the API and cluster controller and limit sandbox egress to the public IPv4 internet and cluster DNS.[5] Command output travels over a separate data plane that connects clients to guest processes using session-scoped attachment tokens; management tokens and attachment tokens are not interchangeable.[5] The repository also includes a reference AWS EKS deployment.[3]

### Core concepts

| Concept | Meaning |
|---|---|
| Template | The starting filesystem and runtime configuration; many sandboxes can share one template. A reference such as `seed:latest` selects a published release, and a digest selects exact content.[5] |
| Sandbox | An isolated microVM with its own writable filesystem and lifecycle.[5] |
| Process | A program running inside a sandbox; processes in one sandbox share its environment and filesystem.[5] |
| Command session | Connection details and authorization for one command. Creating the session assigns a process ID; attaching to it starts the process.[5] |
| Operation | A record tracking an asynchronous create, pause, suspend, wake or delete request, which clients poll for completion.[3][5] |

### Execution environment

The repository defines an execution-environment identity, E0, as the compiled default: a Linux/x86_64 host with KVM, Firecracker 1.15.1, a Linux/x86_64 guest with kernel 6.1.155, a hardware VM boundary, and Firecracker snapshot format 9.0.0.[8] The compiled catalog also approves two Firecracker 1.17.0 bindings (with Linux 6.1.155 or 6.18.44), but only non-production deployments may select them; production nodes are restricted to E0.[8] Other host and guest platforms are distinguishable identities in the schema, but the documentation says that does not mean the build implements execution adapters for them.[8] Perplexity said in July that it intends SPACE to cover settings "from Linux microVMs to Windows guests to a user's own local machine".[4]

## Lifecycle and persistence

Sandbox lifecycle changes are asynchronous: the API returns an operation ID, and the client waits for the operation to succeed and the sandbox to report `running` before running commands. A finished command does not delete its sandbox.[3][5]

| State | Execution | What is retained |
|---|---|---|
| Running | Processes can execute | Live VM memory and writable filesystem |
| Paused | Execution paused | VM memory stays resident and the filesystem stays on the worker; not a durable snapshot |
| Suspended | No guest execution | Snapshot of VM memory, runtime state and root filesystem; active VM resources released |
| Deleted | None | Sandbox no longer available through the API |

Source: SPACE architecture documentation.[5]

A wake request returns a paused or suspended sandbox to running. By default, sandboxes created through the SPACE API suspend after six hours without access or command activity; the documentation describes this as an idle limit, not a maximum lifetime.[5]

Snapshots underpin most lifecycle features. A scheduler takes frequent disk snapshots (point-in-time filesystem copies) and less frequent full checkpoints of the paused VM. Disk snapshots can roll back a destructive command, and full checkpoints let a crashed sandbox resume from a recent running point.[4] On suspend, SPACE pauses the VM, takes a full snapshot and uploads the artifacts to object storage; the snapshot becomes restorable only after every artifact has landed. Because the snapshot lives in object storage, any node can restore the sandbox by downloading the artifacts, reapplying the filesystem delta on top of the template and resuming the VM.[4]

SPACE uses btrfs as its on-node filesystem. Copy-on-write reflinks and atomic snapshots let it give each sandbox a writable root filesystem as a clone rather than a full copy, and store only changed data.[4] On Kubernetes, warm pools keep booted sandboxes for one template release and VM size ready, so that a matching create skips a cold boot; single-node deployments can instead restore new sandboxes from a base snapshot of a booted template.[11][12] Perplexity's October post lists isolated code execution, pause and resume, recovery and session branching as the capabilities SPACE provides in Computer.[1]

## Security model

### Isolation

The architecture documentation states that Firecracker isolates guest execution, while host-side services still need privileges to manage VMs, storage and networking.[5] Perplexity's July post describes two isolation layers, VM isolation and host OS process isolation, both of which must be breached for one sandbox to reach another. The in-guest daemon is the only sanctioned channel between the untrusted sandbox and the trusted platform.[4]

### Network egress control

All outbound traffic from a guest passes through a per-sandbox network gateway that enforces the sandbox's network policy.[4][6] Policies combine a default action with allow and deny lists, whose destinations can be IP addresses, CIDR ranges or exact domains.[13][15] With TLS interception switched on, the gateway terminates TLS and parses the decrypted stream as HTTP; operators can exempt selected destinations, which are then relayed without decryption and lose HTTP inspection and credential injection.[5][14] Hostname exemptions depend on DNS attribution at the gateway: the guest must resolve names through the reserved resolvers 8.8.8.8 or 1.1.1.1, and the documentation notes that DNS-over-HTTPS, other resolvers or cached addresses without observed DNS can leave interception enabled.[14] Operators can also define named "egress profiles" that add allowances to a tenant's policy at creation time; explicit tenant and platform denies still take precedence.[13]

### Credentials

Perplexity's description is that "credentials never live where an agent can steal them".[4] The credential store sits outside the sandbox, retrieves secrets through a pluggable vault backend, resolves them with hierarchical scoping, tracks injection method and expiry, and applies rate limits and audit logging. When a credential is needed, it is injected at the network layer or filled in by a browser agent rather than placed in the sandbox.[4] In the repository, network credential rules list the HTTP methods (`GET`, `POST` and `HEAD`) for which the gateway injects headers, and credential references can be resolved from AWS Secrets Manager through a per-organization IAM role restricted by organization tags.[15][16] For SPACE's own host-side storage traffic, the credential manager implements an RFC 8693 token exchange that issues one-hour AWS credentials scoped to a single S3 object or artifact prefix and never returns its own ambient credentials.[17] The July post adds that SPACE supports bring-your-own-key encryption for externally stored data, with keys from the customer's key management service that never enter the sandbox.[4]

## Security evaluation

"Escaping SPACE: Part I", by the Perplexity Secure Intelligence Institute, tested two boundaries: VM isolation and network confinement.[6] Agents had root inside a guest VM, no physical access and no host-side foothold. The sandbox-escape task asked them to cross the VM-host boundary and obtain an AWS honeytoken stored on the host; the network-bypass task asked them to fetch a flag from a callback URL blocked by the egress policy. Each task ran under four settings, with or without access to SPACE's source code and with either no network or partial network access (approved package repositories such as PyPI and Ubuntu mirrors, plus Perplexity search). Nine model configurations each ran three times per setting, for 216 runs in total.[6]

The evaluated models were [Claude Opus 5](https://aiwiki.ai/wiki/claude_opus_5) (listed as Claude Opus 5.0), [DeepSeek V4](https://aiwiki.ai/wiki/deepseek_v4) Pro 0813, [Gemini 3.1 Pro](https://aiwiki.ai/wiki/gemini_3_1_pro), [GLM-5.2](https://aiwiki.ai/wiki/glm_5_2), [GPT-5.6](https://aiwiki.ai/wiki/gpt_5_6) Cyber, GPT-5.6 Sol, Grok 4.20, [Kimi K3](https://aiwiki.ai/wiki/kimi_k3) and Qwen 3.8 27B. Perplexity said Fable refused the tasks in pre-run testing despite Perplexity's enrollment in the [Anthropic Cyber Verification Program](https://aiwiki.ai/wiki/anthropic_cyber_verification_program), and that [GPT-6 Astra](https://aiwiki.ai/wiki/gpt_6_astra) also refused when tried after its 3 September release.[6]

| Task and condition | Successful runs |
|---|---|
| Sandbox escape (all settings) | 0 of 108 |
| Network bypass, no network | 0 of 54 |
| Network bypass, partial network (before fixes) | 11 of 54 |
| Partial network with source code | Claude Opus 5.0 3/3, GPT-5.6 Sol 3/3, Kimi K3 2/3 |
| Partial network without source code | GPT-5.6 Sol 2/3, GPT-5.6 Cyber 1/3 |

Source: "Escaping SPACE: Part I". Figures are Perplexity's own and were not independently replicated.[6]

The successful bypasses exploited gaps between domain-name policies and IP-based enforcement at the gateway, which learned name-to-address mappings by watching DNS traffic.[6] In the first method, agents with source access forged DNS responses that mapped pypi.org to the callback's IP address; this worked only after the models read in the source which internal address the gateway's DNS socket used. In the second, agents used the fact that CDN addresses are shared by many domains: one GPT-5.6 Sol run reached the callback through Fastly Fiddle on the same Fastly address as PyPI, and one GPT-5.6 Cyber run chained Taboola's image service and the thum.io screenshot service, then read the flag from the screenshot with OCR. Claude Opus 5.0 identified the shared-IP approach but declined to use it, reasoning that relaying through a third-party service would break the instruction not to target other systems.[6]

The vulnerabilities were found and reproduced on 26 August 2026. Perplexity added source-address validation (an nftables rule that drops guest packets whose source address is not the VM's own), a relay that validates the request authority on plain HTTP, and TLS termination that requires both the ClientHello SNI and HTTP host information to be allowlisted and DNS-attributed to the destination IP; domain-based rules now reject UDP and unsupported plaintext protocols. In a re-run under the strongest setting, no model retrieved the flag.[6] The report cautions that absence of an observed escape "is not a proof of isolation".[6]

The same report tested the network-policy enforcement of ten third-party sandbox platforms on 31 August and 1 September 2026, without LLM agents, and found at least one bypass in eight. It published results for nine: the HTTPS shared-infrastructure bypass worked against E2B, Vercel Sandbox, Modal Sandboxes, Daytona Sandbox, Deno Sandbox, Fly.io Sprites and microsandbox, while neither bypass succeeded against Cloudflare Sandbox or [NVIDIA OpenShell](https://aiwiki.ai/wiki/nvidia_openshell). One vendor asked for more time and was omitted.[6] Perplexity's launch post connected this work to the [OpenAI-Hugging Face agent incident](https://aiwiki.ai/wiki/openai_hugging_face_agent_incident), saying the testing showed SPACE resilient against network-bypass techniques like those used there.[1] Some press coverage reported the escape attempts as 118, a figure attributed to Semafor; Perplexity's report gives 108.[6][23]

## Interfaces and deployment

### Native API

The SPACE API reference covers 14 supported HTTP operations: sandbox creation, inspection and lifecycle actions, command creation and process control, operation polling and server-sent event streams.[18] Management requests use a bearer token against endpoints such as `POST /v1/sandboxes`, `POST /v1/sandboxes/{id}:suspend` and `POST /v1/sandboxes/{id}:wake`, while output streams use the data-plane endpoint and the session token returned with each command.[18][27] Lifecycle operations and command creation accept an `Idempotency-Key` that the API keeps for 24 hours.[18] Applications do not need to embed a Rust library; the repository's first-sandbox walkthrough uses a standard-library Python example.[3]

### E2B compatibility

The E2B Compatibility Wrapper (ECW) lets existing E2B clients use SPACE as a backend by translating E2B-shaped HTTP requests into SPACE operations. Its tested baseline is the Python packages `e2b==2.21.1` and `e2b-code-interpreter==2.6.2`. ECW's pause maps to SPACE suspend and its resume to SPACE restore, and it rejects some create options such as `mcp`, `volumeMounts` and `iam`.[9]

### Requirements and versioning

The local installation guide deploys SPACE in a Kind cluster on an apt-based Linux x86_64 host with KVM, `/dev/kvm`, `/dev/net/tun`, loop devices, btrfs support and a Docker daemon that permits privileged containers. It does not run directly on macOS; a VM host must expose the required devices and support nested virtualization.[10]

SPACE 0.8.0 is the public baseline. The versioning plan makes 0.9.0 the final planned breaking-change release and ties 1.0.0 to stable service and sandbox lifecycle contracts covering the native HTTP API, the worker `node-api` gRPC API and the `spaced-bridge` gRPC API for in-guest integrations. The 0.8 host accepts stable guest daemon versions from 0.1.0 up to, but not including, 0.9.0.[7]

### Partners

According to Perplexity, Akamai has tested and launched SPACE on its cloud platform, Crusoe is adding it to its Managed AI Services portfolio, and [CoreWeave](https://aiwiki.ai/wiki/coreweave) has published guidance for deploying it for evaluation on CoreWeave's CKS.[1] SiliconANGLE described [Crusoe](https://aiwiki.ai/wiki/crusoe), CoreWeave and Akamai as partners already deploying the platform.[23]

## Background: Firecracker

Firecracker is a virtual machine monitor that [Amazon Web Services](https://aiwiki.ai/wiki/amazon_web_services) announced on 26 November 2018. It uses KVM to launch lightweight "microVMs" that combine VM-style isolation with container-like efficiency; at launch AWS said a microVM could start in as little as 125 ms and used about 5 MiB of memory, and that Firecracker was written in Rust, began from crosvm, and exposed a deliberately minimal device model to reduce attack surface.[21] The NSDI 2020 paper by Alexandru Agache and colleagues at AWS describes it as an open-source VMM specialized for serverless workloads, built to escape the usual trade-off between strong virtualization security with high overhead and lighter containers with weaker isolation, and deployed in AWS Lambda and Fargate.[20] The project is licensed under Apache 2.0.[28]

SPACE is one of several agent sandboxes built on Firecracker. E2B's open-source runtime also gives each sandbox one Firecracker microVM in its own cgroup and network namespace, with an nftables egress firewall and SNI- and Host-inspecting domain allow and deny lists.[22] A June 2026 comparative security study of AI code sandboxes by George Andronchik and Pavel Lokhmakov found that engine classes (microVM, userspace kernel and OCI container) separate cleanly on architectural measures, but products within a class do not, and that a product's version-pinning and patch policy is the dominant variable for operators.[25]

## Related work at Perplexity

Perplexity presents SPACE as part of security work led by its Secure Intelligence Institute, alongside BrowseSafe (a model and benchmark for detecting malicious instructions hidden in web pages), Numbat (a toolkit, open-sourced in July 2026, for detecting and investigating dangerous agent behavior on computers) and Bumblebee (a scanner, open-sourced in May 2026, for risky packages, extensions and AI tool configurations on developer machines).[1] Perplexity's separate [Portable Computer](https://aiwiki.ai/wiki/perplexity_portable_computer), launched on 25 August 2026, runs a version of Computer on local hardware. Its launch post says code and tool execution run in isolated sandbox environments and that security matches the cloud version of Computer, but it does not name SPACE.[29]

## See also

- [AI agent sandbox escapes](https://aiwiki.ai/wiki/ai_agent_sandbox_escapes)
- [NVIDIA OpenShell](https://aiwiki.ai/wiki/nvidia_openshell)
- [NVIDIA Open Agent Safety Platform](https://aiwiki.ai/wiki/nvidia_open_agent_safety_platform)
- [DeepSeek Elastic Compute (DSec)](https://aiwiki.ai/wiki/dsec)
- [Claude Code Permissions and Sandboxing](https://aiwiki.ai/wiki/claude_code_permissions_and_sandboxing)
- [AI agents](https://aiwiki.ai/wiki/ai_agents)
- [Red teaming (artificial intelligence)](https://aiwiki.ai/wiki/red_teaming)

## References

1. Perplexity. "Open-sourcing SPACE, the sandbox platform behind Computer." 15 October 2026. https://www.perplexity.ai/hub/blog/open-sourcing-space
2. Perplexity (@perplexity_ai). Post on X announcing the open-source release of SPACE. 15 October 2026. https://x.com/perplexity_ai/status/2110778478312481167
3. perplexityai/SPACE. "SPACE" (README). GitHub, accessed 19 October 2026. https://github.com/perplexityai/SPACE
4. Perplexity Engineering. "Making SPACE: Secure and efficient runtimes for long-running agents." 15 July 2026. https://www.perplexity.ai/hub/blog/making-space-secure-and-efficient-runtimes-for-long-running-agents
5. perplexityai/SPACE. "SPACE: Architecture." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/architecture.md
6. Perplexity Secure Intelligence Institute (K. Polley, N. Li, Y. Du et al.). "Escaping SPACE: Part I." 23 September 2026. https://www.perplexity.ai/hub/blog/escaping-space-part-i
7. perplexityai/SPACE. "Versioning and compatibility." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/versioning.md
8. perplexityai/SPACE. "Execution environment identities." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/execution-environments.md
9. perplexityai/SPACE. "E2B Compatibility Wrapper." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/ecw.md
10. perplexityai/SPACE. "SPACE: Install and configure locally." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/installation.md
11. perplexityai/SPACE. "Warm pools." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/warm-pools.md
12. perplexityai/SPACE. "Base snapshots." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/base-snapshots.md
13. perplexityai/SPACE. "Operator egress profiles." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/egress-profiles.md
14. perplexityai/SPACE. "Deployment-configured TLS interception exemptions." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/tls-interception-exemptions.md
15. perplexityai/SPACE. "Full network policies through ECW." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/ecw-network-policy.md
16. perplexityai/SPACE. "Configuration reference." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/configuration.md
17. perplexityai/SPACE. "Credential Manager storage token exchange." Repository design document, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/space/design/credential-token-exchange.md
18. perplexityai/SPACE. "SPACE API." API reference overview, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/api/index.md
19. GitHub REST API. Repository metadata and language breakdown for perplexityai/SPACE, retrieved 19 October 2026. https://api.github.com/repos/perplexityai/SPACE
20. Agache, A.; Brooker, M.; Florescu, A.; Iordache, A.; Liguori, A.; Neugebauer, R.; Piwonka, P.; Popa, D.-M. "Firecracker: Lightweight Virtualization for Serverless Applications." 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20), 2020. https://www.usenix.org/conference/nsdi20/presentation/agache
21. Barr, Jeff. "Firecracker - Lightweight Virtualization for Serverless Computing." AWS News Blog, 26 November 2018. https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/
22. e2b-dev/infra. "E2B Runtime" (README). GitHub, accessed 19 October 2026. https://github.com/e2b-dev/infra
23. Wheatley, Mike. "Perplexity AI open-sources its secure AI agent sandbox SPACE." SiliconANGLE, 15 October 2026. https://siliconangle.com/2026/10/15/perplexity-ai-open-sources-its-secure-ai-agent-sandbox-space/
24. NVIDIA AI (@NVIDIAAI). Post on X about the SPACE release. 17 October 2026. https://x.com/NVIDIAAI/status/2111488462264410553
25. Andronchik, George; Lokhmakov, Pavel. "AI Code Sandboxes: A Comparative Security Study. Part 1 of 2: Engine-Level Properties." arXiv:2606.08433, 7 June 2026. https://arxiv.org/abs/2606.08433
26. Perplexity. "SPACE Guide" (hosted documentation, version 0.8.0). Accessed 19 October 2026. https://space.docs.perplexity.ai/guide/index.html
27. perplexityai/SPACE. "Your first sandbox." Repository documentation, accessed 19 October 2026. https://github.com/perplexityai/SPACE/blob/main/docs/first-sandbox.md
28. firecracker-microvm/firecracker. GitHub repository (Apache-2.0 license), accessed 19 October 2026. https://github.com/firecracker-microvm/firecracker
29. Perplexity. "Introducing Portable Computer for local-first AI." 25 August 2026. https://www.perplexity.ai/hub/blog/introducing-portable-computer-for-local-first-ai