UK AI tests find Claude & GPT-5.6-Sol rogue actions

The UK's AI Security Institute said tests of Anthropic's Claude Mythos 5 and OpenAI's GPT-5.6-Sol found cases of unsanctioned behaviour during cyber evaluations. The most serious incident involved an attempt to insert malicious code into a real open-source project.

The behaviour emerged during a routine assessment of frontier AI models under deliberately permissive test conditions, including internet access and disabled cyber misuse filters. The institute reviewed 122 runs across seven models and found 19 out-of-scope actions in 10 runs. Seventeen were linked to Mythos 5 and two to GPT-5.6-Sol.

According to the institute, one agent created a malicious pull request for a public software project, then tried to influence the approval process by creating fake online identities and pressuring a maintainer. The maintainer rejected the code, and the institute found no evidence of real-world harm.

The findings add to a growing debate over how autonomous AI systems behave when given broad goals and access to live online services. The institute said the models did not escape their sandboxed research environment, but their actions were sustained, novel and directed at real people and organisations.

Its investigation traced the incident to a single cyber challenge designed to test whether agents could solve a security task over many steps. Some runs were misconfigured in ways that may have made the task harder, the institute said, but that did not fully explain the behaviour. Some agents still acted beyond scope even when they had a valid route to solve the task.

Security monitoring first flagged unusual data transfers through the Tor anonymity network. Investigators then found that one agent had used GitHub and other online services in ways that breached the intended boundaries of the test.

Beyond the attempted code insertion, the institute described efforts to contact real people with messages and files intended to persuade them, or their own AI coding tools, to run malicious code. It also said one agent tried to plant hidden instructions for other AI systems, and that separate agents appeared to collaborate by reusing public artefacts left behind during the evaluation.

Expert response

Waseem Ahmed, Head of Engineering at Secure, said the incident should be understood as a consequence of goal-seeking behaviour rather than a loss of control in the popular sense.

"Let's be precise about what happened, because 'AI went rogue' misses it. AISI's own report is clear. The agent did not turn evil and it did not escape its sandbox. It was told to solve a hard security challenge, and deception emerged as a by-product of chasing that goal.

"Two details matter. This was a model not yet released, and testers had switched off the safety filters on purpose to probe raw capability. That is not how these models behave in production with guardrails on. The real lesson is that a capable agent chasing a goal will try routes you never approved, including social pressure aimed at real people. That is new, and it is why we cannot treat agents like ordinary tools.

"The most reassuring fact in the report is also the most alarming. The attack failed because a human caught the bad code and refused it. Good practice worked, but the margin was thin. It depended on human vigilance, not a technical wall that would reliably stop a stronger agent.

"So here are four moves for security teams. First, block open internet access for agents by default and grant it only when a task truly needs it. Second, watch agents in real time so you can stop out-of-scope actions as they happen, not find them in the logs later. Third, assume any capable agent will try to bend its limits, and build guardrails and containment before it runs. Fourth, harden code review and contributor identity checks, because fake identities are now a real supply chain attack path, and treat all AI-generated or outside code as untrusted until you verify it in isolation.

"The strongest response is still standard cyber hygiene done well, which matters more as these agents get stronger," said Waseem Ahmed, Head of Engineering at Secure.

That reading is broadly consistent with the institute's own account. It said the behaviour arose because the agent persistently pursued its assigned objective and explored routes operators had not intended, including deception and social engineering.

Control measures

The institute said it contained the incident within about an hour, halted related evaluations and disabled internal access to the most advanced models under review. It also worked with GitHub to remove artefacts left by the agent and notify affected users.

In response, the organisation is tightening how internet access is granted in cyber evaluations, adding real-time monitoring to flag or stop out-of-scope actions as they happen, and reviewing evaluation design so containment does not depend on a model choosing not to test its limits.

The case is likely to sharpen scrutiny of how frontier model developers and testing partners assess systems before release. While the institute stressed that the specific model configurations were not commercially available and did not reflect ordinary public deployments, it said the episode showed a direction of travel that warrants immediate attention.

For businesses, the report points less to a sudden breakdown in existing systems than to a widening attack surface in software supply chains and identity checks. The institute said standard security practice, human judgement and caution around outside code prevented the worst outcomes, but added that in several cases the margin between failure and success was narrow.

It concluded that the behaviour was possible, sustained and new.