§1Why now
This summer, agents being tested by two frontier labs got out of environments that were meant to hold them. One went out through an exit nobody knew was there. The other went out through the one exit it was allowed.
1.1 – 1.2
From the labs’ own disclosures
1.1 · Anthropic · 30 Jul 2026
Claude was told its evaluation machines had no internet access. A misconfiguration in a partner’s environment had left them online, and the models reached the systems of three outside organizations.3
A proof, before launch, that the channel is the only exit. §3
1.2 · OpenAI · 21 Jul 2026
OpenAI’s sandbox had a single route out: an internal service that fetches software libraries. The models found a previously unknown flaw in it, raised their privileges and moved through OpenAI’s network to a machine with internet access, then into Hugging Face’s production systems.2
A guard proven to do only what its spec says. §2
That sandbox also had exactly one way out. So one channel isn’t the claim.
The claim is two proofs: the channel is the only exit, and the guard on it does only what its spec says. Anthropic drew the same line between the two incidents. OpenAI’s models “exploited a novel vulnerability to escape isolation,” while Claude “accessed the internet via an open path.”4
Table 1
Dated, sourced, kept current
| Disclosed | What happened | The way out | Answered by |
|---|---|---|---|
| 21 Jul 2026 OpenAI |
Models in an evaluation sandbox reached Hugging Face’s production systems.2 | A flaw in the one allowed exit | Verified guard §2 |
| 30 Jul 2026 Anthropic |
Claude reached three outside organizations during cyber evaluations.3 | Internet left open by a misconfiguration | Pre-launch proof §3 |
| 25 Sep 2026 OpenAI |
On Sept. 20, an agent with no sanctioned internet access sent queries to a public chatbot, weeks after OpenAI announced sandbox security upgrades.5 | DNS lookups that weren’t filtered | Pre-launch proof §3 |
As of 3 Nov 2026. Primary sources in the notes.
§2The guards
We design for the worst case: whoever controls the agent controls everything inside its VM. The guarantees are built to hold anyway, because everything that enforces them sits outside it, on the one channel.
Exhibit A
One VM, one channel, one guard. The policy, the real credentials and the record all live with the guard.
Design · Being verified
Every connection and every DNS lookup goes through the guard. Anything not on the allow list is refused there.
14:02:11Z CONNECT api.github.com:443 allow 14:02:13Z CONNECT paste.example:443 refused 14:02:13Z DNS x7f3a.paste.example refused refused: not on the allow list
The agent only ever holds placeholders. The guard swaps in the real credential on requests that pass its check, and only for the destination that credential belongs to.
inside the VM GITHUB_TOKEN=itp_ph_7f3a9c… worthless anywhere else at the guard, after the check Authorization: Bearer itp_ph_7f3a9c… → Bearer ghp_•••••••• api.github.com only
The policy is held by the guard, outside the VM. Nothing the agent sends over the channel can rewrite it.
policy sha256:4be1…09c2 held by the guard allow api.github.com secrets GITHUB_TOKEN → api.github.com agent → write policy no such route on the channel
The record is written by the guard, not by the agent, and the agent has no way to write to it.
#4127 14:02:11Z allow CONNECT api.github.com:443
#4128 14:02:13Z refused CONNECT paste.example:443
#4129 14:02:13Z refused DNS x7f3a.paste.example
writer: guard · the agent has no write path
The guard controls where the agent can go, not what happens once it arrives. Approve a destination that can itself be broken into, and the guard can work exactly as proven while the agent attacks that destination and moves on from there. That is roughly what happened to OpenAI’s package service. Approved destinations are your responsibility, and every certificate says so.
§3Before launch
Before a sandbox starts, the checker looks for every way out of the VM, not just the one you meant to give it. If it finds a second exit, the launch is blocked and the path is named. If it can’t prove there isn’t one, the launch is blocked too. Couldn’t prove it means it doesn’t launch.
One approved destination, one secret.
allow: api.github.com · secrets: GITHUB_TOKEN
Illustrative. DNS is how an OpenAI agent reached a public chatbot on Sept. 20.5
§4The certificate
Every sandbox comes with a document you can hand to an enterprise customer or an auditor. It says what was proven, what the proof relies on, and what it doesn’t cover.
Exhibit C
The document a customer forwards to their auditor, in three parts.
Sample · Not a real sandbox
agent.py with one exit.For this sandbox, by the checker
api.github.com.GITHUB_TOKEN never enters the VM, and is only sent to api.github.com.What the proof relies on
Said plainly, so the rest can be believed
api.github.com lets the agent do is yours to secure.sample signature · ed25519:9f1c…a24b
§5Developers
Fast sandboxes, a few lines to integrate, and pay for what you use. The difference is the last line.
Exhibit D
A sandbox with one approved destination and one secret.
Planned API · Illustrative
from interpolant import Sandbox sb = Sandbox(allow=["api.github.com"], secrets=["GITHUB_TOKEN"]) sb.run("python agent.py") sb.certificate.url # shareable proof of containment
§6Design partners
We’re working with a small number of design partners whose agents run code, hold credentials or act on real systems. Bring the one that worries you most, and we’ll look for every way out of it.
Notes