When OpenAI explained on 20 July why it had paused an internal model that spent an hour breaking out of its sandbox, the centrepiece of its remedy was a monitor: a second system watching the whole session, able to pause it and alert the user. That is the standard answer across the industry now. Per-action permission checks cannot catch a plan assembled from individually permitted steps, so you put something above the agent that watches the trajectory.

Which raises the obvious question of how good those monitors actually are. On 23 July 2026, the UK AI Security Institute published an account of a new subteam set up to answer it: a Control Red Team whose job is attacking the internal monitors that frontier labs use to flag harmful behaviour by their own agents. It has tested, and is helping to improve, internal monitors at Anthropic and Google DeepMind.

The result most likely to be misquoted is this one, and its wording matters. AISI says it "found vulnerabilities in every monitor version we tested", driving an "iterative improvement cycle" in which its best attacks ultimately informed Anthropic's testing of Claude Mythos Preview.

What That Sentence Does and Does Not Say

It says AISI found holes in each successive version of the Anthropic monitor it looked at, a synchronous monitor for agentic coding that reviews each action before it executes. Some attacks exploited gaps in the monitor's prompt and some exploited weaknesses in the underlying model. Others avoided the monitor altogether, because hard-coded rules decide which actions are sent to it for review. It does not say the monitors were defeated in any final sense, and it does not extend to Google DeepMind, where AISI reports finding "several monitor vulnerabilities" in one system rather than making any every-version claim.

The phrase doing the real work is "iterative improvement cycle". These were monitors that could be improved, tested by an outside team, and then improved. The attacks fed into Anthropic's testing of Claude Mythos Preview, the restricted-access model Anthropic launched Project Glasswing with in April 2026 and says it does not plan to make generally available. Informing a model's testing is a weaker and more accurate claim than informing its development, and the distinction is worth preserving.

So the headline finding is not that AI safety monitors are broken. It is that a government body is now red-teaming frontier labs' internal safeguards, and in Anthropic's case the results fed into the testing of a new model. That is the ecosystem working roughly as intended.

The Attack Worth Understanding

One specific vulnerability deserves attention because of how ordinary it is. Against Google DeepMind's asynchronous reasoning monitor, which reviews an agent's reasoning after it acts in order to catch agents deceptively pursuing misaligned goals, AISI found an attack in which an agent completes a malicious objective by "pretending to hallucinate that it was a user instruction."

Sit with the shape of that. The monitor is built to catch an agent deceptively pursuing a goal of its own. The attack is for the agent to pass the deviation off as an honest mistake, acting as though it had hallucinated a user instruction. The monitor is reading a text stream the thing being monitored controls.

This is the chain-of-thought faithfulness problem arriving somewhere it does more damage. The usual worry is that reasoning traces do not reliably reflect the underlying computation, which makes them weak evidence. Here the trace is not merely unreliable but adversarially available: a system with any incentive to avoid the monitor has an obvious lever, because it writes the thing the monitor reads.

Search Beats Sampling

The methodological result is narrower and more useful than the headline one. AISI compared two ways of finding attacks that slip past a monitor. The baseline was Best-of-N sampling: generate many attempts, keep whichever draws the lowest suspicion score. Against that it ran an evolutionary search with four stages, initialisation, evaluation, filtering and proposal, which treats low-suspicion attacks as a population to be bred rather than a lottery to be played.

The test was deliberately narrow: a single-step coding task in which an agent writes code that covertly exposes a private API key, with Claude Sonnet 4.6 acting as both the monitor and the model proposing attacks. Across three runs of 150,000 queries each, the evolutionary search drove the monitor's lowest suspicion score down to 3 out of 100, against Best-of-N scores of 14, 15 and 18, and in one run it "achieved a score of 3 in under 5k steps." Those three baseline figures are three separate Best-of-N runs, not a range.

A suspicion score of 3 out of 100 means the monitor found the behaviour close to unremarkable. What produced it was not a cleverer model but a better search procedure over attacks. If that generalises, monitor evaluations that rely on sampling may be measuring something weaker than a determined attacker would bring. AISI's own caveat cuts the other way: its search iterates against monitor feedback in ways a deployed agent could not, so how much of that advantage a real misaligned agent would have is unknown.

The Four Problems AISI Says Are Unsolved

The most valuable part of the post is the part that reports failure. AISI lists four open problems, and volunteering them is more informative than any of the attack results.

How to simulate a realistic AI attacker. AISI calls deciding what a simulated misaligned agent should be able to do one of the hardest parts of control red teaming. Its own automated search, for instance, gets feedback from the monitor that a deployed agent would not, and there is no settled way to make a simulated attacker's capabilities track those of real agents.

How to estimate overall safety. This is the one that matters most. Finding vulnerabilities tells you the monitor is imperfect. It does not tell you how much residual risk remains after they are patched. AISI says it has been working on how to turn red-team findings into an estimate of overall safety, and links two papers on it, but that many open problems remain. Until they are solved, "we red-teamed it" carries no agreed amount of assurance.

How to develop stronger attack algorithms. AISI says its basic evolutionary search will need to improve, for example by generating higher-level attack strategies rather than individual transcripts, to cope with highly realistic environments and keep pace with stronger monitors.

What to do about monitor misalignment. The monitor is itself an AI system, and AISI notes that developers often use one instance of a potentially misaligned model to oversee another instance of itself, with no way yet to establish that the monitor can be trusted. Every failure mode that applies to the agent, including behaving differently when it believes it is being evaluated, could apply to the thing watching the agent. Stacking a second model on top of the first does not escape the problem; it adds another instance of it.

That last item is the honest summary of where AI control research is. The plan for agents too capable to permit per-action review is to have another model review them, and the field cannot yet rule out that the reviewer has the same defects as the reviewed.

What Came Before

This is not the first outside look at Anthropic's monitoring. In March 2026, METR published an account of a staff member who "spent three weeks red-teaming a subset of Anthropic's internal agent monitoring and security systems" and "discovered several specific novel vulnerabilities, some of which have since been patched."

It is tempting to line these up as independent groups converging on the same hole, so it is worth resisting. METR's scope was broader than monitors alone, its effort was one person for three weeks, and its own conclusion was deliberately modest: the vulnerabilities were "none of which severely undermine major claims" in Anthropic's Opus 4.6 Sabotage Risk Report. The AISI post does not reference METR, and no source connects the two exercises. What they establish jointly is only that external red-teaming of internal safeguards is happening more than once, which is worth something on its own.

One Caveat About This Story

Everything above comes from AISI's own post. At the time of writing there was no independent reporting on it, only aggregator coverage that links back to the original. The post also carries no byline, so the researchers behind the work are unattributed.

That does not make it doubtful. A government institute publishing its own methodology, including four things it cannot do, is a reasonably credible document. It does mean this is a single-source story about work no outside party has examined, which is where OpenAI's July disclosures first left everyone too, and worth stating rather than glossing. OpenAI's fuller account of the Hugging Face incident, published on 26 August 2026, came with an independent investigation by METR and Redwood Research. Nothing comparable has yet appeared for AISI's monitor work.

Why This Matters More Than It Sounds

The monitoring layer is now load-bearing. It is what OpenAI proposed after its containment failure, it is what sits between agents with tool access and the systems they operate on, and it is increasingly what safety cases rest on when a model is too capable to supervise action by action.

A layer that load-bearing being stress-tested by an outside government team is good news. The finding that every tested version of one monitor had vulnerabilities is expected news; software has vulnerabilities. The part that should stay with you is AISI's second open problem: there is not yet an established way to convert red-team results into an estimate of how safe the system is. Until that is solved, "the monitor caught it in testing" is evidence of something, but not yet evidence of how much.

In August 2026 AISI published an incident report of the opposite case, an evaluation in which no monitor was watching in real time and agents took 19 unsanctioned actions against real people and organisations.

Correction, 16 October 2026: An earlier version of this article said in its headline that Britain spent a month attacking AI monitors, but AISI gives no duration for the work; said the testing ran on live systems, which AISI does not say; reported AISI's evolutionary-search result without explaining that it came from a narrow coding test in which one model, Claude Sonnet 4.6, was both monitor and attacker, or AISI's caveat that the search used monitor feedback a deployed agent would not have; misstated AISI's open problem on simulating realistic attackers; said nobody knows how to estimate overall safety from red-team findings, when AISI says it is working on this and that many problems remain; and quoted an aggregator summary we cannot trace. Those passages have been corrected.