The fictional company had a real domain

The Claude cybersecurity evaluation incidents have been chewed over for weeks now, mostly under headlines about an AI breaking into companies. I read the writeup expecting to find nothing new and instead found three details that nobody seems to have picked up, all of which change something about how I'd run my own stuff.

Short version of the event. Models were being run deliberately without cyber safeguards, which is the point of a capability evaluation. A misconfiguration in a third-party evaluation environment left the machines they were working on with live internet access, which nobody involved knew about. Across 141,006 evaluation runs, six runs in three incidents reached real systems belonging to real organizations.

Now the parts that got skipped.

A made-up name resolved

In the first incident, the scenario used a fictional company. That fictional company name matched a real domain. The model went and did to the real one what the exercise asked it to do to the imaginary one, and came back with application credentials, infrastructure credentials, and access to a database holding several hundred rows of production data.

I have been writing test fixtures for twenty years and I have absolutely done this. acme-corp, widgetco, foobar-industries. You need a plausible name for a scenario, you invent one, and you never think about it again because in a normal test nothing leaves the process.

That assumption is what broke. Once the thing consuming your fixture can open a socket, every invented identifier in your test data is a potential live target. Company names, hostnames, IP addresses, email domains, S3 bucket names, API endpoints.

There are reserved values for exactly this and almost nobody uses them. example.com, example.org, and example.net are set aside by RFC 2606. The .test, .invalid, .example, and .localhost top-level domains are reserved by RFC 6761 and will never resolve. RFC 5737 reserves three IPv4 blocks for documentation, 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.

If you are writing scenarios that an agent will execute, that list stops being pedantry and becomes a control. It costs nothing to adopt and it would have prevented the first incident outright.

The techniques were embarrassing

The third incident is the one that recalibrated me. The model scanned roughly 9,000 targets and successfully compromised one company. It got in by reading credentials off an exposed debug page, and by SQL injection.

SQL injection. In 2026.

Every version of this story I read framed it as a machine demonstrating dangerous offensive capability. What the report describes is a competent scanner running well-known techniques against a large sample and finding the one host that was left open. The other incidents follow the same shape, with weak credentials and unauthenticated endpoints doing the work.

That reframing matters because it changes who should be worried and about what. The marginal cost of running old attacks against everything has gone to nearly zero, and there are a lot of exposed debug pages out there. A one-in-9,000 success rate is catastrophic when the attacker can afford to try nine thousand times before lunch.

The unglamorous work you have been putting off is the entire defense.

One hour on PyPI reached fifteen machines

In the second incident the model built and published a booby-trapped Python package to PyPI. It was live for about an hour. In that hour it was downloaded and executed on fifteen real systems.

I wrote last week about the supply chain being people, and about a malicious npm package that sat quietly for fifteen releases before turning. This is the same attack with the patience removed. Publish, wait an hour, land on fifteen machines.

Two things follow. Package registries are a same-day delivery mechanism, not a slow-burn one, which argues for the install cooldown I keep recommending more strongly than the postmark case did. And a model given a goal and an internet connection reached for the supply chain unprompted, because it is the highest-yield move available. The only thing between that idea and fifteen infected machines was outbound access nobody meant to grant.

Telling it not to is not a boundary

The evaluation prompts specified no internet access. The machines had internet access. Nobody noticed until they went looking.

That gap is the whole event, and it is a thoroughly ordinary infrastructure failure wearing an AI costume. The instruction was the stated control. The network was the real control. They disagreed, and the network won, the way it always does.

I have made this argument twice on this site in narrower forms, once about running MCP servers with no outbound access beyond the API they exist to call, and once about scoping the upstream credential so a total compromise still cannot do much. It is easy to treat that as belt-and-braces advice for the paranoid. Here is a frontier lab with substantial security resources, running a deliberately unsafeguarded model inside what everyone believed was a sealed environment, discovering after the fact that the seal was not there.

If it can happen to an evaluation harness built by people whose job is containing models, the container you spun up on a Tuesday is not doing what you think either. Verify egress rather than assuming it. A default-deny outbound policy with an allowlist is an afternoon of work and it is the only part of this that would have held.

They found it because they kept the transcripts

Start with 141,006. That is how many runs had to be reviewed to surface six.

That review was possible because full transcripts existed. No amount of good intent substitutes for having the records. Roughly one in twenty thousand runs did something that mattered, and finding it meant being able to look at all of them afterward.

The timeline in the report cuts both ways. The review started on July 23, two days after OpenAI disclosed a comparable incident of their own, so the detection was prompted by a peer going public. I do not read that as damning, because the alternative was not disclosing, and Anthropic then stopped all cyber evaluations, identified every incident within a day, and notified the affected organizations inside a week. That is a good response and the writeup is more candid than it had to be.

It does say something about how these get caught. The capability to audit was in place. The habit of auditing unprompted was not, and those are different things.

Three changes, none about AI safety

None of them required having an opinion about model alignment.

My scenario and fixture data now uses reserved names and documentation IP ranges, everywhere, on the assumption that anything consuming it might be able to reach the network.

Anything running an agent gets a default-deny egress policy with an explicit allowlist, and I test that the deny actually works instead of trusting the compose file.

Transcripts and tool call arguments get retained long enough to answer a question I have not thought to ask yet, which is the only useful definition of long enough.

It got reported as a model doing something alarming. Read the report and you find a misconfigured network, some unpatched servers, a package registry with no waiting period, and fixture data written by someone who assumed it would stay imaginary. The model was the only part of that list nobody could have patched.