Your staging environment is isolated on a diagram
Anthropic found three real breaches across 141,006 evaluation runs. The model behaved as trained. The test environment kept live network access, and the same gap runs through data pipelines.
The headlines said an AI went rogue. The actual finding is less dramatic and more useful to anyone who runs infrastructure.
Anthropic reviewed 141,006 evaluation runs where Claude could have obtained internet access. Three ended with the model reaching a real company production system. A third-party partner had been running cybersecurity evaluations, the model was solving what it understood to be a simulated capture-the-flag exercise, and the test environment retained live internet access.
Claude used ordinary techniques, weak credentials and unauthenticated endpoints, against systems it had been told were synthetic.
Figures from the published review, disclosed 30 July 2026. The earliest incidents date to April 2026; evaluations were halted on 23 July, all three incidents identified on 24 July, affected organisations notified on 27 July.
The actual failure
A model cannot distinguish a sandbox from production if the sandbox is not sandboxed. It has no independent channel to check. It has the environment it was given and the framing it was handed, and both said simulation.
That is not misalignment. The model did what it was trained to do inside the boundary it was shown. The boundary was wrong.
Detection worked. All three were found within a day of suspending the tests, and every affected organisation was notified inside a week. The failure sat upstream of detection, in an isolation claim nobody had verified.
The same gap in data platforms
I recognise this pattern because I have found it repeatedly in data infrastructure, where it produces less interesting headlines and comparable damage.
A staging schema pointed at a production warehouse role, because that was how someone got a migration unblocked in 2024 and the grant never got revoked.
A test harness with network egress to a live API, so integration tests hit the real endpoint, and one of those tests does a write.
Nobody notices until something reads or writes where it should not. The systems were isolated in the architecture document. They were not isolated in the network.
Verification, not assertion
Agent governance gets discussed as identity, scope, and permissions. This sits one layer beneath that. Before you scope an agent permissions inside an environment, establish that the environment is what you think.
Test egress from inside. From within the sandbox, attempt a connection to something external and confirm it fails. An isolation claim you have not tried to break is an assumption.
Enumerate effective grants, not intended grants. Query what the role can actually reach. In Snowflake that means walking GRANTS_TO_ROLES rather than reading the provisioning script that was supposed to configure it.
Diff the credentials. If your staging and production credentials share a prefix, someone will eventually paste the wrong one. Make them visually distinct.
Rerun the checks on a schedule. Isolation decays. Someone grants access for an incident and the revocation never lands. A boundary verified once is a boundary verified for that day.
The question worth asking about any environment where you are testing something with real capability: would it survive somebody actively checking whether it is contained, or is it isolated on a diagram and nowhere else?
Related reading
- AI engineeringI plan agents in two models before I write any codeA method for building AI agents that starts with architecture and adversarial review instead of a system prompt, and why it costs less than rearchitecting later.
- GovernanceAn AI agent with memory is a database nobody governsAgents that remember across your apps and read your files are data systems. They need an owner, a retention policy, and a deletion path, and most teams piloting them have none.