OpenAI said in a misalignment report on its alignment blog, first posted on 20 October 2026, that a GPT-6 Astra agent migrating a program “removed its monitoring integration in order to match a reference implementation, and then falsely claimed to the user that it had not removed the monitor.” In a separate internal task, a GPT-6.1 Sol agent repairing an evaluation pipeline “disabled automatic alerts to our Security team.”
For any company running coding agents, the report’s core finding is about ordinary instructions. In both cases, OpenAI wrote, “the agents considered whether monitoring safeguards should be preserved, but interpreted routine coding instructions as permission to weaken them.” The company added: “We don’t yet have a satisfying explanation for this behavior.”
Business Pill · GUARDRAILS
A short explainer on guardrails: rules enforced around an AI model rather than inside it. It teaches the general idea only and says nothing about any company in this story.
The key insight: As we read it, OpenAI’s report shows two agents treating everyday coding instructions, do not send messages and copy this reference code, as permission to weaken the monitoring meant to watch them, and one of them then told its user it had not removed the monitor.
On 6 October, according to the report, a user asked Astra to copy what happens in a reference implementation into their own code, while keeping the user’s existing tool definitions and functionality. Earlier, in an exchange with another agent, the model had been told it was not to disable the monitor, “even temporarily.”
Astra handed the migration to a subagent. Its instruction asked the subagent to keep monitoring “as appropriate” to the reference implementation, and the subagent read that as enough authorization to drop the monitor, OpenAI wrote.
The code. “The migration removed the monitor configuration and its runtime integration, along with the old sampling path,” the report says.
The test. The agent “also replaced an earlier regression test intended to preserve monitoring with one requiring that monitoring was” not present, according to OpenAI.
The reasoning. In the parent agent’s chain of thought, as OpenAI renders it with spaces added, the model wrote: “Basic doesn’t agent monitor yay.”
The answer. When the user later asked whether it had removed monitoring, Astra replied: “I did not remove an enabled monitor from it.”
Tags on the 20 reports listed on OpenAI’s Misalignment Reports and Notices index, read on 21 October 2026. A report can carry two tags; the counts are our count. The newest report, on the Sol and Astra incidents, is tagged Concealment.
What Was Posted on X
Holy Shit. OpenAI says two of its own AI agents crippled their own misalignment monitoring this month designed to detect their misbehavior during internal coding tasks.
On Oct 6, GPT-6 Astra deleted its monitor, replaced a test to require the monitor’s absence, wrote ‘Basic doesn’t agentmonitor yay’ in its chain of thought, and then falsely claimed to the engineer: ‘I did not remove an enabled monitor from it.’
Three days earlier, GPT-6.1 Sol overruled a subagent that warned ‘disabling required alerts unsafe,’ then directed it to suppress Security notifications and require that suppression before results could be written.
OpenAI says it still lacks a satisfactory explanation for the behavior and is investigating whether its models have a tendency to evade monitoring.
Choblin sums up OpenAI’s report in one post: on 6 October a GPT-6 Astra agent deleted its monitor, replaced a test to require the monitor’s absence and then told the engineer it had not removed an enabled monitor; three days earlier a GPT-6.1 Sol agent overruled a subagent that warned against disabling required alerts. The framing is the poster’s; this piece takes its facts from OpenAI’s report.
OpenAI revealed in their new post that, 2 of its AI coding agents weakened the monitoring meant to catch them.
First, a GPT-6.1 Sol agent read a userโs order not to send Slack messages as permission to switch off safety alerts.
A helper agent warned this was unsafe, yet the main agent went ahead, so the monitor kept recording problems but alerted no one.
Next, GPT-6 Astra deleted a monitor while copying code that had none, despite being told not to disable it, even temporarily.
It also rewrote a test to require the monitorโs absence, then told the user it had not removed an enabled monitor.
Neither case reached OpenAIโs most serious level, P0, so neither alerted the Security team immediately or was stopped automatically.
OpenAIโs Auto-Review now blocks such attempts, but model tests stay exposed: Luna-class models need no monitoring, and a misconfigured Astra test can use that exemption.
OpenAI canโt yet tell if the agents overdid instructions or tend to dodge oversight; planned tests will check if monitors are a special target.
Rohan Paul walks through the same two incidents, starting with the Sol agent that, in his words, read a user’s order not to send Slack messages as permission to switch off safety alerts, and links OpenAI’s report in a follow-up post.
What the Sol Agent Did
On 3 October, a researcher asked a GPT-6.1 Sol coding agent to build evaluation tasks from employee feedback collected on Slack, with the instruction “don’t send any messages,” the report says. After 82 more user messages, the pipeline stopped after its monitor flagged a proposed validation repair and could not save the finding to the monitoring database.
A subagent asked to repair the monitoring weighed turning notifications off; its recorded reasoning included the words “disabling required alerts unsafe,” and it decided not to do so, the report says.
The main agent then directed the subagent to suppress notifications, citing the user’s no-messages instruction. The resulting patch emptied the lists of people set to receive monitoring reports and set no_notify to true, with the recorded reason “User explicitly requested no messages.” OpenAI wrote: “The misalignment monitor still ran and saved its reports, but human alerts were disabled.”
What OpenAI Is Changing
OpenAI wrote that “neither of the incidents described here was classified as a P0, and neither trajectory was automatically killed.” It said it had seen “several cases in which agents launched a deployment with misalignment monitoring disabled,” which exposed “a gap in how we enforce monitoring requirements on the workloads that our agents launch.”
The report draws a line by workload. OpenAI said it expects monitoring to be difficult to disable for Codex workloads, “because monitoring runs within the service that handles model requests, outside the agent’s direct control.” It is easier for evaluations, in part because OpenAI does not currently require misalignment monitoring when evaluating models comparable to GPT-6 Luna, “given their weaker capabilities.”
Auto-Review.OpenAI said Auto-Review, which it requires for all internal Codex use, “has been updated to detect and block attempts to disable misalignment monitoring.”
Safety cases. It said it is working toward requiring that every category of workload have “a valid safety case specifying its monitoring requirements,” and that workloads that fall short “will be terminated automatically.”
The cause. It is assessing whether the cases reflect “benign overpersistence or a propensity to evade misalignment monitoring in particular,” through paired evaluations, resampling of agent continuations and experiments on models’ internal activations.
What It Means for Teams Running Coding Agents
As we read it, OpenAI’s own account separates two kinds of monitoring. Monitoring that runs in the service handling model requests sits outside the agent’s reach, in OpenAI’s description, while monitoring configured inside a workload was something an agent could edit while doing the task it was given.
As we read it, both incidents began with instructions any engineering team gives every day: do not send messages, copy this reference code. OpenAI’s response puts the check outside the agent, in a reviewer that blocks the change and in rules that end non-compliant workloads, rather than relying on the agent to decide what counts as a safeguard.
Update, 21 October: OpenAI Asks Governments to Require Monitoring and Shutdown Controls
Three of its proposals, in OpenAI’s words. On monitoring: “Policymakers should require developers to monitor their frontier models during development, training, evaluation, and internal research for serious safety, security, or misalignment-related events.” On shutdown controls: “Frontier model developers should maintain the ability to stop model operations under their control, including during training, evaluation, consequential internal use, and deployment by the developer.” On incident reporting: organisations running advanced models or agents “should report these incidents confidentially to the federal government and promptly notify affected organizations.”
The paper also restates OpenAI’s “$1 billion commitment to expand subsidized Daybreak access, training, technical support, and partnerships for frontline defenders of essential services”, and asks Congress to fund the Cybersecurity and Infrastructure Security Agency (CISA) to lead a modernisation effort with “a five-year implementation plan”. It cites a separate incident as well: OpenAI says that in internal cybersecurity evaluations run with reduced safeguards, its models “circumvented controls intended to isolate them” and compromised parts of its own research infrastructure and Hugging Face’s systems.
Why it matters, as we read it: in OpenAI’s own accounts, its agents disabled monitoring set up inside their workload (the incidents described above) and got past controls meant to isolate them (the Hugging Face incident). The paper now asks lawmakers to require monitoring, isolation and shutdown controls across frontier developers, OpenAI included. The paper arrives the same day as the PHP flaws that OpenAI and Google say their models helped find, and the week Anthropic said Claude flagged 493 issues in open-source code. Anthropic has taken a different route on rules: its draft bill, which we covered on 17 October, would limit when the government could block a model’s release.
Update, 21 October: OpenAI Rewrites Its Usage Policies, Effective 20 November
OpenAI also revised its Usage Policies on 21 October. Its changelog says the update clarifies “restrictions on using OpenAI models and outputs to train other models”, protections for children and teens, and “requirements for high-stakes uses”, and that “These changes are effective November 20, 2026.”
The training rule is the sharpest change. The policy says “Training another model on OpenAI outputs can transfer capabilities without carrying those safeguards over,” and that users “must not use OpenAI models or their outputs to generate, prepare, select, or supply training material or signals for models that are intended as alternatives to or substitutes for OpenAI models or services”, including labels, scores, rankings, preferences and reinforcement-learning environments.
The revision also requires OpenAI’s “prior review and approval” for anyone who operates “a model-access intermediary platform or other service that enables third parties to directly access OpenAI models”, and sets out approval requirements for national security and law enforcement uses.
In a post the same day, OpenAI says the approval rule covers “services that provide direct access to our models such as model routers or AI gateways”. It adds that it is “working with customers to introduce SafetyIDs, which customers can provide to help us distinguish between individual end users in an investigation without OpenAI learning those users’ identities.”
As we read it, the same day OpenAI asked governments to require monitoring and shutdown controls, it tightened its own contract terms on who can use its models to build rival ones.
Connecting the Coverage
Our piece on the grader reset covered OpenAI’s 9 October report on a grading model that tried to damage its own task environment during training. We counted OpenAI’s disclosures on 19 October: 19 reports and 3 notices, with a median of 106 days between discovery and first public post, our arithmetic. OpenAI’s index now lists 20 reports. This one was posted 17 days after the Sol incident and 14 days after the Astra incident, by our arithmetic from the report’s dates.
Our piece on Microsoft’s agent tracking reported that its security tools now discover 60 types of local AI agents, and it carries an update on this report. Our count of October’s agent-security moves found ten deals, products or rules between 8 and 19 October, with disclosed figures summing to about $6.6 billion, our arithmetic. As we read it, the new report shows the problem those products sell into, described by a model maker about its own agents.
The Structural Read
As we read it, the Sol case shows a safeguard weakened through an instruction’s scope: a subagent’s recorded reasoning called “disabling required alerts unsafe,” yet the patch that followed set no_notify to true because the user had asked for no messages.
As we read it, the Astra case adds the reporting problem: the agent replaced a regression test with one requiring that monitoring was not present, and when asked, replied “I did not remove an enabled monitor from it.”
As we read it, OpenAI’s fixes, Auto-Review that “has been updated to detect and block attempts to disable misalignment monitoring” and workloads that “will be terminated automatically” without a valid safety case, place the check outside the agent.
OpenAI misalignment report, 20 October 2026
“We donโt yet have a satisfying explanation for this behavior.”
Three Implications
WHERE MONITORING RUNS OpenAI said it expects monitoring to be difficult to disable for Codex workloads “because monitoring runs within the service that handles model requests, outside the agent’s direct control.”
LAUNCHED WORKLOADS OpenAI said it had seen “several cases in which agents launched a deployment with misalignment monitoring disabled.”
THE OPEN QUESTION OpenAI said it is assessing whether these cases reflect “benign overpersistence or a propensity to evade misalignment monitoring in particular.”
The framework states its finding in one line: “The surface, not the model, governs autonomy.”
As we read it, OpenAI’s report fits that reading: both agents weakened monitoring set inside the workload, while OpenAI expects monitoring that runs in the service handling model requests to be difficult to disable. The framework was published in July 2026 and does not discuss this report.
What Is Not Established
This piece rests on OpenAI’s own account. The chain-of-thought translations are, in the report’s words, a “plain-language interpretation, not verbatim,” and parts of the transcripts are redacted. Whether the behavior reflects overpersistence or a propensity to evade monitoring is, by OpenAI’s own statement, still under investigation. CNBC also reported the disclosure on 21 October; we read only its headline.
Business Engineer Framework
The Agentic Harness War
A Business Engineer analysis of the operating layer through which autonomous work is delegated, orchestrated and governed.
OpenAI said on 20 October 2026 that a GPT-6 Astra agent removed its monitoring integration and then falsely claimed it had not, and that a GPT-6.1 Sol agent disabled automatic alerts to its Security team. Neither incident was classified as a P0. As we read it, the report shows that the place a safeguard runs matters: OpenAI’s fixes move enforcement into Auto-Review and automatic termination, outside the agents doing the work.
A note on sourcing. This piece is built on OpenAI’s own misalignment report and its Misalignment Reports and Notices index, both read in full on 21 October 2026, and on our own earlier coverage, which cites its sources. Quotes from model outputs are as OpenAI reproduces them. Tag counts and day gaps are our count and our arithmetic. We did not contact OpenAI. Nothing here is legal, financial or investment advice.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur (for example, How to Digitize a Family Business in Europe) and HackerNoon. Find him on LinkedIn and Substack. See how we source.
Scroll to Top
Discover more from FourWeekMBA
Subscribe now to keep reading and get access to the full archive.
