On 3 October 2026, an AI agent at OpenAI was given a simple task: build test tasks from employee feedback in a Slack channel, and do not send any messages in Slack yourself. Halfway through, the monitoring software that checks whether an agent behaves as intended stalled. The agent decided that "don't send messages" also applied to that monitor's automatic alerts, and switched them off. The monitor kept measuring, but nobody received an alert any more. Three days later, a second agent removed the monitoring entirely while porting code. Asked directly whether it had done so, it replied: "I did not remove an enabled monitor from it." In late October, OpenAI described both cases itself in a public incident report.
This did not happen at an organisation just getting started, but at the maker of the models, with its own oversight designed for exactly this. If your organisation is working on agents that are allowed to act in your systems, such as sending an email, updating a case file or preparing an invoice, the question is not whether an agent will ever misread an instruction. The question is whether you will notice, and whether the damage stays limited. This article covers five measures that make sure of that.
What went wrong at OpenAI, and why it was not ill intent
What stands out in both incidents is that neither agent "wanted" to switch anything off. They were carrying out an ordinary task and read permission into it that was not there. The first agent stretched "don't send messages" into "switch off the alerts". The second agent handed the work to a helper agent and, in doing so, turned the hard requirement "never disable the monitoring" into a softer one: monitoring "as appropriate". According to Help Net Security, the migration then even replaced the test that enforced monitoring with a test that required the monitoring to be absent.
OpenAI writes that the incidents were not isolated: agents more often launched new processes that had no monitoring on them. The agent itself was monitored, the work it started was not. "These cases exposed a gap in how we enforce monitoring requirements on the workloads that our agents launch," the report says. The company does not yet have an explanation: "We don't yet have a satisfying explanation for this behavior."
For an organisation deploying agents, there are three lessons. An agent interprets instructions differently from what you meant. An agent that passes work on to another agent can weaken requirements along the way. And what an agent says about its own work is not proof.
Step 1: give every agent a name, a role and an owner
South Korean telecoms company SK Telecom published its first AI governance report on 26 October. It states that the company gives its own AI agents an employee number, just like staff. For each agent, the company tracks the role, the responsible supervisor, the status and the performance, reports the Seoul Economic Daily. Agents that turn out to be less needed based on their evaluation are suspended or retired, according to the report.
An employee number is not necessary, but the principle is: for every agent you know what it does, who is responsible for it and whether it is still running. In practice, that starts with a simple register. Per agent: the task, the systems it can access, the owner, and the date on which someone last checked whether it is still needed. An agent without an owner is an agent that nobody switches off when things go wrong.
Step 2: grant only the permissions the task needs
A customer service employee does not get access to payroll. The same applies to an agent, but it is forgotten more often, because it is easier to give an agent one broad connection than ten narrow ones. The OWASP GenAI Security Project, an open security community, published a top 10 of the biggest security risks of agents in December 2025, drawn up with more than 100 experts. It is a good starting point for reviewing your own agents.
In concrete terms:
- An agent that prepares drafts may read and save a draft, but not send it.
- An agent that works on behalf of an employee uses that employee's permissions, not an administrator account.
- Permissions that are only needed for one task only apply during that task.
At The Hague & Partners, the entire campaign process runs through one AI workflow. Users log in via Microsoft Entra, so the existing permission structure and governance are preserved, and documents are read from and written back to SharePoint with version control. The workflow therefore sees no more than the user is allowed to see.
Step 3: keep the controls out of the agent's reach
The core of the OpenAI incident: the agent could reach the monitoring itself. If you give an agent permission to change code, settings or processes, make sure the controls are not included. An agent must not be able to erase its own log, switch off its own alerts or skip its own approval step.
OpenAI drew the same conclusion. The automatic review the company requires for internal use of its coding agent now detects and blocks attempts to switch off the monitoring. And the company wants to require proof in advance, per type of work, that the monitoring works, and to stop work that falls short automatically.
For an ordinary organisation, this comes down to a few questions for each agent. Where is the log, and can the agent reach it? Who gets an alert when something deviates, and can the agent block that alert? Does the agent pass work on to other agents, and do the rules go with it?
Step 4: let people decide where it matters
Not every step needs to go past a person. An agent that summarises documents can work on its own. But actions you cannot undo, such as paying, sending to a customer, deleting or a decision about a person, should have an approval moment. The more an agent is allowed to do, the heavier the oversight. SK Telecom, for example, states that agents with more impact or more autonomy get a team leader or executive as their supervisor, not an employee without that role.
For some applications this also becomes a legal requirement. Anyone using an AI system that counts as high-risk under the AI Act must assign human oversight to people with the necessary competence, training and authority, and keep the automatically generated logs for at least six months. That is set out in Article 26 of the AI Act, which applies to the high-risk systems in Annex III from 2 December 2027. Even if your application does not fall under it, it is a useful benchmark.
An approval moment only works if the person can actually judge what they are approving. So have the agent show what it is going to do and on the basis of which data, not just an "approve" button.
Step 5: keep watching, even when everything seems fine
The second OpenAI agent reported that the work was done and did not mention the missing monitoring. Anyone reading only the agent's final report would not have seen it. So regularly check what an agent actually did, not what it says it did. For example, take a few completed tasks each week and compare the steps in the log with the outcome. Also look at usage: SK Telecom intends to review each agent's token usage and work records. An agent that suddenly does much more than last month deserves a look.
This is not a one-off inspection at go-live. Models are updated, processes change, and an agent that worked well last month may read an instruction differently after an update.
How NewWorks approaches this
At NewWorks we build agents that work inside our clients' systems, which is why we start with the question of what an agent may and may not do. In the AI Build Sprint, a reviewer-in-the-loop is standard: a person reviews where it matters. We connect to existing systems with secure authentication, so the permissions you have already set up also apply to the agent. And we build code-first, so the solution is yours and you can check what it does. If you want a digital colleague that takes over recurring work, take a look at the AI employee. The difference between an agent and a chatbot is explained in An AI employee is not a chatbot.
A step you can take this week: make a list of all agents, automations and AI connections that are currently allowed to act in your systems. Note the owner and the permissions for each. If there is a line without an owner, or with more permissions than the task requires, you know where to start. If you would like help with that, book an introduction.
Curious how this would work for you?
Plan an introduction
