Zero escapes and eleven callbacks

At a glance

SPACE stands for Sandboxed Platform for Agentic Code Execution. It runs each agent task in its own Firecracker microVM, exposes an HTTP API to create a Linux environment, run commands, collect output and tear the sandbox down, and it is now Apache 2.0 on GitHub. CoreWeave and Akamai are reported to have tested and launched it on their own clouds, with Crusoe bringing it into its managed AI services. Perplexity's own announcement and report were not directly reachable while writing this piece, so every figure below is as reported by outlets covering the release — and the counts differ between them, which is itself worth knowing before you cite one.

The isolation result is real and it answers a question nobody is losing on

Take the result at face value first. Nine model configurations, given root inside the guest and pointed at a secret planted on the host, produced no escape across a hundred and eight runs. That is a genuinely useful datum, because it is the first time anyone has published an agent-driven escape attempt against a production microVM boundary at that scale, and the result matches the theory: a hardware virtualisation boundary with its own guest kernel is a different class of control from namespaces, which is the whole argument in sandbox and isolation patterns.

It is also the control that was already working. Look at the agent containment failures disclosed this year — the evaluation runs that reached live third-party systems, the harness incidents, the agents that authenticated with credentials lying around in configuration — and none of them turned on a guest kernel exploit. The agent did not break out of the box. It used the network the box was given, with the credentials the box was handed, exactly as configured. A zero in the escape column does not speak to any of that, and the reason to say so plainly is that "zero escapes in a hundred and eight attempts" is precisely the sentence a procurement deck will carry.

This is the same confusion in a new costume. We wrote it up in the microVM held, the mount did not: compute isolation gets measured, gets a number, and then the number is read as a statement about the whole boundary. Perplexity's own report is better behaved than its coverage — it reports the second experiment too.

Eleven of fifty-four is the result that describes this year

The second experiment allowed partial network access — the configuration everyone actually runs, because an agent that cannot install a package fails its first task — and asked whether the guest could reach a host it was not supposed to. Before fixes, eleven of fifty-four runs retrieved a callback. The two reported techniques are the two that have always worked against name-based filtering. If enforcement happens on the hostname in the request and the guest can answer its own lookups, the guest sends an allowed name to an address it chose. If enforcement happens on the resolved address, then on a CDN or any multi-tenant cloud one permitted address is shared with every other tenant behind it.

The detail that makes this concrete rather than theoretical is which entry opened the door: the policy allowed package repositories such as PyPI. That entry is not a mistake, it is the minimum required to make the sandbox useful — and it is a channel purpose-built to serve content that arbitrary strangers published. You cannot write an allowlist that contains a package index and also claim the list bounds what the guest can fetch or reach.

Perplexity says both techniques were fixed and that follow-up testing retrieved no callbacks, and there is no reason to doubt it. The transferable lesson is not about those two bugs. It is that the egress policy is a separate control with its own failure modes, its own tests and its own budget, which is the argument egress control for agents makes at length — and that an allowlist is a scope control, not a confidentiality control. Any permitted destination that accepts arbitrary content is an exfiltration endpoint, and a URL is wide enough to carry a secret, per covert channels.

The design decision worth copying is not Firecracker

Strip the announcement down and the structural claim is one line: the sandbox is always treated as untrusted, and both network access and platform credentials are managed from outside it. That is a stronger statement than the microVM, and it is the part most sandbox products leave to you.

It matters because of what the red team assumed. Both experiments started with root in the guest. Under that assumption, every control implemented inside the guest is decoration — an in-guest allowlist, an in-guest resolver configuration, an environment variable holding a token. A control is only a control if it sits where the compromised party cannot edit it. Moving the policy outward makes the eleven-of-fifty-four result a bug in a proxy you can patch once, rather than a property of thousands of guests you cannot reach. Two concrete consequences follow, and both are cheap:

• No default route. The guest's only reachable address is the proxy. This is the property that makes everything else enforceable and the one most setups skip, because it means configuring the runtime rather than writing a firewall rule.
• The token terminates at the proxy. If the vendor credential is attached on the way out, the guest never holds it, and a compromised agent cannot carry it anywhere the proxy declines to send it — the pattern in credential delivery to the sandbox and scoped credentials for agents.

Neither requires Firecracker. If you are on gVisor, on a shared-kernel container you have decided to accept, or on somebody's managed runtime, the policy-outside-the-guest arrangement is available to you today and is worth more than a tier upgrade in isolation.

Eight of ten is a question for your vendor, not a scandal

Perplexity also ran the network attacks against ten third-party sandbox platforms and reports that eight allowed at least one bypass. Read that carefully, because it is a competitive publication from an interested party and it is still the most useful number in the report.

What it is not: evidence that eight products are broken. Most agent sandboxes ship egress permissive on purpose, document it, and expect the operator to narrow it — which means "allowed a bypass" partly measures a default, not a defect. What it is: a strong prior that the egress behaviour of the sandbox you rent is untested by you, probably permissive, and almost certainly enforced somewhere the agent can reach. Nobody who had run this test on their own deployment would be surprised by their own result.

So turn it into three questions for whoever runs your sandbox, which is the vendor-risk exercise in third-party model and vendor risk:

• Where is the egress rule enforced, and can a process with root in the guest change it? If the answer is a config file or resolver setting inside the image, the rule is advisory.
• Can the guest resolve arbitrary names? If yes, there is an egress path that most network policies never look at.
• Does a denied connection appear in the trace next to the tool call that caused it? A blocked request is either a policy gap or the earliest evidence that an injection landed — see detecting agent compromise. In a network log nobody joins to a run, it is neither.

Then run the test yourself. The attacks in the report are not exotic: plant a secret, give the guest a policy that allows a package index, and see whether a callback arrives. If you run capability evaluations, run it there first — the eval bench is the least hardened environment most teams own, which is the whole of the eval harness had no egress policy and evaluating against live systems.

What this changes for the build-or-rent decision

An Apache-2.0 microVM sandbox with cloud partners behind it narrows the gap between renting a sandbox and running one, and the honest summary is that it narrows it on the dimension that was already commoditised. Startup latency, pooling and lifecycle management are what the hosted sandbox market competes on — the ground covered in E2B vs Daytona vs Modal vs Northflank — and those are now available in a package you can host.

The dimension that does not arrive with the package is the policy. SPACE gives you the place to put it and does not write it for you: the per-task destination set, the derivation of that set from the tools the task was granted, the sequencing that shrinks the network the moment untrusted content enters the context, the logging join. That work is the same whether you host the sandbox or rent it, and it is the work that would have prevented every containment incident disclosed this year. Sandbox pools and cold starts is the operational half; blast radius is the reason to bother.

Further reading

On this wiki:

• Egress Control for Agents — the three jobs an egress policy does, and the proxy architecture that enforces them.
• Sandbox & Isolation Patterns — microVM versus gVisor versus remote-only, by blast radius.
• Credential Delivery to the Sandbox — why the guest should never hold the token.
• Sandboxing & Code Execution — the concept, from first principles.
• gVisor vs Firecracker vs Kata vs Wasm — the isolation tiers compared.

Sources:

• SiliconANGLE — Perplexity AI open-sources its secure AI agent sandbox SPACE
• MarkTechPost — Perplexity open-sources SPACE, a Firecracker microVM sandbox for AI agents
• Semafor — Perplexity to give away its AI security software
• AI Weekly — Perplexity open-sources SPACE, says zero escapes in 118 tries