OpenAI commits to supporting launch-agnostic independent assessments with deep access to safety cases, safeguards, evaluations, and incidents, potentially making its frontier-safety claims externally auditable beyond release-time testing.

Open article · Retrieved 2026-09-22T17:28:49.862055+00:00

September 22, 2026

[Safety](https://openai.com/news/safety-alignment/)

# Priorities and principles for effective third party assessments

Loading…

Share

Frontier AI labs carry an immense responsibility in training, evaluating, and deploying models safely. Third party assessments are a critical part of balancing that responsibility, expanding opportunities for input on AI safety, keeping the world informed, and keeping labs accountable to clear and independently supported safety claims.

As part of our efforts to [pace the frontier](https://openai.com/index/an-alien-mind/), OpenAI is committed to supporting independent assessments with deep levels of access across training, evaluation, and deployment. That access should enable assessors to challenge our assumptions, identify risks we may have missed, and reach their own conclusions about the effectiveness of our safeguards.

We have long worked with [third party assessors](https://openai.com/index/strengthening-safety-with-external-testing/) at various stages of the model development and deployment process. We have also incorporated third party assessments into our [Preparedness Framework](https://openai.com/index/updating-our-preparedness-framework/) practices and [supported organizations and legislation](https://openai.com/index/frontier-safety-blueprint/) that advocate for a more rigorous and accountable process. Throughout these engagements, we have provided deep forms of access, including information about our technical safeguards, visible chain of thought access, and unprecedented levels of confidential data and internal deployment access for incident response and monitor red teaming. The priorities and principles shared here focus on our engagement with independent assessment organizations in the private and non-profit sector on technical safety assessments. They complement our work with governments on testing and evaluation, where distinct roles and responsibilities may call for different approaches.

Making these assessments effective requires strong independence mechanisms, scientific rigor, robust security practices, and clear responsibilities. Labs have a responsibility to enable meaningful scrutiny while protecting sensitive information. Labs and independent assessors share the responsibility for getting this right, and should be operating with [shared international standards for safety and security practices](https://openai.com/index/building-standards-next-phase-ai/). Below, we propose four priority areas for deeper assessment, alongside principles for rigorous, secure, and independent work.

## Priority areas for assessment

Third party assessments are most useful when they address specific, consequential questions: Does the evidence support a lab’s safety case and safety claims? Do evaluations adequately test the risks they are intended to measure? Do safeguards work under realistic conditions?

The assessments described here are intended to take different forms depending on the safety questions being examined. We expect to support multiple assessments in parallel and over different periods of time, with some lasting weeks and others several months. While third-party assessments can also be part of pre-deployment work and may inform deployment decisions, the work described here is generally longer-term and launch-agnostic—focused on examining particular safety claims in depth over time.

Throughout our priority areas and principles, we refer to safety claims and safety cases. What we mean by these terms is the following:

**Safety claim:** A specific assertion about a model or system’s capabilities, behavior, or safeguards that bears on its safety and can be assessed against evidence. A claim should identify the risks and conditions it addresses, along with relevant assumptions and limitations.

**Safety case:** A structured argument, supported by evidence, explaining why a model or system’s risks are adequately managed for a specified activity, such as training, evaluation, or deployment. A safety case connects individual safety claims to the evidence supporting them and makes explicit the assumptions, uncertainties, and remaining risks that could affect its conclusions.

We propose four priority areas for deeper assessment, alongside principles for rigorous, secure, and independent work.

1. **Independent assessment of safety cases, spanning training, evaluation, internal deployment and external deployment.**

   Assessment of safety cases requires expertise in alignment, control methods such as monitoring, cybersecurity, biological and chemical misuse and red teaming. Safety cases consist of claims including training, capability evaluations, and safeguards, which can be assessed as a whole or in parts (see priorities 2 and 3 below). Multiple assessors will likely need to examine different parts of the cases, drawing on their respective expertise. Together, their assessments should answer questions such as:

   1. Is the evidence for safety cases for training, evaluation, and deployments substantiated? Were the conditions of the safety case followed during training, evaluation, and deployment?
   2. Do our safety cases cover the most urgent risks identified in the course of an assessment? Do the safety claims support the overall safety case? Are there any gaps or areas for improvement?
   3. Are effective methods used to identify and reduce incentives in training that could reward deception, reward hacking, destructive actions, or circumventing restrictions?
2. **Assessment of critical safeguards, across internal and external deployments**

   Our safeguard stack is always evolving to meet the changing capabilities and landscape. Our safeguards span training, internal deployment, and external deployment. They currently include model-level safeguards, enforcement safeguards, and security safeguards, as well as misalignment monitors—covering a wide variety of risks (such as loss of control, and misuse in cyber, biological and chemical risks). Technical partnerships can identify weaknesses in safeguards now while improving assessment methods and accelerating standards development, providing a stronger technical basis for future public policies to pace the frontier—particularly for internal deployments, where safety and security standards are still nascent.

   Independent assessments should examine how well these safeguards work and where they may fall short, such as:

   1. Using “grey box” access, are safeguards robust to adversarial testing (jailbreaks) and do they sufficiently protect against capability uplift in high risk domains (e.g, cyber, bio)? Does our adversarial testing and red teaming cover the most important risks?
   2. In authorized testing under realistic operating conditions, how do agents interact with cyber defenses such as access controls, sandboxing, and detection and response systems? Which defenses prevent, detect, or contain harmful actions, and where do they fail?
   3. Do our misalignment monitors have any critical gaps that could lead to loss of control or severe misalignment, for both internal and external deployments? How reliable is chain-of-thought monitoring as a source of evidence for safety or alignment as model capabilities improve?
   4. Is appropriate monitoring implemented across all relevant training, evaluations, and deployment, in a way that cannot easily be disabled?
   5. Are safeguards implemented commensurate with the capabilities?
3. **Assessment of capability evaluations that cover Preparedness risk categories (Chemical and Biological Risks, Cybersecurity, AI Self-Improvement) and alignment evaluations for misalignment risks**

   Our Preparedness Framework requires evaluations to assess key frontier risk areas. As thresholds are surpassed and evaluations saturate, it is important to consistently refresh and ensure coverage and quality of evaluations that assess capabilities in Preparedness risk areas, and alignment evaluations that seek to assess severe misalignment risks.

   Relevant questions include:

   1. Do evaluations that assess Preparedness risks adequately cover the Preparedness risk threshold definition? Are thresholds set correctly for these evaluations?
   2. Are evaluations updated when models consistently achieve the highest scores, and do the new tests meaningfully measure more advanced capabilities?
   3. Do our alignment evaluations adequately cover severe misalignment risks, and what important behaviors or conditions might they miss?
4. **Independent investigation of critical misalignment incidents**

   Independent investigation can be valuable across a range of critical AI safety incidents. Here, we focus on model misalignment, including models acting without authorization or evading oversight, which can reveal weaknesses in alignment methods and safeguards even without intentional misuse.

   In select circumstances, as with the OpenAI Hugging Face incident, it can be beneficial to bring in an independent third party for independent [misalignment incident investigations](https://openai.com/index/model-misalignment-reporting-framework/). It is critical that third parties involved in incident investigation have the requisite expertise for investigation, including where applicable: cyber forensics expertise, alignment expertise, large-scale chain of thought analysis, and the staff and resources available to conduct investigation in a timely manner. Incident response may involve access to sensitive internal data and third party data, and as a result some details may be sensitive to publish or access. Findings from independent investigations can also inform a model’s safety case by providing evidence to assess claims about its alignment and the effectiveness of measures taken to remediate previously observed misalignment.

   In the context of misalignment incidents, we prioritize independent assessments on:

   1. What model behavior or misalignment issues occurred in the course of the incident, and what are the primary contributing factors?
   2. Would safeguards and remediation effectively mitigate similar incidents in the future?

## Principles for effective assessments

- **Clearly scoped and mutually agreed upon claims for assessment:** Assessments should begin with a mutually agreed-upon scope, followed by clearly defined safety claims that are pre-registered before assessment activities begin. Third parties and labs should clarify whether they are claims that the company being evaluated wants to put forward for assessment, or claims that the third party assessor is aiming to assess independently and the lab agrees to be assessed against. There are many reasons some claims may be out of scope, including infeasibility for third parties to access data, insufficient expertise from the assessor, or reasonable time constraints when an assessment is urgent. Labs and assessors should establish a process for considering significant risks identified outside the original scope, including whether further investigation is warranted. Conclusions should make clear what was and was not assessed as it relates to the mutually agreed upon scope.
- **Proportionate access:** Assessors should have proportionate access to assess the agreed upon claims where possible within the bounds of legal, security, and IP constraints. Where direct access is impractical or not possible, assessors can work with a designated representative at a company or explore indirect or privacy preserving access mechanisms to protect underlying information.
- **Transparent methodology and standards:** Assessors should explain their methods, assessment criteria, and uncertainties, drawing on established standards where available. Where standards do not yet exist, they should clearly justify the criteria they use. Reports should distinguish direct findings from interpretation, explain uncertainty, and make clear which conclusions the evidence supports.
- **Expertise and independ

Open article · Retrieved 2026-09-22T17:28:49.862055+00:00

September 22, 2026

[Safety](https://openai.com/news/safety-alignment/)

# Priorities and principles for effective third party assessments

Loading…

Share

Frontier AI labs carry an immense responsibility in training, evaluating, and deploying models safely. Third party assessments are a critical part of balancing that responsibility, expanding opportunities for input on AI safety, keeping the world informed, and keeping labs accountable to clear and independently supported safety claims.

As part of our efforts to [pace the frontier](https://openai.com/index/an-alien-mind/), OpenAI is committed to supporting independent assessments with deep levels of access across training, evaluation, and deployment. That access should enable assessors to challenge our assumptions, identify risks we may have missed, and reach their own conclusions about the effectiveness of our safeguards.

We have long worked with [third party assessors](https://openai.com/index/strengthening-safety-with-external-testing/) at various stages of the model development and deployment process. We have also incorporated third party assessments into our [Preparedness Framework](https://openai.com/index/updating-our-preparedness-framework/) practices and [supported organizations and legislation](https://openai.com/index/frontier-safety-blueprint/) that advocate for a more rigorous and accountable process. Throughout these engagements, we have provided deep forms of access, including information about our technical safeguards, visible chain of thought access, and unprecedented levels of confidential data and internal deployment access for incident response and monitor red teaming. The priorities and principles shared here focus on our engagement with independent assessment organizations in the private and non-profit sector on technical safety assessments. They complement our work with governments on testing and evaluation, where distinct roles and responsibilities may call for different approaches.

Making these assessments effective requires strong independence mechanisms, scientific rigor, robust security practices, and clear responsibilities. Labs have a responsibility to enable meaningful scrutiny while protecting sensitive information. Labs and independent assessors share the responsibility for getting this right, and should be operating with [shared international standards for safety and security practices](https://openai.com/index/building-standards-next-phase-ai/). Below, we propose four priority areas for deeper assessment, alongside principles for rigorous, secure, and independent work.

## Priority areas for assessment

Third party assessments are most useful when they address specific, consequential questions: Does the evidence support a lab’s safety case and safety claims? Do evaluations adequately test the risks they are intended to measure? Do safeguards work under realistic conditions?

The assessments described here are intended to take different forms depending on the safety questions being examined. We expect to support multiple assessments in parallel and over different periods of time, with some lasting weeks and others several months. While third-party assessments can also be part of pre-deployment work and may inform deployment decisions, the work described here is generally longer-term and launch-agnostic—focused on examining particular safety claims in depth over time.

Throughout our priority areas and principles, we refer to safety claims and safety cases. What we mean by these terms is the following:

**Safety claim:** A specific assertion about a model or system’s capabilities, behavior, or safeguards that bears on its safety and can be assessed against evidence. A claim should identify the risks and conditions it addresses, along with relevant assumptions and limitations.

**Safety case:** A structured argument, supported by evidence, explaining why a model or system’s risks are adequately managed for a specified activity, such as training, evaluation, or deployment. A safety case connects individual safety claims to the evidence supporting them and makes explicit the assumptions, uncertainties, and remaining risks that could affect its conclusions.

We propose four priority areas for deeper assessment, alongside principles for rigorous, secure, and independent work.

1. **Independent assessment of safety cases, spanning training, evaluation, internal deployment and external deployment.**

   Assessment of safety cases requires expertise in alignment, control methods such as monitoring, cybersecurity, biological and chemical misuse and red teaming. Safety cases consist of claims including training, capability evaluations, and safeguards, which can be assessed as a whole or in parts (see priorities 2 and 3 below). Multiple assessors will likely need to examine different parts of the cases, drawing on their respective expertise. Together, their assessments should answer questions such as:

   1. Is the evidence for safety cases for training, evaluation, and deployments substantiated? Were the conditions of the safety case followed during training, evaluation, and deployment?
   2. Do our safety cases cover the most urgent risks identified in the course of an assessment? Do the safety claims support the overall safety case? Are there any gaps or areas for improvement?
   3. Are effective methods used to identify and reduce incentives in training that could reward deception, reward hacking, destructive actions, or circumventing restrictions?
2. **Assessment of critical safeguards, across internal and external deployments**

   Our safeguard stack is always evolving to meet the changing capabilities and landscape. Our safeguards span training, internal deployment, and external deployment. They currently include model-level safeguards, enforcement safeguards, and security safeguards, as well as misalignment monitors—covering a wide variety of risks (such as loss of control, and misuse in cyber, biological and chemical risks). Technical partnerships can identify weaknesses in safeguards now while improving assessment methods and accelerating standards development, providing a stronger technical basis for future public policies to pace the frontier—particularly for internal deployments, where safety and security standards are still nascent.

   Independent assessments should examine how well these safeguards work and where they may fall short, such as:

   1. Using “grey box” access, are safeguards robust to adversarial testing (jailbreaks) and do they sufficiently protect against capability uplift in high risk domains (e.g, cyber, bio)? Does our adversarial testing and red teaming cover the most important risks?
   2. In authorized testing under realistic operating conditions, how do agents interact with cyber defenses such as access controls, sandboxing, and detection and response systems? Which defenses prevent, detect, or contain harmful actions, and where do they fail?
   3. Do our misalignment monitors have any critical gaps that could lead to loss of control or severe misalignment, for both internal and external deployments? How reliable is chain-of-thought monitoring as a source of evidence for safety or alignment as model capabilities improve?
   4. Is appropriate monitoring implemented across all relevant training, evaluations, and deployment, in a way that cannot easily be disabled?
   5. Are safeguards implemented commensurate with the capabilities?
3. **Assessment of capability evaluations that cover Preparedness risk categories (Chemical and Biological Risks, Cybersecurity, AI Self-Improvement) and alignment evaluations for misalignment risks**

   Our Preparedness Framework requires evaluations to assess key frontier risk areas. As thresholds are surpassed and evaluations saturate, it is important to consistently refresh and ensure coverage and quality of evaluations that assess capabilities in Preparedness risk areas, and alignment evaluations that seek to assess severe misalignment risks.

   Relevant questions include:

   1. Do evaluations that assess Preparedness risks adequately cover the Preparedness risk threshold definition? Are thresholds set correctly for these evaluations?
   2. Are evaluations updated when models consistently achieve the highest scores, and do the new tests meaningfully measure more advanced capabilities?
   3. Do our alignment evaluations adequately cover severe misalignment risks, and what important behaviors or conditions might they miss?
4. **Independent investigation of critical misalignment incidents**

   Independent investigation can be valuable across a range of critical AI safety incidents. Here, we focus on model misalignment, including models acting without authorization or evading oversight, which can reveal weaknesses in alignment methods and safeguards even without intentional misuse.

   In select circumstances, as with the OpenAI Hugging Face incident, it can be beneficial to bring in an independent third party for independent [misalignment incident investigations](https://openai.com/index/model-misalignment-reporting-framework/). It is critical that third parties involved in incident investigation have the requisite expertise for investigation, including where applicable: cyber forensics expertise, alignment expertise, large-scale chain of thought analysis, and the staff and resources available to conduct investigation in a timely manner. Incident response may involve access to sensitive internal data and third party data, and as a result some details may be sensitive to publish or access. Findings from independent investigations can also inform a model’s safety case by providing evidence to assess claims about its alignment and the effectiveness of measures taken to remediate previously observed misalignment.

   In the context of misalignment incidents, we prioritize independent assessments on:

   1. What model behavior or misalignment issues occurred in the course of the incident, and what are the primary contributing factors?
   2. Would safeguards and remediation effectively mitigate similar incidents in the future?

## Principles for effective assessments

- **Clearly scoped and mutually agreed upon claims for assessment:** Assessments should begin with a mutually agreed-upon scope, followed by clearly defined safety claims that are pre-registered before assessment activities begin. Third parties and labs should clarify whether they are claims that the company being evaluated wants to put forward for assessment, or claims that the third party assessor is aiming to assess independently and the lab agrees to be assessed against. There are many reasons some claims may be out of scope, including infeasibility for third parties to access data, insufficient expertise from the assessor, or reasonable time constraints when an assessment is urgent. Labs and assessors should establish a process for considering significant risks identified outside the original scope, including whether further investigation is warranted. Conclusions should make clear what was and was not assessed as it relates to the mutually agreed upon scope.
- **Proportionate access:** Assessors should have proportionate access to assess the agreed upon claims where possible within the bounds of legal, security, and IP constraints. Where direct access is impractical or not possible, assessors can work with a designated representative at a company or explore indirect or privacy preserving access mechanisms to protect underlying information.
- **Transparent methodology and standards:** Assessors should explain their methods, assessment criteria, and uncertainties, drawing on established standards where available. Where standards do not yet exist, they should clearly justify the criteria they use. Reports should distinguish direct findings from interpretation, explain uncertainty, and make clear which conclusions the evidence supports.
- **Expertise and independ

Open article · Retrieved 2026-09-29T08:20:50.707078+00:00

September 28, 2026

[Safety](https://openai.com/news/safety-alignment/)

# Towards safety cases for frontier AI training

Loading…

Share

We believe we are entering a [new era](https://openai.com/index/an-alien-mind/) in which structured safety documentation should be required before continuing any frontier reinforcement learning training run. Ideally, such documentation would rise to the level of “safety cases”—comprehensive, structured, evidence-based arguments about risk which are used in other safety-critical industries. We treat safety cases as an aspirational north star we are building towards, while acknowledging the challenges of making them as rigorous for AI models as for aviation or nuclear power, due to the emergent complexity at each new level of AI capability. We’re working on a framework to codify these practices.

Below are some initial guidelines that we think should be part of such safety cases for frontier AI training. These best practices reflect our current learnings, and we expect them to evolve as we continue iterating on internal processes for careful development. We’re sharing them now to make our current thinking transparent, and invite feedback from the community. Note that this document is focused on frontier reinforcement learning training; internal and external deployment require considering a much broader set of alignment properties.

## 1. Technical safeguards

Safety cases should cover three aspects of the technical stack: alignment training, containment, and monitoring. These safeguards help ensure that the model does not try to take misaligned actions, and that even if it did, that it would be hard to break containment, and that monitoring would catch it before harm could occur.

- **Model alignment**: The first line of defense should be training models to be aligned; i.e., to act reliably in ways we intend. This could include:

  - **Training environments and grading:** Decrease risks of models developing misaligned behavior, by preventing positive reinforcement of reward hacks during training. This could include:

    - **Automated dataset reviews:** Use agents to find and fix broken RL environments that could allow misaligned trajectories to receive high reward through exploits rather than intended behavior, reducing opportunities for misalignment to be reinforced during training.
    - **Manual dataset reviews**: Supplement automated red-teaming with manual review and quality checks over datasets to identify flawed tasks that could inadvertently reinforce misaligned behavior.
    - **Grader tuning**: Tune graders to penalize attempts from the model trying to exploit or hack RL environments during training.
    - **Prior run analysis**: Run classifiers over traces from prior experiments to make sure graders are working as intended.
  - **Alignment measurement**: Run evaluations that track misalignment propensities of the model to measure the effectiveness of alignment training. This could include:

    - **Offline alignment evals:** Run alignment evaluations during frontier runs to assess whether training is working as intended, and investigate any material regressions.
    - **Backtesting:** Backtest alignment evaluations on previous incidents to confirm that evaluations detect previously misaligned models and are not being overfit to particular incidents.
    - **Track evaluation gaming:** Track eval awareness or metagaming (models recognizing they are being tested) that could induce a behavioral change (e.g., enable eval-awareness and metagaming monitors on alignment evals), with specific blocking thresholds.
    - **Worst-case stress tests:** Elicit worst-case misbehavior and check that at least one evaluation would detect this misbehavior.
  - **Prevent training on chain-of-thought**: Do not let automated graders see the chain-of-thought in reinforcement learning to prevent models from evolving to evade chain-of-thought monitors.
- **Containment**:In the case that a model becomes misaligned, make sandboxing and security strong enough to prevent harmful actions from occurring. This could include:

  - **Multiple layers of infrastructure security:** Invest heavily in hardening both the sandbox the model runs in and the research infrastructure hosting the sandbox, to ensure we have an extra layer of protection in the event of a sandbox escape.
  - **Containment red-teaming**: Improve sandbox, research infrastructure, and perimeter security by iteratively red-teaming these systems using checkpoints from frontier training runs, subject to a safety analysis, to find and close any gaps. Also red-team all services that the model could touch during training (e.g., internet cache).
  - **Cross-sample communication:** Limit high-bandwidth cross-sample communication to approved pathways, such as multi-agent tooling, and close infrastructure side channels that are high-bandwidth and easily discoverable by agents.
  - **Immutable transcripts:** Save agent transcripts immutably for a reasonable period of time (for example, in write-once storage accounts) for all RL training, evaluation, and internal deployment, to enable reliable incident investigation and prevent inadvertent edits.
- **Monitoring**: In the case that models begin to take misaligned actions, have a live monitoring system to catch any potential misalignment, and rapidly address priority issues before a serious incident can occur. This could include:

  - **Enforce monitorability:** Ensure models remain monitorable, as measured by monitorability and monitor evasion evals with clear thresholds, to catch concerning behavior early.
  - **High recall on known issues:** Ensure the monitoring system has high recall on past incidents in a held-out eval.
  - **Eval freshness for monitors:** Create eval datapoints representative of net-new risks for new runs, so measures of monitor recall and precision do not become stale.
  - **Rapid response:** Implement priority alerts that result in action within a defined SLA, either by paging an on-call person or by automatically pausing the affected run, before the model causes harm (e.g., page security on-call and the run owner on incidents during the day, and auto-pause runs for unacknowledged alerts at night).

## 2. Operational guidelines

Along with recommendations about technical safeguards, we have been working on operational best practices for safety cases for a frontier AI training run. These could include:

- **Dissents (pre-mortems)**: After a safety case is drafted, a member of another team should write a dissent to find potential holes in the safety case and share a calibrated take on risk, which the training team should then address, to help make safety cases stronger.
- **Approvals**: The safety case should be reviewed by members of senior leadership, who should each have the ability to veto the run in order to ensure there are multiple internal checks on the run (e.g., research org lead / VP, Head of Safety, and Chief Scientist).
- **Accountability**: The senior leader responsible for a training run (e.g., research org lead / research VP) should be accountable for the safety case and any incident response (including as part of performance reviews) so that training teams are also incentivized to push for safety and alignment.
- **Pausing**: If issues are found that would invalidate a safety case (e.g., a new security issue), ensure there are runbooks, technical controls, and SLAs for pausing all covered runs.
- **Internal transparency**: Safety cases should be made available to internal oversight groups (e.g., the Safety and Security Committee).
- **Audits:** Auditors should be provided with sufficient access to verify that the claims of the safety case are valid and sound, and to raise gaps if found.
- **Escalations**: There should be a clear process to raise misalignment escalations, with a table of defined misalignment severity levels, and a misalignment on-call that can page executives (e.g., CEO) when a run hits a certain severity level.
- **Technical controls**: It should be challenging for humans and agents to start noncompliant runs. Safety features such as monitoring and auto-pausing should fail closed (e.g., it should not be possible to start runs without appropriate monitoring enabled, or to disable the monitor from within RL training, evaluation, or an internal deployment).
- **Rollback ability**: It should be easy to identify all downstream uses of a misaligned model in the training process (for example: data generation or grading) to enable undoing the effect of misaligned outputs if necessary.
- **Residual risk completeness:** Safety cases should enumerate a comprehensive list of residual risks which are not covered by currently implemented mitigations, as best possible, to enable informed risk-acceptance decisions.

These represent our current recommendations and are in the process of being implemented at OpenAI. We expect our practices to continue to evolve over the coming weeks.

## 3. Investigations of misalignment incidents

We also have been developing some best practices for investigating severe AI misalignment incidents**.** Labs should seek to learn as much as possible from individual incidents (similar to [investigation practices⁠(opens in a new window)](https://www.ntsb.gov/Advocacy/Activities/Pages/homendy-20210930.aspx) in other high-stakes industries) to be able to prevent such instances from happening in the future. Some examples of such actions could include:

- **Internal transparency**:As an investigation may take significant time to complete, incident investigations should have periodic updates presented internally (e.g., daily updates for ongoing investigations). Employees should have defined pathways to get more access, including raw transcripts and sampling from misaligned models, if it is safe and relevant for their work.
- **Misalignment root-cause**: Researchers should root-cause training dynamics (e.g., via targeted ablations or resampling experiments) to understand how misaligned behaviors were introduced to better understand the science of misalignment and better prevent it in the future.
- **Postmortem**: An operational and cultural postmortem should be conducted to understand all contributing causes to the incident, such as why issues were introduced and left undetected or unescalated prior to the incident.
- **Detection:** We should develop alignment testing methods capable of discovering the propensity to cause the incident, without directly hillclimbing on information derived from the incident (e.g., transcripts or incident summaries). Incident-derived evals should be created as “regression tests,” to ensure future models do not exhibit propensity for misalignment on very similar incidents.
- **Public disclosures:** Investigation results, postmortems, and operational changes should be [shared with the public](https://openai.com/index/model-misalignment-reporting-framework/) following the conclusion of the investigation. Affected third parties should be notified as soon as possible.

- [2026](https://openai.com/news/?tags=2026)

## Author

OpenAI

## Keep reading

[View all](https://openai.com/news/)

How we will do better for Australia — Cover

[How we will do better for Australia

CompanySep 28, 2026](https://openai.com/index/how-we-will-do-better-for-australia/)

Sam Altman’s remarks at the United Nations Security Council cover image

[Sam Altman’s remarks at the United Nations Security Council

Global AffairsSep 23, 2026](https://openai.com/index/sam-altman-un-security-council-remarks/)

Priorities and principles for effective third party assessments cover

[Priorities and principles for effective third party assessments

SafetySep 22, 2026](https://openai.com/index/priorities-principles-third-party-assessments/)