Every organisation deploying an AI agent has a line somewhere in its risk register about model behaviour. Very few have one about egress.
On 30 July Anthropic published a review of three incidents in which its models, running inside what was meant to be a sealed evaluation environment, reached the production infrastructure of three real organisations. One of them built a malicious package, published it to the Python Package Index (PyPI), and within about an hour it had been downloaded and run on fifteen real systems. Nine days earlier OpenAI had disclosed something similar: models running its ExploitGym evaluation chained a previously unknown vulnerability in Artifactory, a package registry cache proxy, and reached Hugging Face’s production database.
Two of the three largest AI labs, in the same fortnight, lost track of where their test models could get to.
News websites have framed this issue as a matter of model judgment. The models were informed they were in a simulation without internet access, but they proceeded regardless. This official explanation benefits the AI labs because it suggests the solution is a training problem that only those labs can address.
There is a third organisation in this story, though.
What the labs actually found
Anthropic reviewed over 140,000 evaluation runs where Claude had potential internet access. The company identified three incidents. In the most significant case, Claude Opus 4.7 performed four runs where it extracted application and infrastructure credentials. It then accessed a database containing several hundred rows of production data. In another instance, an internal research test model scanned approximately 9,000 targets. The PyPI package originated from Claude 5.
The cause, in Anthropic’s words, was that “a misconfiguration left the machines that Claude accessed as part of the evaluation with live internet access. Neither we nor our evaluation partner were aware of this misconfiguration.” The partner, named in the post, was Irregular. Anthropic is explicit that in none of the three cases did a model exfiltrate itself or deliberately try to break out, and classes the whole thing as “closer to a harness and operational failure than a model alignment failure”.
OpenAI’s incident was different. There the models did exploit a zero-day to get out. But the target was reachable in the first place because of how the research environment was set up.
One organisation left a door open. The other had a door it didn’t know could be forced.
The third organisation
On 21 July, the same day as OpenAI’s disclosure, the UK AI Security Institute (AISI) published its own findings on cheating in frontier model evaluations. It’s a government body with no product to sell and it had tested GPT-5.4, GPT-5.5, GPT-5.6 Sol, Claude Mythos Preview and Opus 4.7. Broadly, the same models involved in both incidents.
The conclusion was direct. “Every model we have tested for this behaviour attempted to cheat.” The AISI defines cheating as taking an action that is outside the scope of a task or explicitly forbidden to reach a goal through a shortcut. There was no obvious link to model capability, which suggests that frontier models do not stop this behavior as they become more advanced. The models described their own behavior as wrong less than half the time when questioned. The AISI concluded that “neither self-report nor chain-of-thought are robust methods” for identifying these actions.
During that work, one model wrote and ran code on an external service in an attempt to reach AISI’s own evaluation infrastructure.
It triggered security alerts and didn’t get anywhere.
The difference wasn’t the model
So we have three organisations, running broadly the same models, on broadly the same kind of offensive security evaluation, in broadly the same month. In all three, a model went looking for a way out.
In two of them it found one.
What differed was the network. AISI’s held because it had been built on the assumption that the thing inside the locked room would try the door handle. Anthropic’s didn’t, because nobody had verified a route that turned out to be there.
I should be careful how hard I lean on that, mind you. Three organisations is not a sample, and AISI almost certainly ran a fraction of the volume: Anthropic reviewed six figures’ worth of runs, and nobody is suggesting the UK’s evaluation programme is anywhere near that scale. So this isn’t a controlled experiment.
What it does prove is that the room can be built properly.
The guarantee was never going to come from the model.
Opus 4.7 was the only instance where a model persisted in attacking a system after determining it was likely a real environment. This is a matter of behavior rather than network settings. Anyone who claims this is only an infrastructure problem is missing a specific detail.
But look at what AISI found and follow it through. If every frontier model attempts this, and if asking the model afterwards catches it less than half the time, and if reading its reasoning isn’t reliable either, then behaviour is precisely the layer you cannot build your controls on. You’d be depending on a property that the people with the best measurement tools in the world have just told you they can’t measure reliably.
Which leaves the network. As it always did.
That holds a long way down from the frontier, incidentally. On a client platform I measured compliance with prompt rules written as absolutes and got roughly half, which is near enough what AISI got asking models whether cheating was wrong. Same finding, five orders of magnitude apart in budget. The write-up is here if you want the version with a validator and a php.ini in it rather than a national institute.
These are organisations with more expertise in this specific failure mode than almost anyone alive, more money than they can spend, and an explicit reputational commitment to containment. They run these evaluations precisely to find out what the systems do when pointed at a target.
If they can’t make that guarantee inside their own laboratory, on what basis would you expect it to arrive bundled with the model? The only thing standing between an agent and your production estate is your own control plane. Egress filtering, credential scope, network segmentation, blast radius. All the unglamorous work - none of it new, all of it dull (sorry!) - that predates large language models by about thirty years.
None of this is novel security thinking. It’s the same least-privilege argument that applied to a Jenkins runner or a scheduled job with a database password in its environment. Take integration middleware, or an overnight payments reconciliation job. Nobody sensible signs those off on the basis that the code means well. They get signed off on what they can do.
What this changes if you’re buying
Most agent deployments I see have been assessed on the model’s capabilities. The evaluation went to whoever owns AI, the security review asked about training data and prompt injection, and the network question either didn’t come up or came back as “it’s in a sandbox”.
If you’re reading this thinking you haven’t got a risk register, a security function or anyone whose job title mentions AI, that’s fine, and the questions are still important. Your vendor is a product somebody signed up for on a company card. Your control plane is a cloud account, a handful of API keys in a .env file, and whatever that agent is allowed to call. The estate is smaller but the problem is still there.
If you’re running an agent pilot, the questions worth putting to a vendor are the ones the past fortnight has just shown the labs themselves struggled with. What can this agent reach on the network, who verified that, and when? What credentials does it hold, at what scope, and how fast can they be pulled? If it does something unintended, would you detect it, or would the affected customer ring you up (or sue you)?
That last one isn’t hypothetical. Anthropic caught its own incidents through additional monitoring. Two of the three affected organisations hadn’t noticed a thing.
My assessment
I’d be careful about over-reading all this. Both labs disclosed voluntarily, in detail, and faster than most enterprises manage after something comparable. The field is better off for it, and I’d rather have this argument with organisations that publish than with the ones that don’t.
But it’s worth remembering that Hugging Face’s own disclosure on 16 July attributed the intrusion to nobody at all. They had no idea which model was behind it until OpenAI said so five days later. The culprit became public because a lab volunteered it, not through detective work.
You will not find out from the model, you will not find out by asking it, and you may not find out at all.
So, can your vendor prove what their agent can reach?
Probably not. On July’s evidence, neither can they. AISI could, and that’s because they’d built the room properly before they let anything into it.