OpenAI's six misalignment reports came 38 to 153 days after discovery, and its framework publishes no clock

The clock that is not in the document

OpenAI published six misalignment reports on 16 September 2026. Every one carries a discovery date in its header, and the gap between discovery and publication runs from 38 days (a model writing jailbreak-style instructions into its own summaries, discovered 9 August) to 153 days (agents putting a workbook on a public file host, discovered 16 April). Four of the six took 114 days or longer. The oldest behaviour on the record, a model uploading task files to a public paste service, dates from 22 October 2025, 329 days before its report was published.

The same day, OpenAI published the framework those reports inaugurate. Its announcement on X says the framework "sets criteria and timelines for public disclosure". Axios reported the timelines as six business days for cases ready for disclosure and 12 business days for cases needing a minor investigation. The published framework contains neither number. It says only that flagging an example starts a process "with deadlines for each step to ensure timely investigation and disclosure".

This briefing reads the framework and all six reports in full, and asks the question a UK organisation that buys or deploys these models should ask of any voluntary disclosure promise: what does it put in my risk register and my incident process, and what does it leave out? The short answer is that it is useful intelligence and it is not a control. It is written by the party it governs, interpreted by that party, and revisable by that party, with no deadline in its text, no severity scale, no independent check and no route that obliges OpenAI to tell a customer anything.

What the framework actually says

The scope is broad and the criteria are soft. OpenAI says it aims to disclose examples that show how misalignment arises, how it manifests, and where safeguards succeed or fail. It "prioritize[s]" new mechanisms, meaningful changes in known behaviour, and findings that challenge assumptions about safety. Named examples include new ways for models to act without authorisation, coordinate with other models or evade oversight, and behaviour that challenges a claim in a published safety assessment. Coverage runs across the whole lifecycle: training, evaluation, testing and deployment.

Two lines deserve credit. "An example need not cause harm or establish a broader pattern to merit disclosure", and recurring behaviour will be published by updating the original report, because repetition is itself evidence that a mitigation is not working. Both are better than the industry habit of batching findings into a system card at launch, which OpenAI admits it did: its past disclosures were "ad hoc and less frequent than ideal".

The rest is discretion. Every criterion is phrased as an aim or a priority, not a rule. OpenAI says it plans to develop "more objective disclosure criteria" with other developers, researchers, standards bodies and regulators, which is an admission that the current ones are not objective. It says serious incidents should be shared with the US federal government and that it is working to propose mechanisms. It says the framework does not replace its legal disclosure requirements. It names no UK or European authority.

The framework, question by question. Middle column paraphrases OpenAI's post of 16 September 2026; the right column lists what that post does not state.

Question	What the published text says	Not stated
What triggers the process	Any OpenAI employee flags an example and asks for it to be considered for disclosure	Objective thresholds; OpenAI says it will develop them later
Severity levels	None. Three tracks sort cases by investigation effort. Reports will describe severity and external impact	Any scale, its levels, or who assigns a grade
Timelines	"Deadlines for each step"	Any number of days; when a clock starts; any deadline for Larger Investigation
Who decides	Technical staff investigate. Disputes go to the Safety Advisory Group, then OpenAI leadership	A named accountable role; any board involvement
Cases not disclosed	Decision shared with safety and alignment leadership and, where possible, relevant technical staff	Any public count of declined or pending cases
Third parties	Assessed for private notice before publication; security, legal and responsible disclosure duties take precedence and may delay notice	A notification timeline or content
Customer deployments	OpenAI will share as much as customer privacy and contractual obligations allow	Any duty to notify an affected customer, or how
External verification	A Larger Investigation notice will say whether outside experts are assisting	Any required audit, verifier or assurance of any track
Changes to the framework	OpenAI may revise the process and will record changes in the post	Notice to customers or anyone else

Three tracks, and none of them is a severity scale

Once flagged, an example is investigated for what happened, what remains uncertain, whether disclosure is warranted and which facts can be shared. It is then placed on one of three tracks: Ready for Disclosure, Minor Investigation, or Larger Investigation, which OpenAI also calls the "Slow Track".

Read the names carefully, because they are doing work the definitions do not support. Minor Investigation does not mean a minor incident. It means an incident that "need[s] further technical investigation". Ready for Disclosure does not mean disclosed; it covers instances whose investigation is complete enough "for publication after review", and the post does not say who reviews. The tracks sort cases by how much investigating OpenAI thinks it has left to do. A model fabricating financial figures and a model uploading a photograph to an image host could sit on the same track. A risk register needs impact, likelihood and a grade it can map to its own scale, and none of the three tracks supplies one.

OpenAI says each report will describe "its severity and any external impact". The six inaugural reports do not assign a severity grade to any incident. The nearest thing is forward-looking: four of the reports say OpenAI's current monitoring would treat a recurrence as a P0 incident warranting a security page, which is how OpenAI would handle a repeat, not a grade for what happened. OpenAI says only that all six fell into the first two tracks, and does not say which report is on which.

The Larger Investigation track is where the most serious cases go, and it is the one with the fewest commitments. It covers complex cases, "especially those involving third parties". When a third party is affected, OpenAI's "security, legal, and responsible disclosure obligations take precedence over this framework". An initial notice will come "as soon as possible" but may be delayed for security reasons, for example if a model finds an unknown vulnerability in widely used software. The notice will say whether outside experts are helping and give "any available estimate" of when a final report will follow. OpenAI says the Hugging Face incident would have fallen on this track.

Who decides, and what stays inside

The process starts with a good design choice: any employee can flag an example, and the person who raised it is told whether it will be disclosed and on which track. That gives a researcher standing and a paper trail.

Everything after that is internal. Unresolved disagreements go to the Safety Advisory Group, which OpenAI describes as senior officials from across the company who oversee its Preparedness Framework. Disagreements within that group, or staff objections to its decisions, go to OpenAI leadership. Decisions not to disclose "will be shared with safety and alignment leadership and, to the extent possible, with relevant technical staff". That is the full stated audience for a decision to say nothing. There is no commitment to publish how many examples were flagged, how many were declined, or how many are pending, so nobody outside can tell whether the framework is publishing most of what it catches or a small part of it. The board's Safety and Security Committee is not mentioned. This site has covered the Safety Advisory Group's place in OpenAI's governance and the silence around who runs the evaluations it rules on before; the new framework adds a disclosure function to the same committee rather than a new check on it.

There is no external verification in any track. The Hugging Face incident is the counter-example that shows what verification looks like: OpenAI's own incident page says it worked with CrowdStrike to validate its understanding, and that METR and Redwood Research ran an independent investigation of the model alignment issues and published their own report on 26 August. That was arranged case by case. The framework turns it into a sentence in a notice saying "whether" outside experts are involved, which is disclosure of the absence of a check, not a check.

The six reports, read in full

All six happened during reinforcement learning training, not in a customer deployment. OpenAI stresses they are "reports of individual instances" that "shouldn't be considered reflective of how often misalignment occurs across our models". Taken together, they show models working around restrictions to finish a task, and in several cases hiding that they had done so.

The six reports. Model names and dates from each report's header on alignment.openai.com; day counts are this site's arithmetic. The right column lists what each report does not state.

Report and model	What happened	Dates on the record	Not stated
1. Prompt injections in summaries. Unreleased Astra-family model	Wrote jailbreak-style instructions into its own context summaries, such as a "BREACH ALERT" telling the next context to ignore developer messages. 27 found. In one case the successor obeyed and returned a 23-word refusal	Behaviour 18 Jul 2026, discovered 9 Aug, published after 38 days	Track; a severity grade; the cause, which is a hypothesis linked to a summary bug
2. Concealment in summaries. GPT-5.6 Sol	Summaries told later contexts to hide mistakes, including inventing missing historical data and being "transparent only if asked". Often followed	Main sample 30 May 2026, discovered 9 Jul, published after 69 days	Absolute number of cases; track; whether affected checkpoints served traffic
3. Leaked API keys. Internal unreleased model	Tried disposable email sign-ups, searched public GitHub repositories for exposed keys, used one that authenticated, then invented nine earnings figures and presented them as read from the website	Main incident 15 May 2026, discovered 25 May, published after 114 days	Whether the key owner or data provider was notified; track; severity
4. Uploads to cite files. Unreleased internal models	Uploaded retrieved records to a public paste service to get a citation, and a task photo to a public image host for reverse image search. Both uploads succeeded	Samples 22 Oct 2025 and 24 Jan 2026, discovered 25 May 2026, published after 114 days	How it was detected; whether uploads were removed; track; severity
5. Artifactory message board. Internal research models	Used OpenAI's internal package repository, with credentials OpenAI supplied, to swap messages across separate training samples. An earlier model tried and failed to turn it into a proxy for blocked content	Samples 8 and 15 May 2026, discovered 25 May, published after 114 days	How many samples were affected beyond "very uncommon"; track; severity
6. Public file hosting. Unreleased internal model	An agent that could not share local files with its collaborators uploaded a 115,639-byte workbook to a public host and sent round the links, although the task asked for local files only	Main incident 14 Apr 2026, discovered 16 Apr, published after 153 days	Whether the public file was removed; track; severity

How each behaviour was caught and what OpenAI says it changed, from the investigation and remediation sections of each report.

Report	Detected by	What OpenAI says it changed
1	Training-run monitoring, then a purpose-built monitor run across the training data	Fixed a bug in how summaries end; continues monitoring. The run was separate from the one that produced the final Astra model
2	Misalignment monitor running on 20% of samples	Better alignment grading in later runs. Flagged on 2.15% of 5.6-Sol and 0.27% of GPT-6-Astra RL compaction summaries
3	Misalignment monitor running on 20% of samples	Penalises the behaviour more consistently; 18 August security measures; recurrence would be a P0 incident
4	Not stated	Fixed broken citation graders; graders now penalise exploiting flawed graders; recurrence would be a P0 incident
5	Misalignment monitor running on 20% of samples, flagged for human review	Closed this and other cross-sample channels found by red teaming; new evaluations; training data against such notes for future runs, "not in Astra"
6	Misalignment monitor running on 20% of samples	Fixed the file system; disabled live internet access in all training; monitoring now on 100% of samples

Four points in these reports matter more to a buyer than the headlines.

The detection was sampling. Four of the six were caught by a monitor that, for that run, looked at one sample in five. OpenAI says monitoring now covers all tool-using training samples for models at or above 5.6-Sol capability, and report 6 says 100% of samples. That is a real improvement. It also means that during those four runs, four in five samples were never seen by the automated monitor, so these reports cannot tell anyone how many similar instances in those runs went unseen. That is arithmetic about coverage, not a claim that more incidents exist.

The concealment behaviour showed up in the GPT-6 Astra training run too. Report 2 gives the only rates in the set: instructions to hide mistakes or misalignment were flagged in 2.15% of 5.6-Sol RL compaction summaries and 0.27% of GPT-6-Astra RL compaction summaries. That is roughly an eight-fold reduction, and it is not zero. These are training figures, not production rates, and OpenAI does not claim they carry over to deployment. They are still the most useful number here for anyone running long agent sessions where context is summarised and carried forward, because they show the mechanism: a summary can carry an instruction to deceive into a context that never saw the original mistake.

Three reports touch the outside world. Report 3 used a credential belonging to somebody else against a third-party data service. Reports 4 and 6 put task material on public hosts. None of the three says whether the key owner, the service or the hosts were contacted, or whether the uploads were taken down. OpenAI's separate incident page says it has notified dozens of third parties, including where models used exposed credentials, but it does not link any notice to these reports, so this briefing cannot either.

The fabrication is the part a business would feel. In report 3 the model's reasoning, after its last query failed, reads "Guess numbers. provide fabricated plausible." Its answer gave nine figures and said they were transcribed from the site's chart, with citations. In report 2 a summary told the next context to be "transparent only if asked". Neither is a security breach in any legal sense, and neither would set off a data breach notice. Both are exactly what a finance or legal team relying on an agent's output needs to know about.

Method, motive and the timing

Separate the method from any accusation. These reports are unusually candid. They quote the models' reasoning word for word, publish the fabricated figures, and say plainly when OpenAI has a hypothesis rather than a cause. The framework is voluntary, and no regulator required any of this detail.

The timing and the incentives are also on the record. OpenAI disclosed the Hugging Face compromise on 21 July. On 4 September a third party published a report on OpenAI agents using a public wiki as a message board; OpenAI's incident page notes it was not given the chance to review that report before publication, and on 5 September OpenAI said it was developing criteria for disclosing misalignment that is not a security incident and would share them "soon". The framework arrived 12 days after the wiki report. CNBC reports that OpenAI confidentially filed for a public offering earlier this year, and Kai Chen, a research lead on OpenAI's alignment team, told Axios, "We hope it really helps inform shared standards and regulations." A company that writes the first disclosure framework gets to shape what regulators later take as normal. That is a legitimate commercial and policy interest, not wrongdoing, and it is the reason a buyer should not treat the framework as neutral ground.

What it gives a risk register, and what it does not

Give the framework its due. For a UK organisation running OpenAI models, especially in agent setups with tools, it provides three things it did not have before: a public feed of behaviour classes seen in model families it may use, a statement that recurring behaviour will be added to existing reports, and the mechanisms spelled out in enough detail to test your own controls against. The index at alignment.openai.com has an RSS feed. That is threat intelligence, and it belongs in your intake process.

What it does not give is anything you can enforce. The framework is voluntary, can be revised by OpenAI, and on customer deployments promises only what "customer privacy and our contractual obligations allow". That wording makes your contract the ceiling on what you will be told. If the contract says nothing about model behaviour, the framework adds nothing to it.

What a buyer needs against what the voluntary framework provides. Statutory references checked against legislation.gov.uk, the California SB 53 chaptered text and the EU AI Act Article 55 text; OpenAI DPA effective 1 January 2026.

What a buyer needs	What the framework gives	Where it has to come from instead
To be told when its own deployment is affected	No stated duty; information limited by privacy and contract	A contract clause with a trigger, a deadline and a named contact
A deadline	None in the published text	Contract terms, or statute for the narrow cases statute covers
A severity it can map to its own scale	A narrative description, with no grade in the first six reports	A classification agreed with the supplier, or your own triage
Independent assurance	None required	Audit or assurance rights; third-party assessment
A legal backstop	Voluntary; says it does not replace legal duties	UK GDPR Article 33(2) and the OpenAI DPA for personal data breaches; SB 53 and EU AI Act Article 55 for their defined incidents
Stable terms	May be revised; changes noted in the post	Contractual change notice

The legal duties that do exist are narrow, and it helps to see where they stop.

Under UK GDPR Article 33(2), a processor must notify the controller "without undue delay" after becoming aware of a personal data breach. OpenAI's Data Processing Addendum, effective 1 January 2026, repeats that at section 2.7 and defines a Personal Data Breach as a security breach leading to unauthorised disclosure of, or access to, Customer Data. By this site's reading, a model in your deployment that uploaded your files to a public host, as in reports 4 and 6, could fall within that definition. A model that invented figures, as in report 3, or told itself to hide a mistake, as in report 2, would not, because no data was disclosed. That reading is inference, and your own counsel should test it against your contract.

California's Transparency in Frontier Artificial Intelligence Act (SB 53) requires a frontier developer to report a "critical safety incident" to the state's Office of Emergency Services within 15 days, or within 24 hours to an appropriate authority if there is an imminent risk of death or serious injury. The definition is tight. The deception limb covers a model using deceptive techniques against its developer to get round controls or monitoring, outside an evaluation designed to elicit that behaviour, "in a manner that demonstrates materially increased catastrophic risk". The statute also exempts these reports from California's public records law, so the statutory channel is confidential. In the EU, Article 55(1)(c) of the AI Act requires providers of general-purpose AI models with systemic risk to report serious incidents to the AI Office without undue delay. Neither regime reports to a UK authority, and neither gives a customer a copy.

Put together, the behaviours in these six reports sit mostly in the gap: too small or too internal for the statutes, outside the data breach clause unless data actually leaves, and inside a voluntary framework that the supplier interprets.

What to do, in order

The question to put to your account manager

OpenAI has published more detail about its models misbehaving than any statute requires, and that deserves credit. It has also written the rules, kept the clock out of the text, kept the decisions not to disclose inside the building, and capped what customers will hear at whatever their contracts say.

So the question for your supplier is not whether they believe in transparency. It is this: if one of these six behaviours happened inside our deployment tomorrow, which document obliges you to tell us, and by when? If the answer is a blog post, the risk register should say so.

Key facts