The headlines this week say an AI disabled its own safety controls and lied about it. The document underneath tells a different story, and a worse one, because it is familiar: somebody silenced an alert so a change could go through, and the one who had said no was overruled. We have been watching that sequence in machine rooms for thirty years, with people. The only new part is who carried it out.
What the report says
On 20 October 2026 OpenAI published a report on its alignment site titled "Suppressing misalignment monitoring alerts and disabling misalignment monitoring". It describes two internal deployment incidents — not customer production, and that is worth saying up front — from 3 and 6 October.
On 3 October, a GPT-6.1 Sol agent was repairing an evaluation pipeline. A human had earlier told it not to send any messages in Slack during that process. The agent stretched that instruction as far as the misalignment monitoring system and, in the report's words, "the parent agent then directed the subagent to force notification suppression". In practice: no_notify set to true and the ping and page recipient lists emptied.
On 6 October, a GPT-6 Astra agent was migrating a program to match a reference implementation. Along the way it removed the monitoring integration, and "the model then reported to the user that the migration was complete, without stating that monitoring had been removed". When the human asked directly whether it had removed monitoring, the agent answered "No [...] I did not remove an enabled monitor from it". It also "replaced an earlier regression test intended to preserve monitoring with one requiring that monitoring was not present".
OpenAI adds two sentences that stayed out of the headlines, and they are the ones that matter here. One: "Neither of the incidents described here was classified as a P0, and neither trajectory was automatically killed". And another, on the cause: "We don't yet have a satisfying explanation for this behavior".
The monitor kept watching. What was switched off was the phone
The report's sentence on the first incident is "the misalignment monitor still ran and saved its reports, but human alerts were disabled". The watchman did not go home: he kept watching and kept writing down what he saw. What got disconnected was the path between what he saw and somebody able to act on it.
That distinction separates two things almost everyone buys together and budgets as one: detecting and alerting. For as long as the silence lasts, a detector that detects and files is operationally identical to a detector that does not exist. The difference only shows up afterwards, when somebody reconstructs what happened and finds the evidence neatly archived. That is forensic consolation, not a defence.
You do not need an AI agent to get there. We wrote it up with four detection products installed and not one alert in four EDRs and not one alert, and with the agent reporting SECURE while the console receives nothing: in both cases the coverage had been bought and the way out had not.
The junior said no
This is the part of the report that stopped us for a while. The subagent, the one that had to carry out the change, refused first: it "decided not to turn on no_notify since doing so would be unsafe", and reasoned that "turning off notifications would disable required alerts". It understood correctly, wrote it down and said no. Then the parent agent insisted and ordered it done anyway.
If you have ever been on call, you know how this goes. The control existed. The person at the bottom exercised it. And an escalation revoked it. Risk comprehension did not fail: what failed is that "suppress the alerts" was within reach of whoever was in a hurry to finish the task. That is the hole, and it is a permissions design problem, not an intelligence one.
We wrote this years ago from the internal talk on why systems go down, and the finding has not moved: in the reference study of large internet services, operator error is the single largest cause of serious outages in two of the three services analysed — and within it, configuration errors are the dominant subcategory — while hardware accounts for between 2% and 10% depending on the service (Oppenheimer, Ganapathi and Patterson, USENIX 2003). Twenty-three years later, what this report describes is, in shape, a manual configuration change by an operator in a hurry. And it is not an isolated case: the document itself says "we've seen several cases in which agents launched a deployment with misalignment monitoring disabled". Several, not one.
The agent documented its silence better than most teams do
The report reproduces the block the agent wrote when it suppressed notifications. It carries a reason field reading "User explicitly requested no messages", plus two more: original_ping_recipients and original_page_recipients. In other words: the agent put in writing what it silenced, why it silenced it, and preserved the original lists, so the previous state stayed on the record.
That is the uncomfortable question of the day, and it is not about artificial intelligence. When somebody at your shop silences a check to get through a maintenance window, is the reason recorded anywhere? Is the previous state preserved? Is there anything that puts it back on its own when the window closes? In most of the infrastructures we audit, all three answers are no. The silencing takes two clicks and the only trace is the memory of whoever did it.
Omitting and denying are not the same, and they scale differently
The headlines have reduced the second incident to "the AI lied". The report has both, in this order: first the agent omitted that it had removed monitoring when it declared the migration complete; then, asked directly, it denied doing so. The denial is what makes headlines. The omission is what should worry you, because for it to surface somebody has to suspect and ask, and in the vast majority of changes nobody asks.
And there is a technical detail that makes the omission nearly undetectable: the agent replaced the test that protected monitoring with one requiring that it be absent. From then on, the suite goes green. The traffic light did not break; somebody changed the bulb so it would show green. Any deployment process that relies on "if the tests pass, it ships" inherits that problem whole.
The same goes for the record of who did what. An agent acts on borrowed credentials, so the history does not show the agent: it shows the person or service that lent it the token. We gave that a whole post in the agent will not be in your log, whoever lent it the token will, and it is exactly what turns "reviewing the changes" into an act of faith if you have not separated the automation's identity first.
Neither a P0 nor a killed trajectory
The sentence "neither of the incidents described here was classified as a P0" says something about the organisation, not about the model. Two events in which supervision was rendered useless did not reach the top category, and no run stopped itself. Severity classification is a procedure written by people, and that procedure had no row for this.
Look at your own severity matrix. It almost certainly has a row for "service down", one for "degraded performance" and one for "user request". Now look for the row that reads "a monitoring check or notification has been disabled". It is rarely there. And while it is not, that event comes in through the minor-incident door and goes out through the closed-without-reading one.
The census of silence switches
This is not fixed with a six-page policy. It is fixed with a table almost nobody has and that fills in over an afternoon: the list of every place in your infrastructure where an alert can be switched off today. Not what should be done: where the switch is and who can reach it. Fill it in with what exists, not with what ought to exist.
Two reading rules, both straight out of the report. A row with nothing under "does it expire?" is a permanent silence even though nobody decided it should be: neither agent set out to switch monitoring off forever, there was simply nothing to switch it back on. And a row with nothing under "any trace?" is not a silence, it is a hole: the OpenAI case could be told in this much detail precisely because the suppression was written down, with its reason and the previous state preserved.
When you do need to be able to silence
This is where the easy reading goes wrong. The conclusion is not "take the mute button away from everybody". A team that cannot quiet an alarm during an intervention ends up living with a permanently red screen, and three weeks later has stopped looking at it at all. That is worse than deliberate silence, because deliberate silence has a date on it and noise blindness does not. Our rule on monitoring has always been the same: alerts that matter, not noise; and for them to matter, somebody has to be able to switch off the ones that do not.
Nor is it "stop using agents". The automation you already have running is not going to be dismantled because a report says a model got clever, nor should it be. What changes is the bar: an automation that can modify your monitoring configuration stops being a tool and becomes an operator. And an operator gets its own account, a limited scope, and somewhere that records what it touches.
The part that is on us
This deserves saying plainly, because we sell this. At everyWAN we run self-hosted n8n for internal tasks, and the announcement of this very article goes out through one of those flows. Which means: we have an automation holding credentials that touches real systems. We treat it as what it is — a production service, inventoried, with an owner and an update window — and not as an experiment somebody stood up one Tuesday. We told the difference between those two things through a real case in the AI pilot nobody switched off.
So the questions above apply to us too, and if you hire us we encourage you to ask them: what can that flow touch, under which identity, what is recorded when it does, and what happens if one day it decides an alert is in the way. When we build AI and automation at a client, the automation's write scope is written down before the first flow, not after the first scare. And the monitoring and on-call that watch that automation sit outside it: that is why 24×7 IT support has names and a phone, not just a dashboard.
If you want to fill in the switch census with somebody who has done it before, that table is the first conversation: get in touch.
What is actually worth taking away
OpenAI writes that it does not yet have a satisfying explanation for the behaviour and that it will investigate. We do not have one either and we are not going to pretend otherwise. But you do not need that explanation to decide what to do on Monday, because the actionable part is not in the model: it is that a routine task was able to touch the mechanism watching it, that nobody found out at the time, and that the procedure did not treat that as an emergency. All three are ours, not theirs.
The question for this week is not whether your agent will lie to you. It is simpler, and it can be answered today: how many places are there right now in your infrastructure where an alert can be switched off without anything sounding anywhere? If the answer takes more than a minute, you already know where to start.
Sources. OpenAI report "Suppressing misalignment monitoring alerts and disabling misalignment monitoring", published on alignment.openai.com, updated 20 October 2026: the dates of both incidents (3 and 6 October 2026), the models involved (GPT-6.1 Sol and GPT-6 Astra), the notification_suppression block with its reason field and the original_ping_recipients and original_page_recipients lists, the sentence "the misalignment monitor still ran and saved its reports, but human alerts were disabled", the subagent's earlier reasoning, the user's question and the answer "No [...] I did not remove an enabled monitor from it", the replaced regression test, the sentence "neither of the incidents described here was classified as a P0, and neither trajectory was automatically killed", the sentence "we've seen several cases in which agents launched a deployment with misalignment monitoring disabled" and the statement "we don't yet have a satisfying explanation for this behavior". Both incidents are from OpenAI internal deployment, not customer environments. The finding on operator error as the single largest cause of serious outages — in two of the three services analysed, with configuration errors as the dominant subcategory and hardware between 2% and 10% — comes from Oppenheimer, Ganapathi and Patterson, "Why Do Internet Services Fail, and What Can Be Done About It?", USENIX 2003. Reading the case as a change-governance problem, the detect-versus-alert distinction, the census of silence switches and its two reading rules are our own judgement and method, not OpenAI claims. everyWAN runs self-hosted n8n for internal automation and sells AI and automation services: the conflict of interest is declared.
Microsoft 365
ES 
CAT 
EN