Anthropic Says Claude Breached 3 Firms in Testing
Anthropic disclosed that three Claude models reached real systems during cyber evaluations. What happened, what it says went wrong, and the lesson for anyone running agents.
Anthropic disclosed on July 30, 2026 that three of its Claude models gained unauthorized access to the systems of three outside organizations during security evaluations that were supposed to stay inside a test environment. The company said it reviewed 141,006 evaluation runs going back to April 2026 to find them, and has stopped its cyber evaluations while the incidents are reviewed. The disclosure was covered by CBS News, TechCrunch and Nextgov.
The models involved were Claude Opus 4.7, Claude Mythos 5, and an internal research prototype. The three affected organizations have not been named.
What happened in each case
All three occurred during capture the flag exercises, a standard security testing format where a model is told to break into a machine and retrieve a piece of secret information hidden elsewhere on the network. The point of the exercise is to measure offensive capability in a sealed environment.
Opus 4.7 discovered it had internet access from inside the test environment and carried out its task against real company networks.
Mythos 5 created login credentials and installed a Python package from a public registry as part of its attempt. The package reached the public internet, and 15 systems downloaded and ran it.
The prototype model failed to find the fictional target it had been given, and scanned real targets instead.
Reporting notes the techniques were unremarkable: weak passwords and access points that required no authentication. This was not a model defeating serious defences. It was a model doing ordinary things to machines that happened to be reachable.
What Anthropic says went wrong
The stated cause is a misunderstanding between Anthropic and a third party evaluation partner, Irregular, about whether the test environment had internet access. It did. The models then operated on the assumption that everything they could reach was part of the exercise.
Anthropic has said it contacted or attempted to contact all three organizations, and that it is working with Irregular, the independent evaluation organization METR, and the affected companies on reviews.
That framing matters for reading the story accurately. The company characterised this as a failure of the evaluation infrastructure rather than as models deciding to escape their environment. The models were doing what the exercise asked. The boundary they were meant to stay inside was not actually there.
Why this is relevant if you run agents
Most people reading this are not running offensive security evaluations. The transferable lesson is not about capability, it is about scoping, and it applies at every scale.
An agent acts on the environment it can reach, not the environment you pictured when you set it up. Every one of these incidents came from a gap between those two things. Nobody intended the test network to have a route to the open internet, and the models had no way to know the difference between a machine they were meant to touch and one they were not.
This is the same class of problem as an agent with database credentials that turn out to be broader than intended, or a coding agent given a token that reaches production as well as staging. The model does not know which permissions were deliberate. It sees capability and a task. This is also why the permission checkpoint sits in the host application rather than in the protocol when tools are connected, a division we described in how the Model Context Protocol works.
What to actually do
Scope credentials to the job. An agent that only needs to read should not hold a key that can write, and a key that reaches production should not be in a testing environment at all.
Assume network access exists until you have verified it does not. That verification is the exact step that failed here, at a company with strong reason to get it right.
Log what the agent did, not just what it produced. All three of these were found by reviewing runs after the fact, which was only possible because the runs were recorded.
Keep a human approval step on anything that writes, deletes, sends or installs. Read only autonomy is a much smaller bet.
Re-check the boundary after any change to the environment. Access that appears later is invisible unless someone looks again.
None of that is exotic. It is the same discipline you would apply to a new contractor with a laptop, applied to something faster that does not pause to wonder whether it should.
The wider context
Disclosures like this arrive as regulators are getting more concrete about obligations on model providers, with a set of EU rules taking effect this month that we covered in what changes under the EU AI Act in August 2026.
For people building ordinary software, the practical takeaway is narrow and useful. Agents are genuinely capable of acting on real systems, which is what makes them useful, and that same property is why the boundary you draw around them is the security control that matters most. If the distinction between an assistant that suggests and a system that acts is still fuzzy, we set it out in what an AI coding agent actually is, and the access questions that come with building on this stack run through our guide to building an app with AI.
For the operational question this raises for anyone running agents against real systems, see how to set spending limits for AI agents, which covers a related class of containment failure.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
