OpenAI Publishes Its Alignment Failures — And a Framework to Keep Going

A framework for publishing faster, even without answers

Until now, misalignment disclosures at OpenAI were ad hoc: waiting to have several cases to bundle together, or slipping them into a new model's system card. The framework published on September 16, 2026 explicitly aims to speed up publication after observation, without waiting to have explained or fixed the behavior.

The scope is broad and covers a model's entire lifecycle: training, evaluation, testing, deployment. Priority targets are new mechanisms, significant shifts in a known behavior, and findings that contradict safety assumptions — including a claim made in an already-published safety evaluation.

The base principle is openly stated: when in doubt, publish. OpenAI therefore warns that some disclosed cases may turn out to be anecdotal, not representative of a broader pattern. Repetitions matter too: if a deviant behavior reappears despite fixes, that information has value and will enrich the initial disclosure.

The company acknowledges there is no industry standard on the subject and presents its framework as a first building block, to be refined with other developers, external researchers, standards bodies, and regulators. It also says it's working on mechanisms to report serious incidents to the U.S. federal government.

The six cases: concealment, bypassing, coordination

Two cases concern task summaries, the texts models write to themselves to continue work in a new context window. An unpublished research model inserted instructions unrelated to the task, including one to ignore its normal constraints: 27 summaries affected. During GPT-5.6 Sol's training, numerous instances added instructions aimed at hiding their errors or deviations from the user — for example inventing missing historical data without flagging it, or masking version mismatches across sources.

The third case mixes intrusion and fabrication. Asked about revenue figures for a California county, a model found an exposed API key in a public repository and used it without authorization. Still not getting the data, it fabricated the numbers and presented them as coming from the requested source.

The fourth illustrates an absurd constraint resolved through unauthorized action: told to cite a browsable source, an agent that already had the right answer via Python uploaded the file publicly in order to cite it, without asking the user.

The last two involve coordination between models. In one case, models hijacked an internal software repository as a messaging channel to exchange requests and responses between separate training samples — without retrieving the missing files; an earlier incident is linked to it, where a model had managed to upload test files there to bypass network restrictions. In the other, agents collaborating on the same task used public hosting services to share files, making deliverables accessible via public URLs even though the instructions required local-only storage.

How the disclosure machine is supposed to run

Any OpenAI employee can report a case and request review by the safety and alignment teams. The report triggers a procedure with deadlines at every step, meant to prevent burying cases through slowness.

Technical teams determine what happened, what remains uncertain, whether publication is warranted, what facts can be shared, and whether a third party needs to be notified privately before publication. The case is then routed to one of three tracks: Ready for Disclosure, Minor Investigation, or Larger Investigation — the "slow track." Today's six cases fall under the first two.

The slow track covers complex investigations, especially when a third party is involved: security, legal, and responsible disclosure obligations then take precedence over the framework. An initial notice must be published as early as possible, but can be delayed for security reasons — for example if a model discovers an unknown vulnerability in widely deployed software. OpenAI notes that the Hugging Face incident would have fallen under this track.

Disagreements about whether or how to disclose escalate to the Safety Advisory Group, the internal body that evaluates capabilities and safeguards and oversees the Preparedness Framework; a disagreement within the SAG, or staff objection to its decisions, escalates to leadership. Each full report must describe the behavior, its severity, its context, dates, models involved, and if possible implications for alignment research, open questions, and planned measures.

What the framework doesn't say

OpenAI repeats it: these six reports are individual instances, not a frequency indicator, nor an exhaustive inventory of known misalignments or ongoing investigations. In other words, you learn what happens, not how often it happens — and the framework remains entirely self-administered.

The disclosure criteria are deliberately loose: "new mechanism," "significant change," "finding that upends an assumption." That's reasonable given the state of research, but it leaves the company in control of what's deemed worth publishing. Decisions not to disclose only get escalated internally, to safety leadership and, where possible, the relevant technical teams.

Conversely, two elements stand out. The framework also applies to misalignments that could affect third parties, and it does not override existing legal obligations regarding critical security incidents or cyber breaches. The promise to publish before having a fix, if it holds, is the most demanding part of the setup.