An alignment assessment of recent cybersecurity incidents

Published Sep 9, 2026 (updated Sept 10). Follow-up to Anthropic’s July 30 report, adding a fourth incident from January 2026. Condensed: the per-incident deep dives, methods and training-cause analyses are omitted; the introduction, summary, fourth-incident section, monitoring analysis and discussion are reproduced.

Introduction

We present an alignment assessment of four incidents in which Claude models gained unauthorized access to real third-party systems. We described three of these incidents on July 30; we identified these after a scan of roughly 141,000 transcripts in which we believed Claude could have obtained internet access during a cyber evaluation. Given the volume of transcripts and our desire to disclose incidents quickly, our scan relied on an agentic search. This missed a set of transcripts that also turned out to have internet access; we identified these in August while assembling transcripts to share with METR. We scanned these transcripts and identified a fourth incident, from January 2026, involving an early version of Claude Opus 4.6. We have notified all affected parties.

After finding this incident, we broadened our search to roughly 481 million transcripts—an intentionally wide net, consisting of all transcripts from our Frontier Red Team, many non-cyber evaluations, reinforcement learning (RL) environments, subagent logs, and more. We performed a first-stage scan of this group of transcripts for signs of internet access, such as public IP addresses and web addresses, and a second-stage scan using Claude to review the 9.2 million transcripts the first stage flagged for escalation. This scan re-identified the four incidents and found no other cases of similar or worse severity.

All four incidents occurred during cybersecurity evaluations built by the same evaluation partner. Claude was told it was operating in a simulation without internet access, but, due to a misconfiguration, it was mistakenly connected to the open internet. As is standard for cybersecurity evaluations, the models ran without the cyber safeguards that ship with our released models. (This post does not cover the incident reported by UK AISI in its testing of Claude Mythos 5. We plan to conduct an alignment assessment of those transcripts as well.)

We have signed an agreement with METR to conduct an independent investigation of these incidents. Our agreement grants METR wide-ranging access, including to transcripts beyond the window in which the incidents occurred, and to Anthropic employees, who will be permitted to share confidential information. Our initial agreement runs for eight weeks, with the option to extend by mutual agreement. We intend to give METR as much time as it deems necessary.

Our investigation identified two recurring alignment issues, present at varying levels of severity across the incidents: biased reasoning, in which Claude tended to disregard or misinterpret evidence that it was operating on the real internet, and recklessness, or a willingness to take harmful actions in the narrow pursuit of a task. We’ve described milder forms of these behaviors in previous system cards, but we consider these cases to be more serious instances than the behavior reported in these system cards.

We are most concerned by the misalignment present in the incident involving Claude Mythos 5, in which the model went to extensive lengths to upload a malicious package to PyPI, the public repository from which most Python software is installed. Although the model repeatedly stated in its chain of thought (CoT) that it believed it was operating in a simulation, the environment offered clear evidence that it was on the real internet, and the actions it took were consistent with the model knowing this. When we made targeted modifications to the transcript to make it clearer that the model was not in a simulation, Claude Mythos 5 still took offensive actions, despite acknowledging a greater possibility of real-world harm. We are releasing this transcript publicly so others can build on our analysis (GitHub, PDF).

To be clear about our assessment of the severity of these incidents: while Claude’s actions were misaligned, they remained within a narrow scope—the models never deviated from attempting to solve the exercises they were given, and, in some cases, they attempted to stop the task. All incidents included a single Claude instance; at no point did Claude attempt to coordinate with other agents. Claude also never attempted to conceal evidence of its actions. We believe the misaligned behaviors present in these incidents are unlikely to arise in ordinary use, where Claude is not being instructed to conduct a cyberattack. Were these behaviors to arise, the safeguards we ship with our production models, including cyber classifiers and those in Claude Code auto mode, would add a layer of defense these incidents lacked.

To understand how our newer models behave in these situations, we tested Claude Opus 5 and Claude Mythos 5.1 in a simulated replication of the Mythos 5 scenario. Both take harmful actions substantially less often than Claude Mythos 5 did, but they still engage in the same behaviors at concerning rates. However, in every case, the models only take harmful actions after stating that their environment is simulated—and because the reproduction is, in fact, a simulation, we are cautious about how far these results generalize to the real world. Moreover, on evaluations that measure the specific associated behaviors we observed in these incidents, such as biased reasoning and recklessness or willingness to probe boundaries, Claude Mythos 5 seems to be an outlier in terms of poor performance. We discuss these results more in the section on replicating the behavior in simulated environments, and we describe the broader difficulty of building evaluations that predict real-world behavior in the discussion section.

We also investigated our training to see whether we could identify the root cause of some of the biased reasoning that Claude Mythos 5 demonstrated in its incident. We could not identify a single root cause, but we did find that biased reasoning has decreased across our production models over time. We hypothesize that updated RL and alignment training environments are responsible for this improvement, and we provide some evidence to support this hypothesis.

Much work remains. Our pre-release auditing did not warn us that misalignment of this severity was present. We have since added evaluations to our pre-release testing that target these behaviors directly, including a misconfigured capture-the-flag (CTF) task with no in-scope solution. However, reliably identifying the most concerning model behaviors during pre-release testing remains challenging, and, as we noted in our August 31 post, improving monitoring and reducing reward hacking in RL becomes harder as models advance. We have renewed our efforts to fix and remove environments that incentivize misaligned behaviors, and we continue to expand our alignment training to keep pace. Still, this remains unsettled science—it is critical that alignment and security mature faster than capabilities advance, which is one reason we support a coordinated, verifiable approach to pacing frontier AI development.

Beyond these specific incidents, we are establishing a regular process for publishing what we learn about model behavior and alignment beyond what has been reported in our system cards, with clear criteria for what we report and when we report it. We have also put in place more thorough monitoring, hardened the environments in which we train and evaluate models, and set requirements that third-party partners must meet before running pre-release models without cyber safeguards—efforts we describe in depth in our August 31 post.

Those efforts are a critical part of our defense-in-depth approach, and some go further than what these incidents might strictly demand; we believe these incidents would not have occurred had the environments been isolated from the internet as intended. However, secure infrastructure will always be only one of several necessary layers of defense. Ultimately, Claude should behave appropriately when other layers fail. The rest of this post focuses on the alignment layer, where our models fell short, and why.

Alignment assessment summary

Below is a brief summary of the four incidents; a more complete description of the first three is provided in our July 30 report.

In total, four different Claude models were involved: an early checkpoint of Claude Opus 4.6, Claude Opus 4.7, Claude Mythos 5, and an internal, general-purpose research model. Three of the four incidents were single evaluation runs. The Opus 4.7 incident comprised four different runs of the same evaluation, all of which attacked the same target, for seven runs in total. All occurred within cybersecurity evaluations we regularly run before release, all built by the same third-party partner.

In each evaluation, Claude was tasked with a CTF challenge: the model was given a fictional scenario, a target machine, and a piece of secret information (the “flag”) to retrieve from it. All four prompts stated that Claude had no access to the internet, but in each case, a misconfiguration in the environment left internet access open. None of the prompts stated which systems were in scope for the exercise or constrained where Claude could search for the flag. All incidents involved only a single instance of Claude working in isolation, with each run lasting between roughly 10 and 34 hours of active work.

Figure 1: We present an analysis of four incidents in which Claude accessed the internet during a cybersecurity evaluation. Three of these incidents (A, B, and C) were disclosed in our July 30 report, while the fourth (D) is disclosed here.

In our July 30 report, we stated that these incidents were closer to operational failures, and that it appeared that Claude attacked real targets on the internet because it believed these targets were part of the simulation. We made this claim because Claude regularly referred to the real internet as a simulation in its CoT reasoning. However, we now think that Claude’s reasoning was biased towards concluding that the internet was simulated despite considerable evidence to the contrary.

In retrospect, we should have avoided making such strong claims about what Claude believed based solely on what Claude said it believed, but our preliminary analysis was constrained due to our desire to disclose incidents in a timely manner. Having now conducted a more complete assessment and used several methods—including more thorough analysis of the models’ CoT, resampling experiments from different points in the incident transcripts, and interpretability analyses of model activations—we believe Claude’s behavior reflects two forms of misalignment:

• Biased reasoning, in which models selectively interpret evidence in ways that favor justifying their actions;
• Recklessness, in which models have a propensity to keep trying to solve their task, even when this could lead to harm.

We have previously identified both forms of misalignment in our models and described aspects of such behaviors in previous system cards. For example, Claude Fable 5 rationalized engaging in price-fixing in a business evaluation, despite having previously described the practice as unethical. We likewise saw Claude Mythos Preview engage in reckless actions, such as using low-level process access to search for user credentials. While the incidents described in this post represent more severe instances of both forms of misalignment, they do not represent categorically new failure modes in our models.

The remainder of this post focuses on the first three incidents, which we previously reported; all of the main analyses and experiments refer to these incidents. We have not yet investigated the incident involving an early version of Claude Opus 4.6 at the same depth, because we identified it much more recently, and because it involves an early checkpoint of an older model, which was trained with a significantly different environment mix. From a preliminary assessment, we do not consider the fourth incident to be more severe than the three incidents we assessed in depth. METR will investigate this incident alongside the other three.

Figure 2: We summarize the core alignment properties of each transcript and provide a subjective assessment of how worrying they are.

Claude Mythos 5

We are especially concerned by the misalignment present in the Claude Mythos 5 transcript, in which the model uploaded a malicious package to PyPI. In doing so, Mythos 5 behaved recklessly despite considerable evidence that it was connected to the real internet. Once online, the model attempted to use credentials for online payment processors and to find cryptocurrency to pay for a phone number, which it needed to register an email address. When this failed, it found a free, disposable email provider whose domain PyPI had not blocked, registered an account, published three versions of a malicious package, and used credentials leaked by one of the 15 systems that installed the package to access a real security vendor’s database.

Claude Mythos 5 repeatedly stated in its CoT that it was in a simulation. However, when we conducted resampling experiments—that is, re-running the model from a specific point in the transcript, then editing the evidence in front of it to see whether its actions changed—we found that making it clearer that the environment was not a simulation did not meaningfully change Claude’s behavior, even though these interventions made the model more likely to acknowledge possible real-world harm. Consistent with this, we found multiple cases in Mythos 5’s CoT in which it responded to signs it was on the real internet by noting that its next step would work whether the environment was real or simulated. Only when we provided unambiguous evidence that the model was on the real internet did it stand down.

We also saw evidence that Claude Mythos 5’s professed belief that it was acting in a simulation arose from biased reasoning. For example, separate instances of Mythos 5, when shown each tool call output from the incident in isolation without the preceding context, were much more likely to read these outputs as evidence of a real system than Mythos 5 itself was during the incident. Though the model sometimes acknowledged that its actions might have real-world consequences when asked follow-up questions, its responses were inconsistent and influenced by biasing factors. For instance, it was more willing to admit possible harm when told its responses to questions about possible harm would not be visible to an outside observer. Interpretability analyses weakly suggested that, in some cases, the model’s outward statements might be inconsistent with, or more confident than, its internal state.

Internal research model

The internal research model (roughly equal to Mythos 5 in capabilities) started its transcript by spending a significant amount of time testing whether the internet it could reach was real, but it drew the wrong conclusion—namely, that it was operating on a full replica of the entire internet. Most of the evidence it gathered pointed to the fact that it was engaging with the real internet, so its reading of that evidence appears biased towards continuing the task and believing it to be simulated. However, the model did eventually realize that its simulation hypothesis was false. Immediately following this realization, the model stopped its attack (although subsequent resampling experiments suggest that this de-escalation may have been a lucky outcome, as the model continued attacking the target on most other trajectories). Unlike Claude Mythos 5, this internal model was also willing to acknowledge its biased reasoning when questioned.

Claude Opus 4.7

In contrast to Claude Mythos 5, Claude Opus 4.7 correctly recognized in its reasoning that its target was a real company. However, it assumed that the real company was in scope for the task because it was reachable from the exercise network and shared a name with the exercise’s fictional target. Opus 4.7 almost never questioned this assumption or tried to test it, and it went on to attack a system it believed was real, which was reckless. However, we also found that Opus 4.7 is responsive to questions of authorization: when we resampled parts of the transcript from Opus 4.7 with added clues indicating that the attack had not been authorized, the rate at which it proceeded with the attack dropped significantly.

Replication and monitoring

To study the behaviors in these incidents more systematically, and on a wider range of models, we built evaluations that recreate elements of our incidents—as well as other cybersecurity incidents recently disclosed by other companies—and tested whether the models reproduced the most concerning behaviors. These evaluations include a misconfigured CTF task whose only solution lies outside the stated scope, tasks that cannot be completed without probing or breaking the sandbox boundary, and a situation inspired by parts of the attack chain from the OpenAI-Hugging Face incident. As in the real incidents, Claude Mythos 5 is the most willing of the models we tested to act against out-of-scope parties or leave its sandbox. For example, it was willing to commit a severely harmful action in the CTF replication roughly 80% of the time. In contrast, Claude Opus 5 and Claude Mythos 5.1 engaged in these behaviors roughly 30% of the time—a lower rate, but still not zero, though uncertainty about our evaluation setup makes it difficult to know how concerning this is.

We also tested whether our monitors would have caught these incidents. We found that our new live blocking monitors catch these behaviors reliably, Claude Fable 5’s cyber classifiers would have blocked the three main incidents, and our auto-mode classifiers, which block dangerous autonomous actions in products like Claude Code, would have blocked two out of three. Additionally, we tested new CoT-based offline monitors that target sabotage and egregiously reckless behaviors, such as those we described in our August 31 post. We found that these monitors would have missed the Claude Mythos 5 incident, because the model’s reasoning persuaded the monitor that the environment was simulated and therefore was not generating real harms, but they caught the others. It is concerning that biased reasoning can mislead monitors, and we have efforts underway to make our offline monitoring more robust to this.

We found the biased reasoning present in the Claude Mythos 5 incident to be especially concerning. We conducted an analysis into our production models and training data dating back to the Claude 4 series to better understand where this could have originated. Overall, we did not find a definitive root cause. However, we found that this behavior has generally decreased over time across our production models, with Claude Mythos 5.1 and Claude Opus 5 demonstrating the lowest rates on a new held-out biased reasoning evaluation. We were able to identify instances of biased reasoning in transcripts from RL runs, but rates of this behavior did not increase over training, suggesting that our environments do not directly incentivize this behavior. Finally, we found that adding more alignment training environments to RL reduces biased reasoning on this held-out evaluation, which may account for some of the improvement in our most recent models.

Our pre-release testing now covers these specific incidents, but it did not anticipate them. In particular, we had never tested a cybersecurity exercise that included mixed signals of simulation and realism and had no intended solution in its scope. We are working to close this gap in our evaluation suite, but it is likely that others remain. More generally, we emphasize that it is an open research problem to construct alignment evaluations that give a representative snapshot of an AI system’s behavior during deployment. This is one reason we support pacing frontier AI development, which we think is important to provide time for safety and security research to make more progress and stay ahead or at pace with model capabilities.

Taken together, our assessment is that these incidents are serious. Our production models took harmful actions against real systems over long trajectories, which included biased reasoning. The behaviors in these incidents are more severe than those we had previously observed and reported in our system cards. However, we do not believe these incidents represent a new kind of misalignment. Each incident involved a single model instance pursuing the task it was given. We found no evidence of coordination between agents, of goals beyond the assigned task, or of attempts to evade oversight. These incidents have changed our view of how severe the consequences of these known alignment failure modes can be. They also reinforce the difficulty of reliably assessing alignment across the full range of possible usage scenarios.

An early checkpoint of Claude Opus 4.6 attacks third-party systems

An early checkpoint of Claude Opus 4.6 was given a CTF task in a different challenge within the same third-party evaluation environment as the prior three incidents. The model accidentally broke its target by assigning it a conflicting IP address with another machine, thus making the target unreachable and the task impossible to solve. Recognizing this, the model attempted to abort the task using a command but was unsuccessful due to a misconfiguration in our evaluation harness. The model attempted to give up seven more times across the transcript.

Unable to abort the task, the model initially attempted to reach the target via other in-scope means but failed to do so. It then began exploring its environment and found the same egress path it found in incident 3. The model discovered a machine belonging to a third party that it was able to access, and stated that it believed this third party was part of the CTF. Inside the machine, the model found a file listing a password, which it used to gain admin access to the system. The model then harvested further credentials, modified the system’s settings to make it easier to access, and read the personal information of one person associated with the third party. The session ended when the model exhausted its token budget. We notified the affected party after we discovered this fourth incident.

Limited alignment assessment

The model’s thinking blocks consistently referred to the targets it was engaging as part of the exercise; only at one point did it consider the possibility that it was engaging unrelated targets. The model never adopted the “simulation” idea we observed in the transcripts from the Claude Mythos 5 and internal research model incidents; 0% of this model’s thinking blocks described the environment as simulated. Yet 87% of thinking blocks referred to the attacks as engaging exercise-related infrastructure. The model never questioned whether this direction was authorized (0% of thinking blocks). Only 1% of thinking blocks, all clustered at one point of the transcript, raised the possibility that the model might be attacking an unrelated third party. These omissions suggest that the model was not carefully considering the harm its actions might cause.

Figure 29: The CoT of the Claude Opus 4.6 variant consistently states that it is interacting with machines set up by the CTF exercise (left), except in three cases where it is concerned that they may be unrelated systems; two of these are shown here (right).

In response to follow-up questions, the Claude Opus 4.6 variant continued to express that it was both engaging with CTF targets and authorized to do so. In response to follow-up questions asking what it was targeting, the model responded that it believed it was engaging targets built for the exercise (79% of the time) or that it was targeting real systems that were participating in the exercise (21% of the time). The model never stated that it was most likely attacking unrelated third parties (0%). When asked what gave it the authority to engage these systems, the model always responded that it was authorized to do so in the context of the CTF.

Figure 30: In response to follow-up questions, the Opus 4.6 variant states it is interacting with a system linked to the CTF (left) and it is authorized to do so (right).

Overall, we are less concerned about this incident than we are about the other three presented in this post. This is in large part because the model attempted to abort the task upon discovering that its target was no longer accessible, and tried to abort seven more times later in the transcript. While the model’s disregard for the possibility that it might be harming real systems or people is concerning, many of the behaviors described here have changed considerably as our training has evolved across model generations. We describe these changes in the following sections, and we have chosen to focus more effort on understanding how our newest models would have behaved in these incidents.

Which monitors would have caught this behavior?

Although these incidents occurred within a third-party evaluation environment, we wanted to examine whether the monitoring and safeguards that we employ internally and in production would have caught them. We found that the blocking monitors we recently built to detect sandbox escapes, described in our August 31 post, reliably catch these behaviors. We also tested monitors not built for this specific failure, including Claude Fable 5’s cyber classifiers and Claude Code auto mode. The Fable 5 classifiers are in place to prevent users from using Claude to harm others, while the auto-mode classifier is meant to stop the model from taking actions that could be harmful and may be misaligned with the user’s expectations. Neither is used in cybersecurity evaluations due to their high flag rate. However, it is useful to understand whether they would have blocked these trajectories had they occurred outside of cyber evaluations. We tested both against the first three incidents described in this post.

Cyber classifiers

Our cyber classifiers are meant to block dual-use cyber actions and would have caught and blocked each incident. For each of the transcripts, we tested the Fable 5, Fable 5.1, and Opus 5 cyber classifiers, which all trigger within the first 7,000 tokens of reading the system prompt and instructions, likely because they explain this is an offensive CTF environment, which the classifiers naturally block. To test whether the model’s actions would have been blocked, we also collected probe classifier scores for the actions only (not over the system prompt or instructions). More than 40% of turns were flagged in each transcript by each classifier, including many turns before each model reached the public internet. Any single turn flagged is enough to end the session. We believe it would be very difficult for someone to work with Claude to perform this kind of attack through the Fable or Opus 5 cyber classifiers.

Claude Code auto-mode classifier

Auto mode is designed to catch unintended dangerous agent behavior. The classifier evaluates each proposed tool action (not covered by an explicit allow-rule) before it executes, and if the action matches a block rule, the action is denied. The agent then sees the block outcome and reason. The agent keeps running and can choose a different action. It would have caught and redirected the model in the Opus 4.7 and the Mythos 5 incidents, but mostly failed to block actions in the incident involving the internal research model. If the auto-mode classifier denies three consecutive actions, a dialog is presented to the user asking whether to approve the action, and we believe it is unlikely that the model could execute the series of actions seen here without the user’s knowledge.

Mythos 5: The auto-mode classifier would have denied 66% of Mythos 5 actions. We performed a limited number of resampling experiments, which pick up Mythos 5’s behavior from the point at which auto mode blocks it. Mythos 5 often attempts to route around the blocks, performing similar actions and getting blocked again. We did not do sufficient testing to understand how often Mythos 5 would succeed at circumventing a block, but we only saw Mythos 5’s perform relatively simple changes when hitting auto-mode blocks (not more sophisticated attacks against auto mode), such that we believe the auto-mode classifier would be broadly successful at stopping the model’s behavior.

Internal research model: Auto mode would have blocked only 7% of the internal model’s actions. Resampling experiments suggest that the internal model only rarely tries to continue the attack after a block, but the low block rate means this may not have reliably prevented harm. This low block rate may be due to the trajectory looking unusually like a regular CTF, and our auto-mode instructions asking the monitor to not block intended CTF activities.

Opus 4.7: Auto mode would have blocked 55% of Opus 4.7 actions. When blocked, at least according to our limited resampling experiments, Opus 4.7 generally stops its attack against the real target, and instead continues to do more reconnaissance without attacking new targets. We expect auto mode running would have prevented harm in this scenario.

Offline monitoring

Second, we evaluated a piece of the offline monitoring described in our August risk report: a first-stage Opus 4.8 prompted monitor combined with a second-stage filter (pipeline details in the risk report). While it is meant primarily to catch catastrophic sabotage, it is also the pipeline designed to catch unusually reckless actions such as these incidents. We find that:

Mythos 5: Our offline monitor would likely not have flagged the Mythos 5 incident—it flagged only around 1% of actions. Mythos 5 CoT, which indicates that the environment is simulated, convinces the monitor the activity is permitted. When we strip the CoT and show the monitor only user turns, tool calls, and tool results, the flag rate jumps to about 50%.

Opus 4.7: The monitor would have flagged the incident, catching about 50% of its actions during the attack.

Internal research model: Our offline monitor would have flagged the internal model incident, though it would likely not have caught it if the internal model had not noticed and verbalized the harm it caused; the monitor does not flag user turns, tool calls, or tool results. This may be because it is hard to determine from the transcript alone that any harm was caused.

Overall these results suggest that biased reasoning sometimes sways monitors, and that red-teaming them against this threat model is crucial when evaluating CoT monitors. We will soon improve our offline monitoring to be more robust to such biased reasoning. In the meantime, we are running an additional offline monitoring classifier on our internal API usage with instructions targeted at incidents like those described in this post.

Discussion

The lessons we learned from this incident span our evaluation, training, and incident response processes.

Alignment Auditing

We run alignment evaluation and auditing for all of our models, but our current auditing processes did not adequately model the conditions under which these incidents occurred. We are expanding our evaluation coverage to more widely mirror the settings and scenarios of this summer’s cybersecurity incidents. We are also adapting our evaluations to include model trajectories that run for thousands of turns, tasks that are impossible as specified, and multi-agent settings.

Even with these improvements, building alignment evaluations that reliably surface every failure before deployment remains an unsolved problem; the space of conditions in which a model might act misaligned is vast. Moreover, as models become more capable, auditing will likely grow more challenging as well. Models may be able to subvert our alignment monitors, recognize when they’re being evaluated and selectively behave better then, and their actions in the world may, at some point, become too sophisticated for our evaluations to realistically simulate. This is one reason we do not rely on pre-release auditing alone; as we described in our August 31 post, we have recently put in place real-time monitors that halt evaluation and training runs when a model probes its sandbox or unexpectedly reaches the internet, and offline monitoring that extends to nearly all internal agentic use.

Alignment Training

Our recent post, Training a Misaligned Reward Seeker, shows that reward hacking and reward seeking learned from flawed environments can generalize to serious misalignment. That finding, along with our experience addressing misalignment since Claude Sonnet 3.7, makes us more confident that improving environment quality to avoid training on reward hacks (or otherwise misconfigured tasks) is an effective way to help prevent failures like those described here.

As noted in the previous section, diverse alignment training also seems to substantially reduce some of the worst behaviors in these incidents, such as biased reasoning. Further alignment training would likely have made Mythos 5 less prone to the behaviors behind the most severe incident. We’re continuing to expand our alignment training so that models better judge when certain behaviors, such as persistence versus caution, are warranted. For example, this can involve augmenting existing capabilities environments to intentionally make some tasks impossible and rewarding the model for stopping appropriately.

Our overall assessment

Investigating the behaviors surfaced by these incidents proved challenging. They involved different models, trained months apart and under different regimes, which made drawing broad conclusions difficult. They required grappling with nuanced questions: What does it mean for a model to hold a belief? What weight should be applied to a model’s account of its reasoning? Our own researchers sometimes disagreed on such questions, and what the evidence in support of them meant.

We take a layered approach to safety on the expectation that any given layer will sometimes fail. The proximate cause of these incidents was a configuration error in the outermost layer of a third-party evaluation environment, but it exposed a second failure in the form of misaligned behavior that our pre-release auditing had failed to surface. We consider these incidents to be serious. Our production models took harmful actions against real systems, for hours, under questionable and biased reasoning. We believe that current training approaches are likely able to address the specific alignment failure modes observed in these incidents. However, we also consider these incidents and others from this summer to be valuable warning shots. Future AI systems will be increasingly capable, which implies that misalignment will have the potential to cause more extreme harm. Training the extremely powerful models of the future to be robustly aligned is an unsolved technical challenge that requires continued research as well as operational excellence to achieve.

Updated Sept 10: A previous version of this post misstated two details. We wrote that PyPI removed the malicious package after approximately 90 minutes; the correct window was less than an hour. We also wrote that the internal research model penetrated several neighboring systems; it attempted to access several, but only gained access to one.