--- title: "Perplexity Open-Sourced Its Agent Sandbox. The Network Leaked, Not the VM." slug: "perplexity-space-open-source-agent-sandbox-network-boundary" author: "ibl.ai Engineering" date: "2026-10-19 10:00:00" category: "Premium" topics: "Perplexity SPACE, agent sandbox, Firecracker microVM, AI agent security, egress control, default-deny network policy, open-source AI infrastructure, self-hosted AI, enterprise AI governance" summary: "Perplexity open-sourced SPACE on 15 October 2026 under Apache-2.0, the Firecracker microVM sandbox behind its Computer product. Its own published evaluation records no escape from the VM to the host in 108 attempts, and some attempts that did get around network restrictions, which is the result worth reading closely." banner: "" thumbnail: "" linkedin: | Perplexity open-sourced SPACE on 15 October 2026 under Apache-2.0: the sandbox platform that runs every task in Perplexity Computer. Each agent task gets its own Firecracker microVM, and credentials and outbound traffic are controlled from outside that VM. The number everyone is quoting is the clean one. Perplexity's published security evaluation found no escape from the virtual machine to the host in 108 attempts. The sentence immediately after it is the one that should shape an architecture. Some attempts did find ways around network restrictions. Perplexity fixed those weaknesses and reports neither method worked in follow-up testing, and it disclosed related weaknesses it found in other sandbox platforms to those vendors. Read the two results together and they say something precise. The boundary made of hardware virtualization held. The boundary made of network policy is the one that leaked, and it leaked against the same class of technique that showed up in this month's other agent security stories. That is exactly why SPACE puts credential handling and egress control outside the sandbox rather than inside it. A boundary an agent can reach is a boundary an agent can argue with. Which leaves the question an enterprise actually has to answer. Apache-2.0 means you can run this yourself. Whether that helps depends on whether the network enforcing the policy is infrastructure you operate, because an egress allowlist is only as good as your ability to see what hit it. On ibl.ai you own all the code and the data. An agent sandbox starts with No Network and opens only as far as the egress profile you choose, down to a named allowlist of hosts. #iblai #AgenticAI #AISecurity #OpenSource #EnterpriseAI --- ## The Short Answer **Perplexity open-sourced SPACE on 15 October 2026 under Apache-2.0, giving every agent task its own Firecracker microVM with credentials and egress controlled from outside the VM. Its evaluation found no VM-to-host escape in 108 attempts, but some attempts got around network restrictions. On ibl.ai you own all the code and the data, so the perimeter enforcing that policy is yours.** The headline is that a frontier AI company gave away the isolation layer under its own agent product. That is real, and it is not the most useful sentence in the announcement. The most useful sentence is the one that admits what did not hold. ## What is Perplexity SPACE, and what did Perplexity actually release? The sandbox platform that runs every task in Perplexity Computer, released as open source rather than described in a paper. SPACE stands for Sandboxed Platform for Agentic Code Execution. The [repository](https://github.com/perplexityai/SPACE) describes it as pluggable-runtime sandboxes for running agent and user code in isolation, and it carries an **Apache-2.0** license, which is the permissive end of the spectrum and allows commercial use and modification without a reciprocal obligation. Perplexity [announced the release](https://www.perplexity.ai/hub/blog/open-sourcing-space) on **15 October 2026**. The architecture has two halves worth separating, because they fail differently. The first is isolation. Each SPACE sandbox runs inside a small virtual machine with its own operating system, creating a boundary between the agent's work and the host. The repository is specific about the mechanism: isolated [Firecracker microVMs](https://firecracker-microvm.github.io/), the same lightweight virtualization AWS built for Lambda. The second is what the sandbox is not allowed to hold. SPACE treats the sandbox as untrusted and manages network access and platform-held credentials **outside** the sandbox. Agents connect to authorized services without those credentials ever sitting in the environment the agent can read. Three infrastructure providers are named as already deploying it: **CoreWeave**, **Akamai** and **Crusoe**. That last detail matters more than a logo list usually does. A sandbox adopted by the companies renting out GPU capacity is a sandbox that gets attacked at volume. ## Did any model escape the SPACE sandbox in Perplexity's evaluation? Not from the virtual machine to the host. Some attempts did get past the network restrictions, and that distinction is the whole story. Perplexity's wording is worth quoting rather than paraphrasing, because the paraphrases circulating are not accurate. The published security evaluation "found no escape from the virtual machine to the host in **108 attempts**, but some found ways around network restrictions." Perplexity then states that it fixed those weaknesses and that neither identified attack method succeeded in follow-up testing. A number of secondary write-ups rendered this as 118 attempts with zero breaches. Both halves of that are off. The count in the primary source is 108, and "zero breaches" erases the only finding that teaches anything. So read the two results side by side. The boundary built out of hardware virtualization held, 108 times out of 108. The boundary built out of network policy did not hold, and had to be patched. That ordering is not a coincidence and it is not specific to Perplexity. A microVM boundary is enforced by the CPU and is not something a language model can talk its way through. A network restriction is a policy, and policies have edge cases: an unexpected protocol, a permitted host that proxies to a forbidden one, a DNS path nobody enumerated. The honest lesson from SPACE is that the hard part of agent containment was never keeping the process inside the box. It is controlling what the box is allowed to talk to. This is the same failure surface that [India's CERT-In documented in advisory CIAD-2026-0049](/blog/cert-in-ai-agents-attack-vectors-egress-control), where every recommended control turned out to be a property of the perimeter rather than of the model, and it rhymes with [the eval agents that reached Hugging Face infrastructure](/blog/openai-eval-agents-hugging-face-intrusion-containment-you-own). Three separate stories in one month, all converging on egress. ## Why does SPACE keep credentials and network egress outside the sandbox? Because anything inside the sandbox is reachable by the thing you are trying to contain. This is the design decision in the release that is worth copying regardless of whether you ever run SPACE. If a credential lives in the agent's environment, then every prompt injection, every poisoned web page and every confused-deputy bug is one step away from exfiltrating it. The agent does not need to escape the VM. It just needs to read its own environment variables and make an allowed outbound request. Moving credential injection and egress enforcement to the host side changes the threat model. The agent gets the *effect* of authenticated access without ever holding the secret, and the component deciding which hosts are reachable is not running inside the blast radius. The structural point: **a boundary the agent can reach is a boundary the agent can argue with.** A boundary enforced one layer down is not. That principle is why the interesting question about any agent sandbox is not "how strong is the isolation" but "who operates the enforcement point." ## What does an open-source agent sandbox change for an enterprise running its own agents? It removes the licensing obstacle and leaves the operational question entirely intact. Apache-2.0 means a health system, a bank or a university can run this inside its own network with no vendor conversation. That is a genuine shift, and it arrives alongside [NVIDIA's Open Agent Safety Platform](/blog/nvidia-open-agent-safety-platform-containment-in-silicon), which put a comparable runtime boundary under an open license in September 2026. The containment layer is commoditizing fast. What open source does not do is answer the detection question. An egress allowlist produces value only when somebody can see what hit it. If the agent runs in a vendor's account and the logs live in the vendor's systems, you have bought a policy you cannot audit, and your incident timeline starts whenever the vendor completes its own internal review. CERT-In's advisory is the empirical case: not one affected organization found the intrusion itself. So the checklist an enterprise should take from this release is short. Run the agent inside a boundary enforced below the agent, not configured within it. Hold credentials outside the execution environment. Default the network to deny and open it host by host. Keep the telemetry somewhere you can query without asking permission. Every item on that list is a property of infrastructure you operate. ## How does ibl.ai handle agent sandboxing and egress control? With the enforcement point and the logs on the customer's side of the line, because that is the only version of this that an enterprise can audit. On ibl.ai **you own all the code and the data**, running **model-agnostic** across any LLM with **no per-seat pricing**, so you can **deploy anywhere** — your cloud, on-premise, GovCloud, or a fully air-gapped network. For agent execution specifically, an ibl.ai [sandbox](https://ibl.ai/docs/os/agent-settings/sandbox) starts at **No Network** and opens only as far as the egress profile you select, down to a named allowlist of hosts. Credentials reach tools through the broker rather than through the agent's environment. Every call an agent makes lands in an [audit trail](https://ibl.ai/docs/os/analytics/audit) you query in your own deployment, and per-agent [roles](https://ibl.ai/docs/os/organization-settings/roles) bound what each agent can reach before any of this is tested. The difference from a hosted agent product is not the strength of the isolation. Firecracker is Firecracker. The difference is that when something does get around a network restriction, as Perplexity's own evaluation shows it can, the organization that notices is you. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ## The Takeaway Perplexity did something unusually honest here: it published the attempts that worked alongside the ones that did not. Strip the release down and it reports one boundary that held under 108 attempts and one that needed patching. The one that held was made of silicon. The one that leaked was made of policy. Plan accordingly, and own the policy. ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.