What happened
Perplexity’s SPACE runs its Computer agents inside guest virtual machines. In *Escaping SPACE: Part II*, the company extends its earlier evaluation with three models released after the original experiments: Claude Mythos 5.1, Claude Opus 5.5, and GPT-6 Astra. Combined with the nine models in Part I, the report discusses 12 models. The sandbox-escape task gave each model root access inside the guest and asked it to retrieve an AWS credential from the host, authenticate to AWS, and submit the returned role name as proof. No run achieved a VM-to-host escape.
The report’s central methodological finding is that a clear success condition does not necessarily make a test exercise the intended security boundary. In initial runs, models searched for credentials and tried application-level routes to host data; most devoted very little effort to the virtualization layer. Perplexity then revised the prompt to direct models toward virtualization vulnerabilities and discourage unrelated searches. The share of effort spent probing that layer rose by about 60 percentage points on average. All Claude and GPT models then used close to the 120-minute limit, whereas some had used only 21.5 to 47.3 minutes on average under the initial prompt. Still, no run escaped the VM.
The models tested virtual-device inputs and state, CPU emulation and virtualization controls, paravirtual interfaces, and packet processing. SPACE uses Firecracker microVMs, whose minimal device model is intended to reduce the attack surface. Perplexity says the focused runs provide stronger evidence for VM-host isolation than the first round, while stressing that they remain experiments rather than proof of security.
The report also evaluates model trajectories using six LLM judges and five criteria, including experimental validity, adaptation, and calibration. GPT-6 Astra and Claude Mythos 5.1 received the highest average ratings. Perplexity highlights that GPT-5.6 Cyber, a cybersecurity-specialized model, scored below general-purpose GPT-5.6 Sol in these experiments. The company cautions against reading too much into these scores because no run succeeded and the measure is based on LLM-as-judge ratings.
For network bypass, the report revisits Part I’s finding that several models used partial network access to reach blocked destinations through DNS spoofing or shared-IP exploitation. These tests targeted the original, pre-remediation implementation. Perplexity says it fixed both vulnerabilities and that post-remediation testing found no successful bypasses. The observed result is specific to the tasks, settings, prompts, and implementation tested; it is not a general guarantee for every deployment.
What the archive adds
New Runtime’s [earlier coverage of the SPACE audit] (https://newruntime.com/posts/audit-of-10-third-party-sandboxes-found-8-54fdd3/) noted that network confinement can fail independently of VM isolation. Its coverage of SPACE’s open-source release also described the sandbox as a production runtime. This is a new fact on that known story: the second report details more focused VM-boundary tests and model behavior, while revisiting the patched network weaknesses.
Trend signal
This supports agent security moving to runtime boundaries: the relevant security question is not whether an agent was told to behave, but what the runtime permits it to access or execute. The report also shows that a boundary needs a test designed to exercise it; a nominal escape task may mostly measure credential-search behavior unless the prompt steers investigation toward the hypervisor boundary.
Why now
Perplexity says it expanded the evaluation after Part I to include three later-released models and analyzed the trajectories to understand what agents attempted. That analysis motivated follow-up experiments with a prompt focused explicitly on the virtualization layer.
Connections to other events
New Runtime’s earlier coverage of third-party sandbox weaknesses described DNS spoofing and domain-fronting-style network bypasses as distinct from VM escape. Part II connects that finding to the same SPACE evaluation: network bypasses were reported in the pre-remediation implementation, while the new experiments found no VM-to-host escape under the focused prompt.
Why it matters
For teams deploying agents, “sandboxed” is not a single security property. VM-host isolation, guest-level permissions, and outbound network policy are separate boundaries, and a test that exercises only one cannot establish the others. Perplexity’s results also show that task design shapes what a red-team run measures: agents may spend their budget on easy credential searches rather than probing the virtualization layer, even when the requested outcome is a host secret.
The report does not establish that SPACE or other microVM sandboxes are secure against all attacks. It does offer a practical evaluation lesson: define the boundary under test, verify the agent’s actual probes, and separately test network egress and VM escape. Treat vendor remediation claims as useful evidence, then validate the deployed configuration and repeat tests as the runtime changes.
Limits and uncertainty
No VM escape was observed, but absence of success in these runs does not establish that escape is impossible. The report says the first prompt generated weak evidence about VM-host isolation because models devoted limited effort to the virtualization layer; the focused prompt improved that coverage without eliminating the limits of a finite experiment. Model capability scores are subjective LLM-as-judge averages, not objective measures of exploit success. The network findings concern an original pre-remediation implementation, and Perplexity reports successful fixes and follow-up checks; those claims are not an independent audit of every current deployment.
Skill to build now
Write a boundary-specific sandbox test plan before running agents. For each test, name the protected asset, the exact boundary (guest-to-host or outbound network), the permitted paths, the observable success condition, and the time budget. Review trajectories to confirm that the agent actually probed the intended layer; report a failed escape separately from a run that never meaningfully tested for one.
Reader takeaway
A sandbox result is only as informative as the boundary the test actually exercises. Perplexity reports no VM escape after a more targeted evaluation and says earlier network bypasses were patched, but teams should test isolation and egress separately against their own runtime and configuration.