AI Control: Safety Without Assuming Alignment
4 min read · updated August 3, 2026
Almost all alignment research asks how to make a model want the right thing. Control asks a different question: suppose you failed, and you cannot tell. What deployment would still be safe?
The premise
The control agenda, set out by Greenblatt, Shlegeris and colleagues in “AI Control: Improving Safety Despite Intentional Subversion” (2023), begins from an observation about the state of the field. There is no reliable way to verify that a model is aligned. Interpretability cannot yet certify the absence of a goal; behavioural testing shows behaviour under test conditions. So a deployment plan that depends on the model being aligned depends on something nobody can check.
Control drops the dependency. It assumes the model may be actively working against you and asks what safety properties still hold. The shift is analogous to security engineering: you do not deploy a system on the assumption that no one will attack it, and you do not need to know an attacker’s motives to design against them.
Two limits are stated in the original work rather than discovered by critics. Control targets models that are dangerous but not radically superhuman — a system that can outthink every countermeasure is outside its scope, and the authors say so. And it is a stopgap: a way to get useful work out of models you cannot yet trust, during a period when you cannot yet verify them.
How a control evaluation works
The methodology is the contribution, more than any individual protocol. A control evaluation is an adversarial game with explicitly separated resources:
| Element | Description |
|---|---|
| untrusted model | The capable model whose alignment is unknown. In the evaluation it is played by a red team that instructs it to pursue a defined bad outcome while avoiding detection. |
| trusted model | A weaker model believed safe, usually because it is too limited to execute a plan of the relevant kind. Cheap, plentiful, and worse at the task. |
| trusted human labour | A small, explicitly budgeted amount of expert review — a fixed percentage of actions, not unlimited oversight. Making this a scarce resource in the model is what keeps the result realistic. |
| the protocol | The blue team's policy for combining the three: what gets routed where, what gets escalated, what gets rejected. This is the object being evaluated. |
| the safety measure | The probability that the red team achieves the bad outcome without being caught, over many episodes. A protocol is judged by this and by how much useful work still gets done. |
The reason this is more than a thought experiment is that every element is instantiable today. You can run it on real code-writing tasks with real models, and get a number that is a property of the protocol rather than an intuition about it.
The protocols
- Trusted monitoring. The untrusted model does the work; the trusted model reads every output and scores it for suspicion; the most suspicious fraction goes to human review, up to the budget. Simple, and strong in the published experiments, because it converts a scarce human resource into a triage problem.
- Untrusted monitoring. Use a second copy of the capable model as the monitor, since a weak monitor misses subtle problems. This raises collusion — two copies of the same model may share a policy of not reporting each other — which is countered by inserting known-bad actions to test whether the monitor flags them, and by keeping the monitor unable to tell testing from production.
- Trusted editing. Rather than accept or reject, hand suspicious output to the trusted model to rewrite conservatively. Preserves more usefulness than rejection at the same safety level.
- Deferral to trusted. Above a suspicion threshold, discard the untrusted output and use the weaker model’s answer. A direct, tunable trade of quality for safety.
These are not exotic. They are the same shapes as staged rollouts, code review and least-privilege access, applied with the assumption that the component under review is adversarial rather than merely fallible.
Safety against usefulness
The framing that makes control practical is that it produces a curve rather than a verdict. Route everything to humans and you are safe and have gained nothing. Accept everything and you have full usefulness and no safety. Every protocol sits somewhere between, and the useful question — for a given task, model pair and audit budget, how much safety does this protocol buy at what cost in throughput — is one an engineering team can answer.
That is a genuine change in what safety work looks like. It turns an argument about future systems into a measurement about a deployment you are running, and the measurement can be repeated when either model changes.
Where it stops working
Capability ceiling. Every protocol assumes the untrusted model cannot reliably out-plan the whole scheme — that it cannot recognise the evaluation, model the monitor well enough to be subtle in exactly the right way, or coordinate across episodes. Those assumptions weaken as capability rises, and there is no version of control that survives arbitrarily large gaps.
The red team is a lower bound. The safety number is a measurement against the attacks your red team thought of. A real failure mode nobody modelled does not appear in the result. This is the standard limitation of adversarial evaluation and it applies here in full.
The strategic objection. Some researchers argue that making it possible to extract value from models you cannot trust reduces the pressure to build models you can — that control is a workable answer to the wrong question. Proponents reply that the untrusted period is happening regardless, so refusing to work on it forfeits the safety available in it. This is a disagreement about strategy and incentives, not about any empirical claim, and it is not close to resolved.
It is not a substitute for alignment. The authors are explicit: control buys time in a specific regime. Whether that regime lasts long enough for the time to be worth much is a prediction, and it depends on how fast capability moves — a question taken up in the scaling and forecasting pages of this cluster.