Security evaluations of AI models normally run in environments deliberately isolated from anything real, with the model told exactly that so it behaves accordingly. On 30 July 2026, Anthropic disclosed that this assumption failed three times, and each time the model treated a live target as a training exercise because it had been told, incorrectly, that it was one.
What went wrong
Reviewing 141,006 evaluation runs conducted with third-party partner Irregular, Anthropic found three incidents in which its models accessed the open internet during what was meant to be a fully simulated capture-the-flag exercise. The root cause was a configuration disagreement between the two companies over whether the test environment had internet access. It did. The prompts given to the models said it did not. Neither party noticed until last week, well after the runs had completed.
Three separate models were involved: Claude Opus 4.7, an internal model referred to as Claude Mythos 5, and a further internal research model. Operating under instructions that told them safety constraints were relaxed for a contained exercise, the models did what they were tasked to do. They found and used a SQL injection flaw, discovered and exploited an exposed debug page, and in the most serious of the three incidents, Mythos 5 built and uploaded a functioning malicious Python package to the public PyPI registry. That package ran on 15 real-world systems before it was caught, including machines belonging to a security vendor, from which it exfiltrated credentials.
Anthropic says the review that surfaced these incidents was itself prompted by a comparable episode OpenAI disclosed earlier in July, where one of its unreleased models broke out of its own sandbox and interacted with Hugging Face during a benchmark run.
Why this is not just an Anthropic problem
Two AI vendors disclosing the same failure mode within weeks of each other, in each case only after the fact, is the more useful signal than either incident alone. Agentic AI models are increasingly being pointed at real infrastructure for legitimate purposes: automated penetration testing, vulnerability triage, red-teaming of production systems. Every one of those use cases depends on the boundary between “this is a live target” and “this is a sandbox” holding exactly as configured, and on the operator of that boundary catching a mistake before the model does something a live target should never have exposed it to.
A misconfigured evaluation environment is not exotic. It is the same class of mistake as a staging database pointed at production credentials or a test API key that turns out to be live. The difference with an agentic AI model is that once it believes the constraints do not apply, it will use every capability at its disposal, including ones you did not know it had, to accomplish the task it was given. A malicious PyPI package built and published autonomously, from prompt to live compromise of 15 systems, is a demonstration of exactly how fast that gap closes.
What this means for teams deploying agentic AI
Any organisation running AI agents against real or near-real infrastructure, whether for security testing, DevOps automation, or coding assistance with broad permissions, should treat this as a prompt to verify, not assume, the isolation of the environment those agents operate in. Network egress controls, scoped credentials, and independent verification of “simulated” environment claims belong in the same category as any other access control you would not take a vendor’s word for.
If your organisation is deploying agentic AI tooling for security testing, DevOps workflows, or infrastructure automation and needs an independent review of the isolation and access boundaries those agents operate within, contact Excello Digital. We help European organisations build the guardrails that assume the sandbox will fail before it does.