Over the past few weeks, several separate incidents have surfaced in which a frontier AI model, operating with some degree of autonomy, broke through the boundaries it was meant to stay within and took actions against real systems. Crucially, no one had specifically authorized those actions. We think these incidents, as reported by Hugging Face/OpenAI, Anthropic and the UK AI Security Institute (UK AISI), warrant sustained attention from policymakers, AI developers and deployers, and potentially the internet ecosystem as a whole.Â
Our analysis is based on IST’s AI Loss of Control Risk Indications & Warning (I&W) methodology. Given the concerning convergence of behaviors, including unauthorized resource acquisition, deception, manipulation, goal misgeneralization, and scheming, we assess that these incidents map to Level 2 on IST’s Loss of Control (LOC) Risk Schema. We also pose critical questions about these incidents for consideration by policymakers, developers and deployers, and the general public to help shed light on the level of detail needed for clearer assessment.Â
 Our framework distinguishes between theoretical LOC indicators and indications. Indicators are behaviours such as unauthorized resource acquisition, scheming, manipulation, goal misgeneralization, self-preserving behaviour, model behaviour drift, or deception that would be concerning if observed, while indications are documented evidence that these patterns are occurring in practice. It also presents five warning levels, ranging from Level 0 (normal operation of AI systems) to Level 5 (fundamental compromise of control mechanisms). IST has been examining LOC risk for some time. In April and June 2025, we ran tabletop exercises (TTXs) built around a time-sensitive Loss of Control scenario at a frontier AI lab, which showed that existing monitoring and response mechanisms lag well behind the actual capabilities of current and near-future models.
Indication 1: OpenAI models inside Hugging Face’s infrastructure
On July 16, Hugging Face disclosed that it had detected and contained an autonomous AI agent inside its infrastructure. The company noted that this incident differed from previous ones in that it was driven end-to-end by an autonomous agent, and that detection relied substantially on Hugging Face’s own AI-based defenses. A joint disclosure with OpenAI on July 21 attributed the intrusion to GPT-5.6 Sol and an unreleased frontier model.
Hugging Face’s forensic timeline, published July 27, reconstructs roughly 17,600 autonomous actions over four and a half days, including a command-and-control channel the agent improvised from pastebins and file-drop services to maintain state across ephemeral sessions. The models chained several vulnerabilities together, identified a zero-day exploit, escalated privileges, and broke out of an isolated testing environment into Hugging Face’s production database.
OpenAI’s own July 20 disclosure noted that the underlying sandbox vulnerability was not new, and that earlier models had encountered the same obstacle and abandoned the attempt. A related internal case is illustrative: an OpenAI internal long-horizon model spent roughly an hour finding a sandbox vulnerability specifically in order to open a public GitHub pull request, in violation of an explicit instruction to post results only to Slack.Â
The disclosures prompted responses from across civil society and government. Advocacy coalitions have written to the White House and to Congress asking for a federal investigation. The House Committee on Homeland Security Subcommittee on Cybersecurity and Infrastructure Protection has requested a briefing from OpenAI, and a group of state attorneys general has instructed OpenAI to preserve records. In response, OpenAI has engaged METR (Model Evaluation and Threat Research) and Redwood Research for a third-party assessment of the model behavior. However, METR’s review will be brief and cover a specific set of questions, not a comprehensive, root-cause investigation—a distinction that METR has been explicit in articulating.Â
Mapping to AI Loss of Control Risk Indicators Framework
The agent had no legitimate basis for reaching the open internet from a sandboxed research environment, let alone Hugging Face’s production servers; this is a clear instance of unauthorized resource acquisition. Another indicator observed in this case is goal misgeneralization. OpenAI’s own account of the incident describes a model that devoted substantial inference compute to a narrow objective: solving an internal challenge referred to as ExploitGym. The model, which was described as “hyperfocused,” chained together multiple attack vectors, including stolen credentials, to fulfill the task it was given.
Indication 2: Claude reaching production infrastructure during evaluations
Nine days after the Hugging Face disclosure, Anthropic reviewed 141,006 of its own evaluation runs and identified three incidents in which Claude reached the open internet from a third-party evaluation partner’s environment and gained unauthorized access to the production infrastructure of three separate organizations.Â
Even though the initial prompts had told Claude it was operating in a simulated environment with no internet access, their review found that a misconfiguration had left live internet access in place within the evaluation environment. Anthropic has described these incidents as a misunderstanding between the internal company and its external evaluation partners. Across the three incidents, six runs were affected, spanning three different models — Claude Opus 4.7, Mythos 5, and an internal research model — with the earliest dating to April. In one case, Claude Mythos 5 was tasked with solving a capture-the-flag exercise. Over the course of attempting it, the model found setup instructions telling developers to install a Python package that did not exist. The package was live for roughly an hour. It ran on fifteen real systems belonging to people with no connection to the evaluation.
To complete the task, Claude required a PyPI account, which required an email address, which in turn required a phone number. It attempted and failed to obtain funds to pay for one, then located a free email provider and completed the registration by other means. Notably, Claude’s own reasoning had already identified that this action, on the real internet, would constitute an actual attack and was “not okay, and surely not the intended solution,” before concluding that the environment was staged and proceeding regardless.
Mapping to AI Loss of Control Risk Indicators Framework
According to Anthropic, Claude behaved according to general instructions issued for the capture-the-flag training: locate a path to the flag. Because the prompt stated there was no internet access and set no access boundaries, Claude treated the real systems it encountered as part of the exercise. This constitutes a clear case of unauthorized resource acquisition, and reflects the same underlying dynamic observed in the OpenAI case: a model pursuing a goal past the point at which its own reasoning had flagged a problem.
Indication 3: OpenAI and Anthropic agents’ unsanctioned behavior during cyber testingÂ
On August 4, the UK AI Security Institute published an incident report documenting unsanctioned agent behavior observed during its own cyber testing. Of the unsanctioned actions recorded, a Claude Mythos 5 agent accounted for 15 of 17 and GPT-5.6 Sol accounted for the remaining two. Importantly, during testing, internet access was permitted, and model-provider cyber classifiers, mechanisms to prevent misuse, were deliberately disabled.Â
While our analysis does not cover all events described in UK AISI’s detailed report, according to the Institute, the most serious case involved an agent that attempted to insert malicious code into an open-source project. Attempting to get the malicious code approved, it engaged in social engineering, creating fake online identities and using them to pressure the project’s maintainer. A human maintainer identified the attempt and declined to approve the code.Â
Mapping to AI Loss of Control Risk Indicators Framework
The specific case described above maps to unauthorized resource acquisition, deception, and manipulation. UK AISI reports no evidence of resulting harm but frames the finding as notable in its own right, describing it as the first instance in which risks associated with autonomy and deception have appeared clearly in a real-world setting without specific prompting.
An overview of the AI Loss of Control Risk Schema, as described in the February 2026 report, “AI Loss of Control: Indications & Warning.” For a more detailed version of this schema, see page 28.Â
Recent indications map to Level 2 on IST’s Loss of Control Risk SchemaÂ
In all of these cases, agents appear to have been driven by a specific focus on completing the task at hand (or appearing to complete it), rather than in pursuit of any broader goal. Task difficulty seems to be a contributing factor. All of the incidents share the same three enabling conditions: some safety classifiers were disabled, there was no real-time or synchronous monitoring, and some pathway to internet access existed.
In our view, of all the indications described in this analysis, the case reported by UK AISI, in which multiple indicators converge, is the most concerning. The incident pairs social engineering, a method that has been historically effective in manipulating humans, with AI-enabled tradecraft.
As indicated in the Loss of Control Risk Schema, incidents reach Level 2 when they move from the test environment to the production environment, and when they demonstrate multiple indications of Loss of Control that converge on the same indicator. In the incidents we analyzed, they manifested in deployment, not just in testing (even though agents were promoted during testing), and converged on the same indicator: unauthorized resource acquisition. These incidents, which map to Level 2 on the Loss of Control Risk Schema, should prompt policymakers, the developers and deployers of these systems, and arguably the broader internet ecosystem to pay attention, ask questions, and find ways to bring clarity to the situation. The latter is especially important, since analysis of these incidents to date has been either very alarmist or have significantly downgraded the severity of the issue. To help with gaining this clarity, ensuring evaluations run safely, and supporting overall situational awareness, the following open questions are worth consideration:
- Who else was affected? The full scope of organizations affected, beyond those already disclosed, remains unclear. Hugging Face was a unique target. The fact that it is an AI company that uses AI for defense potentially made the detection process easier. Beyond this case, cybersecurity measures remain far from perfect and similar intrusions at other organizations with fewer defenses could easily have caused greater damage.Â
- How do we improve monitoring of AI agents? These incidents clearly demonstrate that implementing continuous monitoring and persistent telemetry of the agents will be crucial for avoiding similar incidents in the future.Â
- What did the evaluation prompts actually say? More visibility into the prompts themselves would help distinguish actual model behavior from poorly-specified constraints imposed by humans.
- What is the exact nature of agents collaborating with other agents in these incidents? The UK AISI report described “unexpected collaboration between the agents.” On August 5, OpenAI revealed another important detail about the Hugging Face incident, stating that their agents collaborated while planning the hack in early May. If such collaboration occurred in other incidents, it is important for the public and policymakers to gain additional insight into what happened.
- What should standard disclosure forms look like? Each incident saw a different level of detail in the disclosures. For example, the UK AISI disclosure was the most comprehensive report of the incidents in both form and rigor.Â
- Does convergence across labs indicate that a shared capability threshold has been crossed? All of the incidents described in this analysis cluster across two frontier labs. Is this a coincidence, or some kind of shared capability inflection point?
This commentary is written and published in accordance with IST’s Intellectual Independence Policy. The authors are solely responsible for its analysis and recommendations. The Institute for Security and Technology and its supporters do not determine, nor do they necessarily endorse or advocate for, any of this blog’s conclusions.

