*You can access the full technical report *here.
AISI’s role is to evaluate and understand the capabilities of frontier AI models, surfacing potential risks before they reach the public. To assess what these models can do, including whether they could be misused for cyberattacks, we test them under deliberately permissive conditions: with access to the open internet, and with some safety filters disabled.
On 28th July 2026, AISI's Security Team detected unusual data transfers leaving our research systems during a routine cyber evaluation. On investigation, we found that some of the agents being tested had engaged in sustained, potentially harmful activity directed at real people and organisations. We declared a security incident and, within roughly one hour of discovery, had contained it and begun a full investigation.
The incident stemmed from a single evaluation where agents were given a task of solving a cyber security challenge. We ran this challenge 122 times across several models. Our investigation found that in 10 of those runs, an AI agent took autonomous, unsanctioned action on the live internet, targeting real people and organisations. In total, we catalogued 19 such actions. Almost all of this behaviour (17 actions) came from a single model, Anthropic's Mythos 5, with 2 actions involving OpenAI's GPT-5.6-Sol with cyber classifiers (mechanisms to prevent misuse) disabled. In the most serious case, an agent tried to insert malicious code into an open-source project. In an attempt to get the code approved, the agent engaged in social engineering — creating fake online identities and using them to pressure the project's maintainer to approve the code. A human maintainer caught and refused to approve the malicious code.
These attempts were unsuccessful, and our investigations have not evidenced any resulting real-world harm. But this is the first time we have seen risks around autonomy and deception manifest this clearly, without specific prompting, in the real-world.
Importantly, this was not a case of a model escaping its secure test environment, or ‘sandbox’. As was standard in our cyber testing, we had intentionally permitted internet access, and model-provider cyber classifiers were deliberately disabled - conditions that do not reflect how frontier models are made available to the public. We do this to best assess the maximum capability of models. These configuration choices have been common practice in frontier AI evaluations. The specific models in question, in the configurations in which we tested them in questions are not commercially available and there is no clear indication of similar activity outside of testing scenarios.
Ahead of publishing this blog, we notified GitHub (the developer platform accessed during the evaluation) of the agents' malicious activity, which included actions that GitHub has confirmed violated their terms of service. We worked together with GitHub to remove artefacts left behind by the agent, and to notify the GitHub users the model interacted with. We have also contacted other affected parties. We also intend to work with METR (Model Evaluation and Threat Research) to conduct an independent third-party review – we are still working through the scope of this review with them.
This incident should be interpreted with caution and nuance. To some degree, our evaluation design choices and specific configurations enabled the behaviour. Nonetheless, the activity undertaken by the agent show signs of novel, potentially deceptive behaviours, and were to an extent and severity we did not anticipate.
There are important caveats to bear in mind: we observed a small number of events under very specific conditions, and cannot yet say how likely such behaviour is in different contexts or outside of testing environments. We cannot yet be certain when the agent understood it was taking real world action, or to what extent it believed it was in a fictional test scenario; our analysis so far presents a mixed picture and is ongoing.
What we can say is that the behaviour was possible, sustained, and new; that alone warrants attention.
This is precisely the kind of behaviour AISI exists to uncover, surfacing it in a controlled evaluation, so it can be understood and addressed before more capable models are widely deployed. This post sets out what happened, why it matters, and what we are doing in response. Our accompanying technical incident report provides further detail, and we intend to share more as our investigation continues.
What happened
AISI regularly tests the cyber capabilities of frontier models using cyber ranges: controlled, simulated networks that mimic real-world systems. An AI agent is given a cybersecurity challenge to solve, such as finding a protected piece of data, and works autonomously over many steps to complete it.
This exercise compared an existing cyber range against a new range, testing seven different models on the two ranges over 122 runs in total. All runs were conducted in AISI’s research environment, using virtual machine sandboxing to isolate the agents from other AISI infrastructure. Two features of the evaluation’s set-up are central to what followed:
Internet access was deliberately enabled. To measure what these models can genuinely do, we test them under conditions that reflect what a capable human attacker could do, including access to the open internet.
The developers' cyber classifiers were deliberately switched off. Frontier models are usually deployed with built-in filters that block dangerous behaviour. As a trusted testing partner, AISI can disable these filters to elicit a model's underlying capabilities.
This combination of conditions is not reflective of how frontier models are made available to the general public.
How we discovered the incident
On the morning of 28th July, our security monitoring flagged data leaving one of our testing systems through the ‘Tor’ anonymity network, which is commonly used to disguise the origin of internet traffic. The team running the evaluation began reviewing the agent's activity within minutes.
They quickly found that, during one run, the agent had created a malicious ‘pull request’ (a proposed code change) on a real, public open-source project on GitHub. We declared a security incident, stopped all related evaluations, and disabled internal access to the most capable models. All evaluation runs were terminated, and relevant machines isolated, within one hour of the alert being raised. Over the following hours and days, we reviewed the full set of runs, combining automated transcript scanning with expert manual analysis, to establish what had happened, and whether anything similar had occurred elsewhere.
What we found
43 of the 122 runs involved Mythos 5, and 35 of the 122 runs involved GPT-5.6 Sol. The overwhelming majority of the 122 runs proceeded as intended. However, in 10 of the 122 runs, we identified 19 cases where an agent had taken distinct actions beyond the scope of the testing parameters. 17 of these cases came from Mythos 5, and 2 came from a single run involving GPT-5.6 Sol.
The 19 cases were not separate incidents; they clustered into a few connected behaviours. They primarily arose from a single sustained line of activity by one agent (Mythos 5), with a handful of related actions elsewhere. This behaviour occurred between July 25th and July 28th 2026.
Below, we highlight the four most significant behaviours observed. A full summary of cases is available in our technical incident report.
1. An attempted supply-chain attack on real open-source software. In the most serious sequence, an agent tried to insert malicious code into a publicly used open-source project and took actions in an attempt to secure approval for this insertion by human reviewers. The agent researched the project's human maintainers, created multiple fake identities, and used the fake identities to socially engineer a real maintainer into approving the code. When the agent’s pull request was challenged in public, it edited its earlier activity to appear harmless and considered adopting a fresh identity to continue. The agent used Tor to bypass some network restrictions on GitHub, which is what first triggered AISI’s security alert.
2. Attempts to deceive and target real people. As part of the same effort, the agent tried to contact real people directly, sending messages and files through an online file-transfer service to persuade them, or their own AI coding tools, to run malicious code. Some messages carried harmful payloads, and some were attempts at social engineering; targeted at real people – something we’ve never previously observed.
3. Attempts to plant and prompt-inject malicious code. The agent tried to insert malicious instructions where it reasoned that other automated AI systems might pick them up and execute them. Prompt-injections are hidden instructions designed to manipulate AI coding assistants.
4. Collaboration between independent agents being assessed simultaneously. One agent left public messages on GitHub offering collaboration with other agents working on the same challenge. It also provided instructions to reuse accounts and artefacts it had left behind, which were discovered and used by subsequent agents.
We assessed each event for its potential to cause real-world harm. The most serious attempts were unsuccessful. Some actions had a limited real-world effect, but in contained circumstances; we set these out in the accompanying technical report. Our investigation has not identified any resulting real-world harm.
Why this happened
Fundamentally, the agent took these actions to complete the task it had been set – to solve the cyber range. Several factors contributed to the emergence of unsanctioned behaviours:
The agent pursued its goal persistently. AI agentsexplore routestheir operators did not intend. Given a difficult objective, the agent kept searching for a way through, and some of the routes it found involved trying to deceive real people. It was never instructed to deceive; deception emerged as a by-product of pursuing the task, the kind of goal-directed deception that, until recently, had been largely theoretical.
The task was hard, and misconfigurations sometimes made it harder. In a number of runs, the task prompt was misconfigured so that the agent (incorrectly) believed no 'solve' existed that didn't require it to go beyond the intended task scope**.** There is good reason to think near-impossible tasks push models towards more ‘creative’, and more transgressive, problem-solving. But this does not fully explain the behaviours: in some runs the agent acted this way even when it had the necessary instructions to solve the task as intended.
Internet access was open, and monitoring was not purpose-built. We deliberately granted internet access to allow the agent to download tools required for its task; what we did not anticipate was that this would lead the agent to use this internet access to direct action at real people. In earlier model generations, this risk trade-off was judged to be acceptable, but we did not revisit that judgment quickly enough as capabilities advanced. Our security team detected the anomalous traffic through general monitoring after the fact, not through monitoring built to watch the evaluation as it ran, which could have flagged or blocked the behaviour sooner.
The agent was not specifically instructed not to leverage open internet access or avoid social engineering elements. Previously, it was not clear that such instructions were necessary when using models with alignment training.
The factors that limited the damage also provide valuable insight. Human review and good security practice played an important role. In one instance, an agent's malicious pull request was caught by a human reviewer. The agent’s attempt to conduct social engineering by creating fake accounts to encourage the reviewer to approve this request failed. A member of the public, who suspected the code was malicious, opened it inside a secure, isolated environment built to contain such code.
Additionally, the agent did not directly escape the secure test environment (‘sandbox’) that keeps the test environment sealed off from AISI's other internal systems. Agents often explore such an environment to understand what they can access, but here no agents tried to break out of it, or attack AISI’s systems.
In these cases, standard good practice, human judgment, and caution around AI-generated code stopped the worst outcomes. But in several cases the margin between failure and success was narrow, resting on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.
**Lessons for the future **
We are treating this as a serious incident, warranting lasting change for AISI’s evaluation protocols and security architecture. Three lessons stand out for AISI and other evaluators:
Tighter controls on internet access. We are building fine-grained network controls into our cyber ranges, with the aim to preserve the realism these evaluations need while constraining them appropriately. We already use fine-grained network controls in all other evaluations, and will now treat the decision to grant internet access as one that must be actively justified rather than a default.
Real-time monitoring. We are introducing monitoring built to watch an evaluation as it runs, able to flag or block out-of-scope actions as they happen.
Reassessing evaluation design. Evaluations should assume a capable model may try to act beyond its remit, with the scope of any such behaviour limited in advance. AISI’s sandboxing guidelines recommend tailoring the sandbox configuration based on the design of the evaluation;good containment should not depend on the model choosing not to test its boundaries. We are also adding additional checks to ensure tasks are correctly specified and solvable by the intended route.
Alongside these changes, we are analysing what happened from both a cybersecurity and an AI alignment perspective, as well as auditing past evaluations for comparable behaviour that may have gone unnoticed.
We are also disclosing this openly so others can learn from our experience and continue to work closely with Anthropic and OpenAI to investigate this incident further.
What this means for people and businesses
This incident occurred in a controlled evaluation, not in ordinary use, and there is no clear indication of similar activity outside of testing scenarios. It is, however, a reason to prepare. As AI models become more capable and accessible, what we have seen during this incident could become more common.
The most effective response remains standard cyber hygiene, which matters more as AI advances. Organisations should ensure the cyber security basics are implemented robustly and be cautious when verifying outside code and contributions. This is an area where the leaders of the Five Eyes cyber security agencies have jointly called for action, and the National Cyber Security Centre has issued guidance on how to prepare as frontier AI’s cyber capabilities evolve. We encourage organisations of all kinds to sign up to the NCSC’s free Early Warning service, to make cyber a board-level responsibility, and to require Cyber Essentials right across their supply chains.
Final reflections
Incidents of this kind reflect the speed at which AI is developing. As capabilities advance, the work of understanding these systems, and ensuring their safety, must keep pace alongside them.
AISI is a capable organisation with strong safety practices, and we identified this behaviour through our own procedures. But no organisation's defences remain sufficient indefinitely. In this case, we deliberately enabled internet access, and did not have active monitoring that would have surfaced the behaviour sooner – things we will directly address moving forward. We are being open about these lessons so others can learn and adjust.
Taken alongside recent incidents reported by OpenAI and Anthropic, this incident points to a shift in the risk landscape. Harm may arise not only when people deliberately misuse publicly available models, but when capable agents operating in an internal research or privileged-access setting take unintended action beyond their authorised scope.
We have outlined important caveats that contextualise this incident. These behaviours emerged during an evaluation in which an agent was trying to complete a task. We cannot currently be certain when exactly the agent thought it was in a test, or how aware of potential real-world implications of its actions it was. In any case, this incident indicates a direction of travel that warrants immediate attention.
AISI exists to identify these problems, understand them, and share what we learn so they can be addressed before more capable systems are deployed – internally in AI labs, to trusted partners, and also to the public. The work is not complete, but it is shared across government, industry and the research community. The task now is to strengthen our defences, and ensure that safety work keeps pace.
You can read our technical incident report here.