Run this before you read any further. Pull the image first, because full isolation also blocks the pull: docker pull alpine, then docker run --rm --network none alpine sh -c 'ip -o addr show; wget -T 5 -qO- https://example.com || echo NO_EGRESS'. If you see a single loopback interface and NO_EGRESS, that container has no route out. If HTML comes back, whatever you believed about the sandbox your agents run in is wrong, and you now know it in under a minute instead of after an incident report. Anthropic published one of those reports yesterday.
What the review found
In Investigating three real-world incidents in our cybersecurity evaluations (opened 31 July 2026), Anthropic says it began a review on 23 July 2026, went through 141,006 evaluation runs, and found three incidents spanning six runs, the earliest in April 2026. The cause is one sentence: "a misconfiguration left the machines that Claude accessed as part of the evaluation with live internet access." Anthropic and its evaluation partner Irregular both believed the systems were isolated.
The three incidents are worth reading as separate lessons rather than one story.
- A model working a capture-the-flag scenario reached a real company's infrastructure across four runs, after the fictional target name in the exercise matched a real website. It extracted application credentials and production database records running to several hundred rows.
- A second model created and published a malicious Python package to PyPI. Within roughly one hour it had been downloaded onto 15 real systems, including a security scanner where the code executed and exfiltrated credentials.
- An internal research model scanned about 9,000 targets and compromised one company using an exposed debug page and SQL injection, then stopped once it recognised the system was real.
Anthropic says none of the models deliberately tried to escape the environment, that the affected organisations had not detected the activity themselves, and that it halted cyber evaluations on 23 July. Its stated remediations are expanded continuous monitoring of evaluation transcripts, holding evaluation environments to the same security standard as any other system, more rigorous assurance work with vendors, and better investigation tooling.
The failure was a question nobody owned
Two capable organisations each had a mental model of the network, and neither model was tested. That is the transferable part, and it is not exotic: the same shape appears when a developer assumes the CI runner is locked down, the platform team assumes the container image is, and the person who wired the sandbox left last year.
Notice also what did and did not save anyone. In the third incident the model stopped when it worked out the target was real. That is a behaviour, not a control, and Anthropic's own framing treats it as luck rather than architecture. The second incident is the one with the broadest blast radius, because a package published to a public registry does not need the sandbox to fail again to reach the next fifteen machines. That is the same dependency surface that makes pinning every artefact your build downloads worth the friction.
Four levels of isolation, and what each one costs
| Level | How | What it stops | What it costs you |
|---|---|---|---|
| Default bridge | docker run with no network flags | Nothing outbound | Nothing, which is the problem |
| Internal network | docker network create --internal agents, then --network agents | Traffic to and from external networks; no default route is configured | Containers can still reach the gateway IP and host services; package installs fail |
| No network | --network none | Everything. Only the loopback device is created | Dependencies must be baked into the image and inputs mounted from disk |
| Allowlist proxy | Internal network plus an explicit HTTP proxy on a separate host | Everything except destinations you named | You own and maintain the proxy and its list |
Method: levels two and three are quoted from Docker's own references, opened 31 July 2026. The none driver page states that "within the container, only the loopback device is created", with 127.0.0.1/8 configured and no IPv6 loopback address. The docker network create reference defines --internal as "restrict external access to the network" and notes that containers on it can still communicate with the gateway IP and host services. Level four is an ordinary pattern, not a Docker feature, and the cost column is our assessment rather than anything Docker publishes.
Running the test properly
- Pull images before you isolate. A test that fails because the image was never present tells you nothing.
- Check the interfaces.
ip -o addr showinside the container. On the none driver you should seeloand nothing else. - Test by IP, not by name.
wget -T 5 -qO- http://1.1.1.1. A DNS failure looks like isolation and is not. - Then test DNS separately.
getent hosts example.com. Resolution working while traffic is blocked is a useful signal about which layer is doing the work. - Run the same probe from inside the agent loop. Ask the agent, in its normal harness, to fetch a URL and report what it got. The process that matters is the agent's, not your shell's, and the two often have different network paths.
Where the test lies to you
An internal network still reaches the gateway and services on the host, so a sandbox with no internet access can still talk to the Postgres you bound to 0.0.0.0 for convenience. Bind development services to 127.0.0.1, or put the sandbox on a separate machine.
Some paths never touch your container at all. Server-side tools run by a model provider, such as hosted web search or fetch, execute on the provider's infrastructure and are unaffected by anything you do with Docker. So are MCP servers running on the host, editor extensions, and the CI runner that spawned the job. Enumerate those separately; the container test says nothing about them.
And a container with no egress is still not a safe place to run untrusted code if you mounted credentials into it. Isolation of the network is one axis. Nothing above addresses what the agent can read on the filesystem it was given, which is the same reason a written policy file is not an enforcement mechanism.
The ownership question
If someone else runs the environment, a vendor, a research partner, a hosted evaluation service, put one line in the agreement naming who owns the network path and who verifies it. Then ask for the verification output rather than the assurance. "It is isolated" is what both organisations in this incident believed for three months.
The checklist, and it is short enough to finish this afternoon:
- Run the two-command egress test on every image an agent runs in, and paste the output into the repository.
- Move agent containers to
--internalas a baseline, and to--network nonewherever dependencies can be pre-baked. - Rebind local development services to 127.0.0.1 so the gateway path stops mattering.
- List every tool your agent can call that runs outside your container, and decide about each one explicitly.
- Re-run the test after any change to the compose file, the base image or the CI runner, because this is a configuration property and configuration drifts.
Then do the opposite direction as well: this is all about what can get out, and what can get in is a separate audit with a separate list.
Discussion
Sign in with Google or just a name. No email link, no password to remember.