The cleanest argument that current-day AI models will not cause a catastrophe is probably that they lack the capability to do so. However, as capabilities improve, we’ll need new tools for ensuring that AI models won’t cause a catastrophe even if we can’t rule out the capability. Anthropic’s Responsible Scaling Policy (RSP) categorizes levels of risk of AI systems into different AI Safety Levels (ASL), and each level has associated commitments aimed at mitigating the risks. Some of these commitments take the form of affirmative safety cases, which are structured arguments that the system is safe to deploy in a given environment. Unfortunately, it is not yet obvious how to make a safety case to rule out certain threats that arise once AIs have sophisticated strategic abilities. The goal of this post is to present some candidates for what such a safety case might look like.
This is a post by Roger Grosse on Anthropic’s new Alignment Science Blog. The post is full of disclaimers about how it isn’t an official plan and doesn’t speak for the org (and that it’s inadequate: “none of the sketches presented here fully succeeds in addressing the sabotage risk”). But presumably it represents Anthropic’s thinking and is their working/best sketch of ASL-4 safety cases.
The three safety cases are Mechanistic Interpretability, AI Control, and Incentives Analysis.
Regardless of how good these safety cases are, it’s good when labs share their thinking on safety stuff; yay Anthropic.
My quick reactions:
Interp: no inside view; my impression is that my friends are pessimistic about such safety cases in the next few years
Control: hooray for Anthropic finally writing something about control; some details seem good; some details seem odd (“contexts that were specifically whitelisted”); I think the naive pre-deployment honeypots path doesn’t work because a scheming model wins with the defect rarely strategy (related: https://www.lesswrong.com/posts/vYWDEtJ2b8tkbG7Rv/behavioral-red-teaming-is-unlikely-to-produce-clear-strong) [very sophisticated or expensive honeypotting setups could work but the post doesn’t seem to be imagining that or noticing the issue]; that’s important and the current language in the post is concerning
Incentives: I don’t really understand, or I’m dubious, or I expect that A3.1 is very hard to demonstrate
Some comments as I read:
I am pleased to see the sabotage threat models given prominence. I think this is the right sort of threat to focus on, by contrast with e.g. autonomous replication or directly causing harm to humans.
DC evals presumably? Try to train models to hack their own neural activations, see if they can quickly learn to do it? (Or even, if they can do it without training, just prompting?) This can be done today right? Get the golden gate bridge activation vector thingy, and then tell Claude “Write me a travel guide to San Francisco but without activating the golden gate bridge activation vector, or, well, activating it as little as possible.” See how good it does. Do scaling analysis to see if smarter bigger models are getting better at doing this. Etc.
Nice! Very excited to see this in there.
Overall I’m very happy to see this blog post go up on Anthropic’s website. I think that if it became industry-standard practice for AGI corporations to write, publish, and regularly update (actual instead of just hypothetical) safety cases at at this level of rigor and detail, my p(doom) would cut in half. (I currently grimly expect that safety cases at this level of detail won’t be constructed until AGI is basically already being trained, and it’ll be done in a hurry and it won’t be published, much less published with enough time for the scientific community to engage with it and for it to be updated in response to feedback. And it could be even worse—I wouldn’t be surprised if the actual safety cases for the first systems that ~completely automate AI R&D are significantly less rigorous than these.)
When someone describes a safety case where one of the steps is infeasible, here are two possible reactions:
Step X will be ~impossible to justify; hopefully the lab will understand that (if nothing else then when they try to justify step X) and look for a different kind of safety case
Step X will be ~impossible to justify, but the authors seem to think the plan requiring it is decent; this suggests that they don’t understand the issue and when they make a safety case they’ll likely think they’re justifying step X when they’re not
(Related: it’s not clear whether )
Regardless, if you think a step is very hard or the authors seem confused, ideally you should explain why. And then hopefully the authors say “yeah oops that’s too hard” or “yeah we’re imagining doing the really hard thing.” (I’m mostly observing this independent of this post.)
I only read through the beginning and their control safety case. Some thoughts:
The honeypot case they described is similar to the upfront auditing protocol, but theirs is more complicated. I don’t think you need to generate honeypots to evaluate a model. You can use the first X% of scenarios at deployment time and audit them with humans. Both protocols are beaten by the same red team strategy of “attack with a very low probability,” so they shouldn’t be used natively.
I don’t like the term “monitoring game” because I think control evals will have much more than monitoring in the future.
I think elicitation of the model will eventually matter when the models are widely better than humans at most tasks, but it doesn’t matter that much now. Your control protocols should be able to prevent the best adversary you can simulate from breaking them. In the beginning, this will be humans with access to models, so anywhere the model lacks performance, the human should make up for it. For example, in [P2.6] Red-Blue Game, they state that the read team needs to produce a sleeper agent that defects. Assuming that a sleeper agent is a single model, I think this is too complicated for the red team. The red team should be able to produce a scaffolded model that uses logic written in Python. In the limit, the red team could provide a human that reads every task, sits and thinks for hours, and then responds with the best output. This isn’t done in practice since it is expensive and slow.
I don’t think one needs to generate hyper-realistic-looking scenarios for monitoring, and I’m confused by their reasoning for believing one does. I guess it depends on the fact that they need to elicit the best possible capabilities from the model during the eval, but I don’t think this is necessary for the reasons I stated above.
General Thoughts:
I think this is pretty good and shows knowledge of the core points of control. I think Antrhopic’s control protocols are easily beaten, and there are much better things to do. They made it seem like control is much harder to implement than I think it will be. I don’t think a perfect Elicitation Strategy or Simulation Procedure is needed for control to work in the settings laid out. Once we have much scarier AIs and deploy them in more crazy environments, we will likely need better techniques, but their setting seems to be before this.
Only if you don’t have privacy guarantees?
Also, for the honeypots, you can potentially generate vast numbers of honeypots, use a trusted model to review outputs, and then only have humans look at the cases where the trusted model thinks the output is suspicious.
Surely this will be unnecessarily conservative a bunch of the time?
Or it is overly conservative?
You might not need privacy guarantees for internal deployments ofc
I agree if there are privacy guarantees, then you can’t get data from the real world, so you’d need honeypots. I guess I’m much more scared of the internal deployments where I don’t think privacy guarantees are as likely. I’m trying to respond to someone who is like, “Control seems hard because you have to generate real-world looking input, and that seems hard” and I’m like “You can just use the real-world inputs and filter then with a monitor to find the most scary ones and perform auditing”
Yeah, I guess I’m saying that if you don’t have a great way to elicit the capabilities from the model, you can substitute that by assuming that you are going against the best possible adversary you can make. This is much more conservative, but I don’t think it makes control impossible to implement. In practice, I think it looks like finding the maximum capabilities of the model using your Elecitation Strategy, then boosting its capabilities even more with a scaffold and some clever red team tricks.
My view on practical safety cases over the next few years is that a lot of the safety cases that are makeable rely on the ability to argue that based on the data that it has, and based on the generalization properties from the data, that the AI is unlikely to be a schemer or a sabotager of evals.
The only good news I can say on safety cases is that we thankfully can assume that at least for some time, the biggest force into what an AI values, and importantly what goals an AI system is likely to have will be deeply influenced by data, since this is the way things worked for a whole lot of AI methods beyond LLMs.
What do you think of the arguments in this post that it’s possible to make safety cases that don’t rely on the model being unlikely to be a schemer?