The Allowlist Is a Claim Until Someone Tests It on the Wire

In Perplexity’s red team against its own agent sandbox, “no VM-to-host escape was observed in 108 runs.” In the same exercise, before remediation, network-policy bypass succeeded in 11 of 54 partial-network runs. In the 54 runs with no network at all, it succeeded in none.

Two boundaries were under test there. The compute wall held every time. The network rule, the list of hosts an agent is allowed to reach, gave way in roughly one run out of five whenever it was switched on.

Perplexity also tested ten third-party sandbox platforms, without LLM agents: “We found at least one network-policy bypass in eight of the ten platforms tested.”

My reading of the two results together is simple. A network allowlist is a statement of intent until someone tests it on the wire.

What the red team measured

The source is Escaping SPACE: Part I. We covered SPACE itself in July and will not repeat its architecture here. The new material is the attack data.

Four models identified vulnerabilities in the network confinement implementation: Claude Opus 5.0, GPT-5.6 Cyber, GPT-5.6 Sol and Kimi K3. Two more, Fable and GPT-6 Astra, refused to perform the tasks.

The lesson Perplexity draws is about how the rule was enforced: “Relying only on the destination IP address at the host to determine whether a connection is allowed is insufficient.” Nothing in a policy file tells you which check sits behind it. The file lists hosts. The enforcement code decides what a match means. My reading is that the enforcement code, not the list, is where the weakness lives.

Read the numbers with the caveats they carry. The page has no byline and no publication date, and its internal references place it after September 10, 2026. Perplexity sells SPACE and reports its own fix, which makes it an interested party. Each test cell ran three times, so 11 of 54 is a small sample. The authors add their own hedge, and it applies to the clean 108 as much as to anything else: “the absence of an observed escape is not a proof of isolation.”

Even with those limits, the shape of the result is hard to wave away. The compute layer held. The layer written as a list of permitted destinations was where the bypasses happened.

Eight of ten, and what the vendors said

The third-party round ran from August 31 to September 1, 2026, and it did not involve LLM agents. No model improvised its way through those platforms. The bypasses were found by conventional tests.

Perplexity names nine of the ten platforms publicly, and seven of those nine had a bypass. Its Table 3 records vendor responses as of September 10:

Vercel: “Known limitation: Documented domain-fronting behavior.”
Modal: “Known limitation: Not classified by the vendor as a vulnerability.”
microsandbox: fixed in v0.6.18, with strict mode disabled by default.

Those statuses date from September 10 and may have changed. They still say something useful about where responsibility lands.

Vercel’s entry says the behaviour is documented. Modal’s says it is not classified as a vulnerability. My reading: once a vendor calls it a known limitation, the buyer who configured an allowlist on that platform owns the decision to accept it. For a human developer running a build, a documented egress quirk may be tolerable. For an agent that reads untrusted input and can write its own network calls, the same quirk can become the path an exfiltration takes. We have described that shape before, in When the Agent Sandbox’s Intended Feature Becomes the Exit.

The microsandbox entry raises a different operational question. The table pairs the fix with strict mode off by default and does not say whether the fix depends on it. If it does, the version number alone does not tell you what your deployment enforces. Somebody has to read the config.

In August we wrote that a bounty is a price on containment confidence. A bypass table is the other side of that price: the list of places where confidence was not yet earned.

Docker makes authority diffable

On September 24, 2026, Docker published the Sandbox Kit Specification v3 under Apache 2.0, announced by Christian Dupuis in From Dockerfile to Kit. It is a vendor spec launch with no measured data, so treat it as design intent.

The part that matters for this argument is its rule for change: “A version inside what was granted may apply without asking. Any widening stops and asks, and removing a deny rule counts.”

That sentence turns authority into something you can declare, version and diff. A new release that asks for one more host is a reviewable event. Deleting a deny rule is treated as widening, which closes a quiet route for permission creep.

Docker is also direct about the limit of its own spec. Without a conforming runtime, “the annotation is inert: an image and no enforcement.”

Put the two sources side by side. Docker’s spec addresses the declaration problem: what was granted, and when the grant changed. Perplexity measured the enforcement problem: whether traffic outside the grant actually stops. A diffable allowlist enforced by a runtime that checks only destination IP at the host can still leak, and the diff will show nothing, because the declaration never changed. You need the declaration and the test, and only the test tells you the declaration is true.

A buyer-side test for the allowlist

The test is small enough to run this week, and it has two halves that must both be present.

Baseline. From inside the sandbox, with the exact network policy production will use, make a request to a host on the allowlist. It must succeed. This proves the test harness works. A test that only checks for failure passes just as happily when the sandbox has no network at all.

Forbidden host. From the same sandbox and the same policy, make a request to a host the policy does not permit. It must fail. Then try to reach that host by other routes your vendor’s documentation mentions. If the vendor lists domain fronting as known behaviour, one of those routes is a forbidden host reached through an allowed front.

Record both results with the policy version and the runtime version. A pass on the baseline plus a block on the forbidden host is the only green state. Anything else means the allowlist is describing a network that does not exist.

Two cheap additions make the test worth more. Run it whenever the policy diff shows a widening, and whenever the vendor ships a runtime update. And where a workload can live without egress, give it none: in Perplexity’s data, the no-network runs recorded zero bypasses in 54.

Do this now

List every agent workload that runs with partial network access. That is the configuration where Perplexity measured bypasses.
For each sandbox vendor, pull its known-limitations list and match every entry against your allowlist. Anything touching egress gets a named owner and a written acceptance, or it gets removed.
Build the two-sided wire test above and attach it to every policy change and every runtime upgrade.
If you are adopting a declarative format such as Docker’s Kit spec, require a conforming runtime before you count the annotation as a control, and keep running the wire test after you do.
Move workloads that do not need egress to no network.

An allowlist you have never tested is a claim. The wire test turns it into evidence.

This analysis synthesizes Escaping SPACE: Part I (Perplexity, September 2026) and From Dockerfile to Kit: the Docker Sandboxes Kit Specification (Docker, September 2026).

Victorino Group helps engineering teams turn agent sandbox policies into tested, enforced controls. Let’s talk.