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 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 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, 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, 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.
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, 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 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 you query in your own deployment, and per-agent 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.