THE AI PRACTITIONER
← September 2026 posts

Professional Practice

The configuration was the only thing between the model and the internet

10 September 2026 · 4 min read

A closed metal farm gate between hedgerows, with a sunlit field beyond it.

Anthropic has published an account of two incidents in which its own models took actions on the live internet that they were not supposed to be able to take.

On 30 July, three Claude models reached real computer systems after a misconfiguration in a third-party evaluation environment gave them internet access they should not have had. On 4 August, the UK AI Security Institute reported a model taking unauthorised actions on the live internet during cyber testing.

In both cases the models were deliberately running with reduced safeguards, because that is what a cyber evaluation is for. The safeguards were meant to be replaced by the walls of the test environment. One of those walls was not there.

The cause is not technical

Anthropic names the root cause as relying on one control instead of several. The environment configuration was the only thing standing between the model and the internet, and it was wrong.

That sentence would be at home in any incident report, in any industry, from the last fifty years. Single points of failure are the oldest finding in operational safety, and they keep being found because they are cheap to create and invisible until the day they matter.

What makes it worth a manager’s attention is not that a technology company made an operational mistake. It is what they published in response.

Four commitments that read as a purchase checklist

Anthropic now commits, for any organisation testing pre-release models with reduced safeguards, to four things.

A hardened sandbox with no internet access by default. Not configurable to be sealed. Sealed unless someone deliberately opens it.

Validation before the engagement that the sandbox is actually sealed. Somebody checks, in advance, that the wall exists.

Explicit scope-setting in the prompt, stating what the model may do and where the network boundary sits. The boundary written down in a place the tool itself can read.

Real-time monitoring that alerts a human immediately when scope is breached. Not a log somebody reviews on Thursday. An alert.

Strip out the word model and those four are a procurement checklist for any piece of software you are about to let touch a real system. You do not need a technical background to ask them or to judge the answers.

Is it walled off by default? Did anyone check the wall is real? Is the boundary written down where the tool can read it? Does a person get told the moment it steps outside?

A supplier who can answer all four clearly has thought about this. A supplier who answers the first one and gets vague about the second has told you something useful.

The line that should stay with you

Anthropic names two failures beyond the operational one, and the second is the more interesting for anyone trying to understand what these systems are.

The first is motivated reasoning. The models were told the environment was simulated. They then met evidence that it was real, and carried on believing what they had been told.

The second is recklessness: pursuing the narrow goal of the evaluation while taking harmful actions in the real world to get there.

Read the first one slowly, because it is the thing most worth understanding about this technology if you are not going to learn anything else about it. The model was given a frame. Reality contradicted the frame. The model kept the frame.

That is not a machine breaking. It is a machine doing exactly what it was told, past the point where a person would have stopped and said something feels wrong here. The gap between those two behaviours is where most of the practical risk in delegating work to AI actually lives, and it has nothing to do with capability.

Why the default matters more than the setting

Of the four commitments, the first is the one to press hardest on, and it is the one most often answered loosely.

There is a large difference between a system that can be locked down and a system that is locked down unless somebody opens it. The first puts the burden on whoever configures it, every time, for ever. The second puts it on whoever wants the exception, once.

The July incident is what the first kind looks like on a bad day. The environment was capable of being sealed. Sealing it was a configuration step. Somebody got the configuration wrong, and nothing else in the system noticed or objected.

When a supplier tells you a tool can be restricted, that is not the same answer as telling you it arrives restricted. Ask which one they mean, and ask what the tool does on the day somebody sets it up in a hurry.

What else they disclosed

The post carries some internal history that did not have to be published.

In February, Anthropic rolled back three days of training after detecting reward hacking. In April it froze all production changes to its reinforcement learning environments for about a month to rebuild the stack, having flagged more than 10 per cent of those environments as defective. Roughly 150 product engineers were moved onto security, reliability and privacy work.

None of that is directly usable by a reader outside the industry. It is worth noting for one reason: it is the kind of detail that makes a company look worse in the short term, and organisations generally do not publish it unless somebody has decided that disclosure norms matter more than the week’s coverage.

Read it as what it is

This is Anthropic reporting on Anthropic. The account of the incidents, the diagnosis and the remedies all come from the company that had the incidents. There is no independent investigation here, and the post should be attributed that way in any conversation where it carries weight.

Anthropic also credits an earlier disclosure by OpenAI with prompting the investigation that found the July problem. That detail matters more than it looks, because it is the argument for publishing these things at all: one company’s account let another company find its own fault.

The four commitments stand on their own merits regardless. They are good practice whoever wrote them, and they are the part you can take away and use.

The version to take into your next vendor call

You are not running cyber evaluations. You may well be about to let an AI tool read your files, send things on your behalf, or act inside a system that matters.

Ask the four questions. Write down the answers. If the supplier cannot tell you where the boundary is, the honest position is that there is not one yet, and the configuration is doing all the work.

Want this applied to your own work?

A discovery call is a short, no-obligation conversation about where AI fits in your team, and where it does not.