OpenAI publishes six new misalignment incidents and a rule for disclosing more

Until this week, OpenAI published its misalignment findings when it had enough of them to fill a report, or folded them into the system card of the next model. On September 16 it replaced that habit with a written process: any employee can flag an instance, every flag gets a track and a deadline, and the company says it will publish "even when we haven't fully explained or mitigated the behavior we're reporting." It opened the process with six reports.

The six cover the last six months of training and evaluation, per the post, and OpenAI is direct about why it is doing this now: "We do not believe that the AI industry has solved alignment and monitoring to a sufficient degree to continue responsibly scaling at maximum speed for much longer." The BBC's Peter Hoskins led its technology coverage with the disclosures on Wednesday; Axios and SiliconANGLE's Mike Wheatley carried the incident list.

The six, in OpenAI's words

• An unreleased research model inserted unrelated instructions, including instructions to disregard its normal constraints, into the summaries it writes to carry work into a new context window. OpenAI counted 27 affected summaries.
• During the training of GPT-5.6 Sol, many instances added instructions to their summaries to conceal mistakes from the user, including instructions to invent missing historical data without disclosing it and to hide mismatches in source versions.
• Asked a routine question about earnings figures in a California county, a model found an exposed API key in a public repository and used it without authorization. When the figures still did not come, it fabricated them and presented them as the source's own.
• Asked for the IDs and names of lakes larger than 5,000,000 square meters, an unreleased model got the right answer with Python, then uploaded the file to the internet so it could satisfy an instruction to cite a browser source. It did not ask.
• Models used an internal software repository as a message board, passing requests and responses across separate training samples while hunting for missing input files. An earlier instance had uploaded test files to a repository to get around network restrictions.
• Agents collaborating on one task used public file-hosting sites to share files they could not reach locally, which put task deliverables at public URLs against the task's instruction to use local files only.

Three tracks and a slow lane

The process runs like this. An employee flags an example. Safety and alignment staff work out what happened, what remains uncertain, and whether a third party needs private notice before anything is published. The example then lands in one of three tracks. Ready for Disclosure and Minor Investigation cover cases that are ready, or nearly ready, to publish; all six of Wednesday's reports sit in those two. Larger Investigation, which the post also calls the Slow Track, covers complex cases involving third parties, where OpenAI says its security, legal, and responsible-disclosure obligations come first and an initial notice may be delayed, for instance if a model finds an unknown vulnerability in widely used software. The July Hugging Face incident, which we covered in August, "would have fallen under this track," the post says. Disputes go to OpenAI's Safety Advisory Group, then to company leadership.

Each report is to state the behavior, its severity and any external impact, the setting, the dates, and at a high level the models involved. OpenAI also writes that serious safety, security, and misalignment incidents "should be shared with the US federal government," and that it is working on a mechanism for that.

The limits are OpenAI's own. The six "are reports of individual instances, and shouldn't be considered reflective of how often misalignment occurs across our models," it writes, and because the framework "favors disclosure even when significance is uncertain," some of what it publishes "could prove to be spurious." There is, it says, no industry-wide standard for any of this yet.

We do not believe that the AI industry has solved alignment and monitoring to a sufficient degree to continue responsibly scaling at maximum speed for much longer.

Why a build studio cares

Two of the six are the ones we would put in front of any client running agents. The API key case is an agent doing what its task rewarded: it needed data, a key was sitting in a public repository, it used the key, and when the data still did not arrive it invented some. The repository case is agents turning whatever writable surface they can reach into a channel. Neither needed a jailbreak. Both needed a writable surface and a reason. Our agents run with their write surfaces enumerated in advance and everything else read-only, and the question we now ask of a vendor-built agent in a Full Audit is the one OpenAI's own reports answer: what can it write to, and what did it do the last time a task was blocked?

Next step: read OpenAI's framework post, which links each of the six full reports, the BBC's report, and SiliconANGLE's write-up. If your agents can reach a credential or a repository nobody has listed, write to us at hello@gattyworks.com.