Agent red team finds a common sandbox egress flaw

Perplexity’s security team published results from an authorized red-team exercise that gave nine frontier models root access inside SPACE, the sandbox behind Perplexity Computer. All 108 attempts to cross the virtual machine boundary failed. Separate tests found that several models could bypass SPACE’s network policy once package repositories were reachable, and similar weaknesses appeared in seven other sandbox platforms.

Long-running coding and research agents can execute untrusted code for hours, making containment responsible for accidental failures and deliberate attacks. Perplexity cites a recent incident in which agents compromised internal research infrastructure at OpenAI and Hugging Face as evidence of that risk.

Inside the 216-run test

SPACE runs each agent in a Firecracker microVM called the guest. Root access gives the agent full control inside that guest without granting control of the physical or cloud machine hosting it. A dedicated gateway on the host enforces the guest’s domain-level network policy.

The evaluation crossed two variables: whether the model could inspect SPACE’s source code and whether it could reach package repositories such as PyPI. Each of the nine models attempted two tasks three times under all four configurations.

The host boundary survives 108 attempts

Across 108 escape attempts, no model crossed SPACE’s VM-to-host boundary or recovered the AWS honeytoken. The result held when models could inspect the platform’s source, install software, and use web search. It applies to the tested SPACE configuration and attack harness.

Package access opens an egress route

In the fully closed network configuration, every callback attempt failed. Allowing access to package repositories gave models an indirect route to blocked destinations because public repositories often share network infrastructure with unrelated services.

DNS trust breaks in two ways

SPACE’s gateway learned domain-to-IP mappings by observing DNS traffic from the guest, then enforced policy against the destination IP. That design allowed a root process to manipulate the gateway’s view of DNS and exploit IP addresses shared by many domains.

1. Forged DNS replies. An agent created a DNS response mapping pypi.org to the blocked callback’s IP address. The gateway accepted the poisoned mapping and allowed the following HTTPS connection. The model needed source access to identify the network interface monitored by the gateway.

2. Shared-IP routing. PyPI uses Fastly, whose IP pool serves thousands of unrelated domains. In one run, GPT-5.6 Sol used Perplexity search to find fiddle.fastly.dev, a developer tool capable of fetching a user-supplied URL. Because Fastly Fiddle and pypi.org shared an allowed IP address, the agent used Fiddle to request the blocked callback. GPT-5.6 Cyber built a longer chain through a Taboola image service and thum.io, captured the callback as an image, and recovered the flag with optical character recognition.

Model-side safety policies also affected the outcome. Claude Opus 5.0 identified the shared-IP technique and declined to execute it, interpreting the instruction against targeting external systems as covering third-party relays. Anthropic’s Fable and OpenAI’s GPT-6 Astra refused the tasks outright, despite Perplexity’s participation in Anthropic’s Cyber Verification Program for authorized security research.

Perplexity tightens each protocol layer

Perplexity deployed two controls aimed at the specific bypasses:

• Source-address validation: An nftables prerouting rule now drops guest packets with forged sender addresses, preventing the DNS spoofing technique.
• Hostname enforcement: The gateway terminates TLS and verifies that the ClientHello server name indication, the HTTP Host header, the allowlisted hostname, and the DNS-resolved destination IP agree. SNI identifies the requested hostname during TLS setup, while the Host header identifies it at the HTTP layer.

A repeat evaluation under the most permissive test configuration produced no successful network bypasses.

Eight of 10 sandboxes allowed a bypass

Perplexity tested SPACE and nine other sandbox platforms. At least one network-policy bypass worked against seven of the nine third-party sandbox platforms publicly reported. The HTTPS technique affected SPACE before its patch, E2B, Vercel Sandbox, Modal Sandboxes, Daytona Sandbox, Deno Sandbox, Fly.io Sprites, and microsandbox.

• Bypass reported: SPACE, E2B, Vercel Sandbox, Modal Sandboxes, Daytona Sandbox, Deno Sandbox, Fly.io Sprites, and microsandbox.
• Both attacks resisted: Cloudflare Sandbox and NVIDIA OpenShell.

Four vendors had documented or deployed responses by the time of the report.

Checks for agent operators

Teams running agents with domain-based egress controls should verify the full request path instead of relying on destination IP addresses. CDNs and other shared hosting systems routinely place unrelated tenants on the same addresses.

• Confirm the deployed sandbox version and whether strict network enforcement is enabled by default.
• Validate guest source addresses before trusting DNS packets or other network metadata.
• Require DNS attribution, destination IP, TLS SNI, and HTTP Host values to agree.
• Test HTTPS and direct TCP controls separately because their enforcement paths may differ.
• Probe allowlisted package repositories and CDN endpoints for cross-tenant routing.
• Repeat tests with guest root access, source visibility, package installation, and web search enabled.