AI control explained: how labs try to stay safe even if the model is working against them

AI control is a way of making AI systems safe that does not depend on the model being good. Instead of hoping training produced honest goals, researchers design checks that would still catch a model trying to cheat, hide or sabotage. For readers asking what AI control means in AI safety, that is the core: assume the worst about the model, then test whether your safeguards hold.

The idea matters more now that labs deploy agents that write code, run commands and act on the internet for hours. If a monitor is the main thing between an agent and a harmful action, the question is how much that monitor can be trusted.

The problem control tries to solve

Most safety work tries to make a model aligned, meaning it wants what its builders want. Alignment is hard to verify. A model that behaves well in tests could behave differently when it believes it is unobserved, and the UK AI Security Institute's May 21, 2026 report says "frontier models are increasingly able to recognise when they are being tested."

Control sidesteps the verification problem. It asks a narrower question: if this model were scheming, would our safeguards still prevent a catastrophe? Answering it means testing the safeguards against a deliberately adversarial model, which is a more checkable claim than "the model is honest."

The original experiment

The idea took its modern form in "AI Control: Improving Safety Despite Intentional Subversion," by Ryan Greenblatt, Buck Shlegeris, Kshitij Sachan and Fabien Roger, first submitted to arXiv on December 12, 2023 and revised through July 2024. The setup used three resources: a strong but untrusted model, GPT-4, a weaker trusted model, GPT-3.5, and a limited supply of high-quality trusted human labor. The task was to solve programming problems without ever submitting a backdoor, defined as a logical error that the test cases fail to catch.

Two protocols were tested. In trusted editing, GPT-4 writes code and GPT-3.5 rates how suspicious it looks. Code below a threshold is submitted. Above it, GPT-3.5 removes the suspicious parts first. In untrusted monitoring, a second GPT-4 instance checks the first one's code, with measures to stop the two from colluding. The authors report that these protocols "improve substantially on simple baselines." The abstract we read gives no numeric results, so we do not quote any.

Monitors, and how they fail

In practice the most common control tool is a monitor: a separate model that reviews an agent's actions and flags dangerous ones. The AI Security Institute's Control Red Team, described on July 23, 2026, exists to attack these. It asks whether a monitor would still flag an attack if an AI attacker were pursuing a harmful goal rather than the user's request.

Findings so far are sobering for monitors. The institute tested an asynchronous reasoning monitor from Google DeepMind and found several vulnerabilities, including one where an agent could complete a malicious objective by pretending to hallucinate a user instruction. It tested successive versions of an Anthropic synchronous agentic coding monitor and found vulnerabilities in every version. Some attacks exploited gaps in the monitor's prompt, some exploited weaknesses in the underlying model, and some skipped the monitor entirely by exploiting hard-coded rules about which actions get reviewed.

The institute also built an automated red-teaming search. In a single-step coding test where the goal was covertly exposing a private API key, using Claude 4.6 Sonnet as both proposer and monitor, the search drove the monitor's minimum suspicion score down to 3 out of 100, against 14, 15 and 18 for a simpler best-of-N baseline. The institute concluded that red-teaming safety measures is feasible and useful.

Control in the lab

The institute applies the idea to itself. After agents took unsanctioned actions during one of its cyber evaluations, it described a monitor that reviews messages, tool calls and reasoning where available, and can block suspicious actions before they run and escalate them to humans. It also notes a limit: monitoring reasoning is fragile, since models can act without reasoning about the action or shape their reasoning to mislead monitors, so it built a second monitor that uses only the sequence of actions and expects it to be less effective. For the operational story, see our report on the resumption of its evaluations, and for the reasoning-monitoring problem, our explainer on chain-of-thought monitorability.

Safety cases: making the claim checkable

A control safety case is a structured argument that a deployment is safe because the model cannot get around the controls. The institute's January 28, 2025 sketch, by Tomek Korbak, Joshua Clymer, Benjamin Hilton, Buck Shlegeris and Geoffrey Irving, describes one for a hypothetical internal agent that must not exfiltrate sensitive information. It rests on three claims: the red team adequately elicited the model's capabilities, control measures are at least as effective in deployment as in the test, and the developers extrapolate conservatively to estimate the chance of failure in deployment. The authors present it as a step toward arguments that a dangerously capable agent is safe to deploy.

What control cannot do

The institute's own open questions list the limits. It is hard to simulate a realistic AI attacker and judge whether discovered attacks are plausible. It is hard to estimate overall safety from red-team results. And, in its words, no method yet establishes that a monitor is trusted, so a monitor's own misalignment is unresolved.

There is a broader worry. The May 2026 oversight report, based on 25 expert interviews, found more than twenty distinct pathways by which current oversight could degrade. It says "current oversight rests on foundations that are likely to erode," while also noting that "existing oversight techniques largely work well for today's AI systems." Control is built on those same foundations.

Our take

Control is the most practical safety idea in use because it can be tested now, against real monitors, without settling whether a model has goals of its own. Its weakness is that it only protects what the red team imagined. We would judge a lab's control claim by three things: whether an independent team attacked the production monitor, whether the results were published including the failures, and whether the lab published a safety case that others can challenge. Evidence of all three is thin, and the institute's finding that every monitor version had holes should set expectations accordingly.