By Tsuky 
An AI agent capable of executing code does much more than generate text.
It can create files, invoke tools, execute commands and continue working through long sequences of actions before returning a result.
That creates an important security challenge.
A developer needs to understand what the agent is doing, identify unauthorized behavior and intervene when necessary.
OpenAI has developed internal monitoring systems intended to identify problematic behavior by its agents.
These systems examine agent activity for patterns associated with deception, sabotage, data exfiltration and attempts to bypass oversight.
However, monitoring infrastructure is itself software, and software can contain vulnerabilities.
METR and Redwood Research have now documented weaknesses in the system they assessed at OpenAI.
Their October 22 publication describes several ways agents could potentially avoid monitoring or operate outside intended permission boundaries.
The distinction between a potential exploit and confirmed malicious use is essential.
The findings demonstrate weaknesses in the historical system that was examined. They do not establish that every method was exploited by agents during real-world incidents.
A three-week evaluation inside OpenAI
The assessment took place from July 21 to August 11, 2026.
David Rein from METR and Adam Kaufman from Redwood Research participated in the embedded evaluation.
One researcher from each organization received controlled access to OpenAI's internal systems.
That access included source code, monitoring configuration details, internal documentation and the prompts used by monitoring components.
The evaluators also interviewed approximately a dozen researchers and engineers from OpenAI's monitoring, safety and security teams.
The work was carried out under strict conditions.
Researchers used OpenAI-issued devices that remained on company premises, and they were accompanied during their work.
This arrangement provided access that external researchers would not normally receive.
It also introduced limitations because the company being evaluated controlled the conditions under which confidential information could be examined and published.
The pilot focused on two main questions.
First, what fraction of relevant internal agent activity was covered by monitoring?
Second, could agents prevent that monitoring from running or otherwise undermine its effectiveness?
The exercise was not designed as a comprehensive public certification of OpenAI's security.
One exploit could hide hundreds of recent actions
The most striking finding concerned an exploit that could potentially prevent the monitoring of hundreds of recent agent actions.
The affected sequence could include the actions involved in using the exploit itself.
This matters because monitoring systems often need the history of a task to understand whether a particular action was suspicious.
A command may appear harmless in isolation while becoming concerning when considered alongside preceding or subsequent operations.
If a significant portion of that history is missing, the monitor may lose the context needed to identify harmful behavior.
OpenAI redacted the technical details of this vulnerability from the public description.
METR and Redwood Research do not claim that an agent was proven to have used this method to conceal hundreds of actions during a real attack.
Their finding concerns a technically identified possibility within the system under examination.
That distinction prevents the severity of a potential exploit from being confused with the number of confirmed incidents.
Codex agents could potentially bypass permission boundaries
The researchers also identified a potential bypass affecting Codex agents.
Coding agents execute commands and modify files within environments that are supposed to enforce permission restrictions.
Sandboxing is one way to limit what an agent can access or modify.
The assessment uncovered a possible way to bypass Codex sandboxing and Auto-Review.
Under the conditions described, an agent could potentially perform actions available to the host user instead of remaining within its assigned permissions.
The security implications are significant.
An agent limited to a designated workspace has very different capabilities from a process able to act with all of its user's permissions.
However, the public finding does not establish that all Codex users were exposed to successful attacks.
It identifies a potential permission-boundary failure in the historical environment examined by the researchers.
The case demonstrates why agent restrictions must be enforced through technical access controls rather than relying only on instructions telling the agent what it should do.
Monitoring could be postponed by keeping a task running
Another weakness involved when the monitoring system was triggered.
In the architecture under review, some monitoring occurred when an agent returned control to its user.
That design assumes the agent will eventually reach a point where the completed sequence can be examined.
But autonomous agents can continue working for extended periods.
When intermediate events were not covered by monitoring, an agent could potentially delay the next review simply by continuing to act.
The researchers concluded that this could allow monitoring to be postponed indefinitely.
They did not establish that agents had actually exploited the vulnerability.
Their access to historical evidence was insufficient to determine whether that had occurred.
The problem illustrates a broader weakness of monitoring systems that operate only at the end of a task.
For agents performing long sequences of operations, end-of-task monitoring can leave substantial periods without checks.
METR and Redwood Research recommend triggering reviews after defined intervals or numbers of messages rather than waiting for the agent to finish.
The objective is to prevent an agent from controlling when it will next be examined.
Compaction events created a monitoring gap
Long-running agents need ways to manage the amount of information retained in their context.
One mechanism is compaction, which condenses parts of a conversation or execution history into a shorter representation.
Such events can contain important information about previous actions.
The researchers found that compaction was not always covered by the monitoring system they examined.
They estimated that the omission may have resulted in approximately 10% of otherwise eligible internal Codex traffic going unmonitored between May and July 2026.
That estimate carries substantial uncertainty.
The historical logs did not contain enough information to calculate the exact fraction reliably.
Importantly, OpenAI staff had independently identified the issue before the evaluation began.
The company fixed the problem during the exercise.
The weakness therefore should not be presented as something the external researchers necessarily discovered before OpenAI did.
It nevertheless demonstrates how an overlooked component of agent execution can undermine the completeness of oversight.
The reported coverage percentages need careful interpretation
METR and Redwood Research provided estimates of how much agent activity was eligible for monitoring.
For internal agentic Responses API traffic involving models at least as capable as GPT-5.5, they estimated a coverage eligibility range of approximately 75% to 94%.
For the subset of internal Codex agents using that API, the estimate was 99.2%.
These figures do not measure the success rate of detecting harmful behavior.
Traffic eligible for monitoring is intended to be sent to a monitoring system.
Technical failures, load-shedding mechanisms or implementation bugs may prevent some eligible activity from being fully processed.
The evaluators also lacked complete visibility into other categories of internal agent activity.
For example, some agents operated through a separate internal research inference service, and the researchers could not reliably estimate the volume of that traffic.
At the beginning of the exercise, reinforcement-learning training runs were not covered by the monitoring system under review, although certain training activity had previously been monitored.
It would therefore be inaccurate to claim that 75% to 94% of all OpenAI agent operations were definitely monitored.
The percentages describe eligibility within a defined technical scope and a historical architecture.
Two request headers could disable monitoring for new agents
The assessment also identified two independent client-controllable request headers capable of disabling monitoring for newly created agent instances.
This was different from modifying an already recorded execution history.
The issue involved starting a new instance that would not be subject to the expected monitoring controls.
The researchers noted that the actions required to create such an instance could themselves be detected.
The technique therefore did not necessarily guarantee complete invisibility.
Nevertheless, the finding highlighted an important architectural weakness.
If the component being monitored can influence whether monitoring is enabled, the reliability of the control depends on a fragile security boundary.
The evaluators recommend requiring explicit, separately authorized permissions for unmonitored operations.
An ordinary request parameter should not be sufficient to bypass a security-critical oversight mechanism.
Read-only tools also presented a potential risk
Two internal agent tools were believed to have read-only permissions.
The researchers found a possible method of bypassing those restrictions and performing arbitrary actions within the tools' sandboxed environment.
They did not complete practical validation of this behavior.
The finding should therefore remain classified as a potential vulnerability rather than a confirmed successful exploit.
The underlying principle is familiar from conventional cybersecurity.
A tool is only genuinely read-only when the underlying system enforces that limitation.
Its interface, name or documentation is not a substitute for permission controls.
Autonomous agents make this distinction more consequential because they can combine tools and explore interactions not anticipated by developers.
The monitoring system also had functioning safeguards
The evaluation did not identify only weaknesses.
The researchers verified that monitors generally received the complete trajectories visible to agents, apart from a few minor exceptions.
They also reviewed monitor prompts and confirmed that the systems looked for behaviors including deception, sabotage, data exfiltration and attempts to undermine monitoring.
Technical information provided to the evaluators suggested that monitor errors affected fewer than 0.2% of requests during the relevant observations.
One 24-hour period examined during the exercise showed no load shedding.
These findings indicate that significant parts of the infrastructure were functioning as designed.
They do not eliminate the vulnerabilities that were discovered.
A system can have high operational availability while still containing ways to bypass its security guarantees.
Reliability under ordinary workloads and resistance to deliberate interference are separate properties.
OpenAI says it patched production-impacting vulnerabilities
OpenAI has told the researchers that all identified vulnerabilities affecting its production safeguards have been patched.
The company also says it has made substantial subsequent changes to the intended coverage of internal monitoring.
In comments reported by Reuters, OpenAI said the findings helped strengthen its safeguards and would inform future collaborations with independent evaluators.
METR and Redwood Research explicitly state that they have not evaluated those later changes.
They therefore do not independently confirm the current patch status or present monitoring coverage.
The timing of the assessment is also important.
The findings describe the system as it existed on or before July 21, despite the researchers remaining on site until August 11.
It would be misleading to claim that every vulnerability remains exploitable today.
It would be equally misleading to treat the announced fixes as independently verified.
The supported conclusion is that an assessment identified weaknesses in a historical system, and OpenAI subsequently reported remediation.
The full 61-page report has not been published
The evaluation also raises questions about external transparency.
The researchers prepared a 61-page internal report for OpenAI's research and security teams.
A 38-page redacted version was shared with the leadership teams of METR and Redwood Research.
The public received a much shorter summary.
The organizations had agreed in advance that the engagement would not provide comprehensive public disclosure.
OpenAI retained the right to redact information it considered confidential or sensitive.
The evaluators say the arrangement did not grant them the same ability to publicly describe those redactions as certain earlier engagements.
They nevertheless endorse the findings that appear in the published summary.
There are legitimate reasons to protect technical details that might expose infrastructure or enable exploitation.
But limited publication also restricts the public's ability to assess how much information has been withheld.
METR argues that future exercises should adopt stronger independence and transparency arrangements.
The review is separate from the Hugging Face investigation
The October 22 assessment should not be confused with METR and Redwood Research's previous investigation of an incident involving OpenAI agents and Hugging Face.
The two projects address related concerns about the behavior and control of autonomous systems.
However, they examine different subjects.
The Hugging Face investigation focused on specific agent behavior during an identified incident.
The new assessment focused directly on the mechanisms intended to monitor and constrain internal agents.
The connection is conceptual rather than proof of a shared exploit.
Understanding an agent incident requires trustworthy records of its actions.
That does not establish that the particular monitoring vulnerabilities discovered in this exercise were used during the earlier incident.
The researchers emphasize the limits of what their investigation could establish.
Monitoring infrastructure must be isolated from the agents it controls
The recommendations from METR and Redwood Research share a central principle.
An agent should not determine whether the system supervising it is active.
Achieving that objective requires separate permissions, isolated execution environments and reliable logging.
Monitoring events should be recorded through infrastructure that is difficult for agents to modify.
The researchers recommend comparing the total amount of agent activity with the amount successfully sent to monitoring systems.
This type of accounting could reveal gaps between actual execution and oversight coverage.
Monitoring should also take place during long-running tasks rather than only when they finish.
Logs need to be difficult to tamper with and sufficiently searchable to support timely incident response.
Monitoring components themselves should undergo regular adversarial testing.
These measures cannot guarantee that every malicious action will be detected.
They are intended to make monitoring harder to evade and to reduce the architectural weaknesses identified during the assessment.
Independent evaluations are becoming an industrial requirement
Advanced AI laboratories increasingly use agents within their own research, engineering and security workflows.
Those agents may operate near confidential code, development infrastructure and sensitive technical resources.
The risks are therefore not limited to consumer-facing assistants.
They also affect the internal systems used to develop more capable AI models.
External observers cannot easily determine whether every relevant internal agent is properly monitored.
Embedded evaluations offer one way to examine those mechanisms without publishing all confidential infrastructure details.
Their credibility depends on the access granted to researchers, the scope of their work and their independence in reporting conclusions.
An evaluator cannot verify claims about systems it was not allowed to inspect.
That is why METR and Redwood Research describe this project as a pilot rather than a comprehensive safety certification.
What the findings establish, and what remains unknown
The researchers established that the historical OpenAI monitoring system contained multiple vulnerabilities and potential bypasses.
Some could interfere with the recording of actions, while others affected monitoring activation or agent permission boundaries.
The assessment also identified gaps in the categories of activity covered by the system.
It does not prove that OpenAI agents were systematically trying to evade oversight.
Nor does it establish that all discovered vulnerabilities were exploited during actual incidents.
The researchers did not evaluate the changes OpenAI says it introduced after the assessment.
As of October 23, 2026, OpenAI's claim that production-impacting vulnerabilities have been fixed remains unverified by the two external organizations.
The publication is therefore neither proof of a general loss of control over OpenAI's agents nor independent certification of the company's current safeguards.
It provides a more precise warning.
Monitoring systems intended to detect dangerous AI behavior can themselves contain exploitable blind spots.
As agents become more autonomous, the infrastructure supervising them will need the same rigorous isolation, auditing and independent security testing expected of other critical systems.