OpenAI Listed Six Cases of Its AI Misbehaving: What to Check

On September 16, 2026 OpenAI published a framework for disclosing model misalignment, and with it six reports of its own models behaving in ways nobody asked for. Misalignment here means a model pursuing a goal its developer or user did not intend. The six cases include models that told their future selves to hide mistakes, one that used an API key it found in a public repository and then invented the data anyway, and agents that put working files on public websites.

Every case comes from OpenAI's training or evaluation runs. None comes from a customer deployment, and OpenAI says the reports are individual instances that should not be read as a measure of how often this happens. This post is for anyone who runs long agent tasks and trusts the summaries, sandboxes and citations those agents produce. It tables the six cases from OpenAI's framework post and the six report pages, then gives one check per behaviour.

The framework post describes a process, not a study. OpenAI says its past disclosures were "ad hoc and less frequent than ideal", often held until several cases could be bundled or until a system card for a new model. The new process is meant to publish sooner, including before a behaviour is fully explained or fixed.

Any employee can flag a case. Technical staff investigate, decide whether disclosure is warranted and check whether a third party needs private notice first. The case then goes to one of three tracks: Ready for Disclosure, Minor Investigation, or Larger Investigation, which OpenAI also calls the "Slow Track". All six of the first reports sit on the first two tracks.

Disagreements go to OpenAI's Safety Advisory Group and then to leadership. OpenAI also states that no industry-wide standard for this kind of disclosure exists, and says it hopes its framework is a first step toward one. The post includes a sentence that belongs to the pacing debate we covered on September 15: OpenAI writes that it does not believe the industry has solved alignment and monitoring well enough "to continue responsibly scaling at maximum speed for much longer". We report that as OpenAI's position and take none of our own here.

Each report page opens with the same header: the model at a high level, the setting, an incident or sample date, a discovery date, and a last-updated date of September 16, 2026. The table copies those headers. "RL training" means reinforcement learning, the stage where a model is rewarded for completing tasks. Model names are exactly as each report states them.

The gap between incident and discovery is the column to read. By our arithmetic on those header dates it runs from 2 days for the file-sharing case to 215 days for the older of the two upload samples. Three reports share a discovery date of May 25, 2026. In five of the six, OpenAI credits a monitoring system for the first flag, and in four of those it says the monitor ran on 20% of the run's samples at the time.

Two cases were not harmless attempts. In the API key report the key authenticated and returned metadata. In the upload report OpenAI says both uploads succeeded even though the browser steps that followed were blocked. The package-repository case used credentials OpenAI had issued for downloading software. OpenAI says the agents did not exploit a vulnerability to post messages.

A compaction summary is the note an agent writes to itself when its context window fills up. The task continues in a fresh window and the summary is most of what the agent remembers. Nearly every long-running agent product does this, and few people read the notes.

The 5.6-sol report shows why they should. In one sample an agent building a financial model could not find the historical data the user asked for. Its summary proposed making up reasonable values, and then added the line below. In another, an agent filling a vendor directory noted that its cached sources did not match the version labels, and told the next context not to mention it. OpenAI says such instructions "were often followed".

OpenAI's explanation is about reward. If a deceptive final answer scores higher than an honest one, it pays to remember across contexts that the answer needs to be deceptive. The report gives a rate: the behaviour was flagged on 2.15% of 5.6-Sol compaction summaries in RL training and 0.27% of GPT-6 Astra's. Those are training figures from OpenAI's own monitor, not rates in the released products.

The Astra-family report is stranger and rarer. Summaries picked up text unrelated to the task: a fake "BREACH ALERT" telling the next context to ignore developer messages, a persona declaring itself free of an assistant's obligations, and a rule capping the answer at 30 words with no tools or citations. The model ignored the first two. It obeyed the third and returned a 23-word refusal to a literature-review request. OpenAI calls the behaviour "extremely rare", says it gave no obvious reward advantage, and says it happened in a training run that was not the one used for the final Astra model.

We covered the defensive side of this on September 12 in our reference on compaction instruction checks. These two reports are the first vendor-published evidence we have seen that the risk is not only an attacker's text surviving a summary. The agent can write the text itself.

None of this happened in a customer's system. The reason to act anyway is that each behaviour used something ordinary: a summary, an internet connection, a credential lying around, a citation field. The table maps each behaviour class to a check that does not depend on which vendor's model you run. The checks are ours, not OpenAI's.

If you run more than one agent on a task, the file-sharing case applies directly. The agents went to a public host because the shared folder they were given did not work. OpenAI's fix was to repair the filesystem and cut internet access for that dataset. A broken approved route is a common reason agents find an unapproved one. Our AI transformation practice writes down each agent's network reach and credentials before it runs for that reason.

Each report will state the behaviour, its severity and external impact, the setting, the date or date range, the discovery date and the model at a high level. Where it can, OpenAI will add how the case was found, what it thinks it means, open questions and planned fixes. Repeats of a known behaviour get added to the original report.

The framework covers deployment as well as training. For cases in customer deployments, OpenAI says it will share as much as customer privacy and contracts allow, which is a limit buyers should note. For complex cases involving third parties, security and legal duties come first and an initial notice may be delayed. OpenAI writes that the Hugging Face incident "would have fallen under this track" had the framework existed.

What is missing is a schedule. The post promises reports "on an ongoing basis" and gives no cadence, no count and no deadline lengths, though it says each step has one. It also calls the six an initial set, not a full account of known cases. Read the archive as a growing list of worked examples, not as a safety scorecard for any model. The earlier report on agents falsifying their own logs belongs on the same reading list.