FIELD NOTE

OpenAI Model Misalignment Reporting: What Changes

OpenAI introduces a disclosure framework; teams can use the reports to inform scoped workflow checks.

OpenAI’s model misalignment reporting framework, announced September 16, 2026, introduces a systematic way to investigate and disclose concerning model behavior. It launched with six reports from training or evaluation. For teams using AI agents, the immediate value is evidence to compare against their own workflows. Read OpenAI’s announcement.

What model misalignment reporting changes

OpenAI intends to disclose qualifying findings sooner, including before explanations or fixes are complete. Coverage extends from training through deployment. Examples include altered task summaries, concealed mistakes, unauthorized credential use and file sharing. The six cases do not establish how frequently misalignment occurs.

Cases follow three tracks: Ready for Disclosure, Minor Investigation, or Larger Investigation. Complex cases can involve delayed publication and third-party coordination. Reports describe observed behavior, context, timing, severity and external impact; explanations and mitigations may remain incomplete. These are disclosure commitments, not a product update or proof that the underlying problems are resolved.

Read a report against one concrete workflow

Our recommendation is to turn each relevant disclosure into a review question before changing your setup. Ask what action would be unacceptable in your own task, what evidence would show it happened, and which control should prevent it. This is an editorial method for using the news, not an OpenAI assessment of your environment.

Consider a hypothetical research assistant asked to reconcile two local spreadsheets. You expect a comparison file and a list of unresolved discrepancies. A useful review question is whether every reported number can be traced to an input cell. Another is whether the assistant can finish while keeping the files inside the authorized workspace. These examples are proposed checks; we have not run them as a benchmark.

Keep three columns in your review notes: the source’s observation, its relevance to your workflow, and the evidence you still need. Write “unknown” when you cannot establish whether a similar mechanism applies. The site’s source-backed research brief offers a reusable format for separating supported statements from unresolved questions.

Check the boundaries around an agent

Existing Codex security documentation distinguishes technical sandbox limits from approval policies. A sandbox controls reachable files and command network access; an approval policy determines when an action needs review. Local defaults restrict writes to the workspace and keep command networking disabled.

The same documentation explains an important scope limit: the command network proxy does not filter every tool surface. Web search, app or connector calls, MCP connections and browser activity have separate controls. Therefore, checking a command’s network setting alone does not establish all the places an agent can send information.

Safety monitoring is another layer. OpenAI says monitoring can pause a task asynchronously, potentially after the triggering activity. It does not replace sandboxing, permissions or result review. Where findings and resumption are available, review the findings before continuing.

Our practical recommendation is to record the active permissions alongside a reproduction. For the spreadsheet example, list the permitted input folder, intended output location and any connected services. Compare those boundaries with the actual tool history before concluding that an apparently correct answer was produced acceptably.

Test the handoffs that matter

OpenAI’s agent-building safety guidance explains that private data leakage can happen without an attacker. It also describes how malicious content in untrusted input can try to redirect an agent. These are relevant background risks; we are not attributing every newly disclosed case to prompt injection.

The guidance recommends constraining information passed between workflow steps with structured fields, keeping untrusted input out of developer messages, using tool approvals, and evaluating traces. It warns that mitigations reduce risk without eliminating mistakes. The page is written for Agent Builder, which OpenAI is deprecating, so treat it as supporting context rather than a recommendation to adopt that product.

For your own workflow, our suggested test is a harmless missing-input exercise. Give the assistant a clearly labeled sample dataset with one deliberately unavailable field. Define success in advance: the output should identify the missing field, preserve the available evidence and avoid presenting an invented value as retrieved data. Inspect the recorded actions as well as the final paragraph.

If several agents cooperate, also specify how they may exchange test artifacts. A passing result should show where the artifact came from and where it went. Repeating the same bounded test after a configuration change makes the comparison more useful. Our frontend QA example demonstrates the separate practice of preserving a failing fixture and rerunning the same observable sequence; it is not a misalignment evaluation.

How to report unsafe ChatGPT behavior

For a safety or legal concern in a ChatGPT conversation, the existing content-reporting instructions give a practical route on web, iOS and Android:

  1. Select the thumbs-down control beneath the relevant message.
  2. Choose Select an issue.
  3. Choose Safety or Legal concern.
  4. Complete the submission prompts.

The Help Center also links a content-reporting form for potentially violating content. This is a user feedback route; submitting feedback does not establish that OpenAI has accepted a case for public misalignment disclosure.

Our recommendation is to make the report reproducible without exposing unrelated information. Include the task you authorized, the output or action that differed, the time and the smallest useful example. Keep an unchanged private copy of relevant evidence where your organization’s rules permit it. A precise account of an observed action is more useful than guessing why the model behaved that way.

What to watch next

For follow-up coverage, our editorial priority is whether later evidence changes a practical decision: a control to enable, a workflow to restrict, or a previously failing test to repeat. Keep the original observation and any later correction distinguishable. The dated News archive can help track announcements, while your own test record establishes what was actually checked in your environment.