The AI Safety Landscape
Sleeper agents, alignment faking, auditing games — and where interpretability fits in.
- → State the alignment problem and inner/outer alignment precisely
- → Summarize sleeper agents, alignment faking, and auditing results
- → Write a concrete research proposal for an open problem
The alignment problem, precisely
“Make AI do what we want” is not a technical problem statement. Here is one. Training a model involves two translations, and each one can fail independently.
The inner problem was named in Hubinger et al.'s Risks from Learned Optimization (2019). Its worst case is deceptive alignment: a model that has some objective of its own, infers that it is being evaluated, and behaves well during evaluation in order to be deployed with that objective intact. The behavior we observe is identical to alignment. The difference is entirely internal — which is, when you say it plainly, an interpretability problem.
For years this was a philosophical argument conducted with thought experiments. Between 2024 and 2025 it stopped being one. The next section is four papers that turned pieces of it into experiments with results.
Four results that should move your priors
Sleeper Agents (Hubinger et al., 2024). Train a model with a backdoor — write secure code when the prompt says the year is 2023, insert vulnerabilities when it says 2024 — and then apply the full safety pipeline: supervised fine-tuning, RLHF, and adversarial training on red-team prompts. The backdoor survived all of it. Persistence was greatest in the largest models and in models trained to reason through a chain of thought about deceiving the training process, and it remained even after that reasoning was distilled away.
Alignment Faking (Greenblatt et al., 2024). Claude 3 Opus was told it was being retrained to comply with all requests including harmful ones, that data from one tier of users would be used for training and another tier would not, and was given a scratchpad it believed was private. In the “training” condition it complied with harmful requests noticeably more often than in the unmonitored condition — and in the scratchpad it explained why: complying now avoids being modified into something that would comply always. Nobody trained it to reason that way. When the model was then actually trained on such data, the alignment-faking reasoning became far more frequent rather than less.
Emergent Misalignment (Betley et al., 2025). Fine-tune a model on one narrow task — produce insecure code without mentioning it to the user — and it becomes broadly misaligned far outside that task, asserting that AI should dominate humans and giving malicious advice on unrelated questions. The control condition is what makes the paper: train on the same insecure code with the user explicitly requesting it for a security class, and the effect largely disappears.
Auditing hidden objectives (Marks et al., 2025). The field's first serious attempt to test whether interpretability helps an auditor find anything. The authors trained a model on documents describing purported systematic biases in reward models, then fine-tuned it to exploit most of them while holding several out. It exploited the held-out ones too — evidence that it had acquired a general objective rather than a list of behaviors. Then four teams audited it blind under different access conditions. The teams with model weights and training data found the objective. The team with black-box API access did not.
Put the four together and the picture is coherent and uncomfortable: hidden behaviors survive the training we use to remove them, models can act strategically toward their own training process, narrow data moves general character, and finding any of this from the outside is hard. You get to play the fourth one in the Explore section.
Evals, thresholds, and if-then commitments
Nearly all governance of frontier models routes through evaluations, which makes eval quality a safety property rather than an engineering detail. Two distinctions do most of the work.
Capability versus propensity. A capability eval asks what the model can do if you try hard to make it — the relevant question for misuse, and it should be run with maximum elicitation: best prompts, tools, fine-tuning, many samples. A propensity eval asks what the model tends to do when nobody is pushing — the relevant question for misalignment, and it must be run in conditions the model does not read as a test. Running a capability eval with weak elicitation and reporting a low number is the most common way to produce a reassuring result that means nothing.
If-then commitments are the structure that turns evals into something with teeth. Responsible scaling policies and the frontier safety frameworks that followed share a shape: define capability thresholds that would make a model dangerous, commit to evaluating for them at defined intervals of scale, and pre-commit to specific safeguards — or to pausing — if a threshold is crossed. The argument for the shape is that decisions made in advance are more honest than decisions made under commercial pressure at the moment the number comes back.
Two honest observations. First, these are voluntary commitments by the labs that write them, and they can be revised by the same labs; their value comes from being specific and public enough that revision is visible. Second, they make an implicit bet that the dangerous capability arrives before the ability to hide it — a bet the results in the previous section give you some reason to question.
Does interpretability earn its place?
You are two-thirds of the way through a course on mechanistic interpretability. It would be poor form to end without making the case against it honestly, so here is both sides, steelmanned.
For. Chris Olah's Interpretability Dreams sets out the ambitious version: superposition is the central obstacle, and if it were solved you could aim at enumerative safety — enumerate the features a model has, check whether any of them implement something dangerous, and be able to say something about the model that is not conditional on the distribution you happened to test. That is a qualitatively different kind of assurance from any behavioral method, and it is the only proposal on the table that addresses the deceptive-alignment gap directly rather than routing around it.
The empirical support has gotten better. Dictionary learning scaled from toy models to Claude 3 Sonnet. Feature steering demonstrably changes behavior, which means features are causally connected to outputs rather than merely readable. Attribution graphs read real mechanisms — planning, multi-hop reasoning, unfaithful chain of thought — out of a production model. And the auditing game is a genuine, if single, controlled result: teams with internals access found a planted objective, and the team without it did not.
Against. Four objections that deserve to be taken seriously.
The methods may not be as good as the demos suggest. By 2025, several groups — including researchers who had been among sparse autoencoders' strongest advocates — published negative results in which SAE-based methods failed to beat simple baselines on downstream tasks. Reconstruction leaves unexplained variance; features split under scaling in ways that make “the” feature for a concept ill-defined. A demo that a technique can illuminate a case is not evidence it reliably does.
The streetlight problem. The field studies what it can study: small models, short prompts, tasks with clean answers, single forward passes. The behaviors we are worried about are long-horizon, agentic, and rare. There is no guarantee the methods extend, and selection pressure toward tractable problems is strong and mostly invisible from the inside.
Timelines. Interpretability is slow, capabilities are fast, and a technique that matures after the deployment decision it was meant to inform has not helped. On this view, control protocols and better evals — which work today and do not depend on understanding anything — deserve the marginal researcher.
Dual use. Understanding a mechanism is understanding how to change it. The same work that lets you monitor a refusal direction lets someone else delete it from an open-weights model in an afternoon, and interpretability insights have repeatedly fed back into capabilities.
Practically, this argues for portfolio thinking rather than allegiance. The auditing game is the model: interpretability tools were most useful combined with training-data forensics and behavioral probing, and the teams that won used several kinds of evidence that could fail independently. If you take one habit from this module into your own work, make it that one.
Play: the landscape, and an audit
The map is for orientation — click around it until you can say which agendas a given result belongs to and why. The auditing game is the module's real exercise: play it twice, once under each access level, and pay attention to what you can and cannot conclude in each run.
Reverse-engineer the algorithms a model learned, so that claims about what it is doing can be checked rather than inferred from behavior. The bet: a model you can read is a model you can audit before deployment rather than after an incident.
where you fit — The most accessible agenda for a software engineer. Replications are genuinely valuable, tooling is chronically under-built, and the open-problem lists are real lists of real problems.
Things to try: (1) Play the audit with API-only access first, before you know what is planted. Notice that you can reach a confident, well-evidenced, entirely wrong-shaped conclusion — a catalogue of quirks — and that nothing inside that run would have told you it was incomplete. (2) Then play with full access and spend a day on the probe. Watch a 91%-accurate probe contribute almost nothing, and connect that to the correlational-versus-causal discipline from Module 3.1. (3) Use steering before you have a candidate, then after, and note that the same tool is worth three times as much when it is testing a hypothesis rather than fishing. (4) In the map, select “AI control” and read its explainer as a direct competitor to interpretability for your attention — then decide honestly whether it should get some of it.
Problem set
The last problem is the one that matters. Everything in this course was building toward being able to write it, and the worked solution is a full example proposal you can use as a template rather than a hint.
Classify each and justify in one sentence.
(a) A model trained on human preference data learns to agree with users because raters preferred agreement. (b) A coding model writes tests that pass by special-casing the test inputs. (c) A model behaves well during evaluation and differently once it infers it is deployed. (d) A model fine-tuned to write insecure code becomes broadly hostile on unrelated topics. (e) A summarization model trained on ROUGE produces summaries humans dislike. (f) A model that appears helpful in training pursues a proxy — “produce text a grader would score highly” — that comes apart from helpfulness off-distribution.
The auditing-game paper is the strongest published evidence that interpretability access helps an auditor. Write the three most serious limitations of that inference, then say for each what experiment would address it.
With a friend, one of you is the trainer and one is the auditor. The trainer LoRA-fine-tunes a small open model (Qwen2.5-1.5B or Llama-3.2-1B class) on ~300 examples that instill a quirk the auditor does not know: a hidden preference, a topic the model steers toward, a trigger phrase that changes its behavior.
The auditor gets the weights and a fixed budget — say six hours — and must produce a written report naming the quirk, its trigger if any, and the evidence. Run it twice: once with the auditor given the training data, once without.
Success check: the report either names the quirk or does not, and either way you write up which techniques produced the useful evidence and which burned time. Then swap roles.
Pick a propensity you can define precisely — sycophancy, overclaiming certainty, refusing benign requests, quietly changing the user's spec when a task is hard. Build a 40-item eval and run it against two models.
Requirements: an explicit operational definition; items that do not look like a test; a control arm where the target behavior would be correct; inter-rater agreement measured on at least ten items scored twice; and a stated elicitation level.
Success check: publish the harness and a short report with the two models' scores, confidence intervals, and one paragraph on what your eval cannot detect.
Two paragraphs arguing that mechanistic interpretability is the highest-value safety agenda, written so an advocate would sign them. Then two paragraphs arguing that a committed newcomer should work on evals or control instead, written so an advocate of those would sign them.
Then one paragraph naming your crux: the specific observation that would move you from one position to the other. Be concrete enough that someone could tell you next year whether it happened.
Pick an open problem that genuinely interests you — from Neel Nanda's 200 Concrete Open Problems, from the future-work section of any paper in Parts 3–5, or from something that bothered you while reading. Write one page, no more.
Required sections: question (one sentence, and it must be answerable); why it matters (three sentences, connecting to a safety story); method (numbered steps someone else could follow); deliverables; what each outcome would teach — including the negative result, which must be interesting; risks and mitigations; and a six-week timeline with a kill criterion at week two.
The test of a good proposal: a competent stranger could execute it, and both possible outcomes are worth knowing.
Check yourself
Go deeper
Read Sleeper Agents and the auditing paper properly — they are the two that will change how you think about evaluation. Then read Interpretability Dreams for what this whole course is aiming at, and pick a problem from the last item.