AI Control: Using Untrusted Systems Safely with Buck Shlegeris of Redwood Research, from the 80,000 Hours Podcast

Hello and welcome back to The Cognitive Revolution. Today, I'm excited to share a cross-post from the 80,000 Hours Podcast featuring a conversation between host Rob Wiblin and Buck Shlagaris, CEO of Redwood Research and a leader in the nascent but rapidly evolving field of AI control. For those unfamiliar with the term, AI control represents a qualitatively different approach to managing AI risks. Rather than trying to create perfectly trustworthy AI systems from the start, Buck and collaborators are developing frameworks that they hope will allow us to deploy and get useful work from AI systems, even if they remain fundamentally misaligned. This strategy feels particularly timely and important considering the increasingly sophisticated bad behaviors we've seen from frontier AIs over the last 6 months. From the scheming behaviors documented in O1 by Apollo Research, to the alignment faking that Buck's colleague Ryan Greenblatt demonstrated in Claude, to the dramatic rise in flagrant reward hacking behaviors we're now seeing in O3, which, by the way, OpenAI's own research suggests won't be easy to train away, at least for as long as we remain in the reinforcement learning scale-up era. All in all, it seems we're headed for a world of increasingly powerful and autonomous AIs that we can't fully trust and thus have no choice but to figure out how to control. With that in mind, what I particularly love about Buck and team's work is their first principles approach to understanding AI systems and their unique strengths and weaknesses on their own terms. Critically, and in sharp contrast to humans, AI systems operate in information environments that their developers fully control, and they can thus be monitored and tested in totally different ways. Buck shares a number of great ideas in this conversation, including always-on monitoring systems that use weaker models to efficiently review model outputs and then escalate potentially concerning behaviors to stronger models and eventually to humans when needed. Resampling strategies that discard potentially bad behaviors and simply have the AI try again, thus also helping us identify areas where models are particularly misaligned. Paraphrasing strategies that attempt to disrupt any attempts models might make to communicate with one another in undetected code. Factored cognition architectures that give models only the minimum information needed to do useful work, hopefully thereby making it much harder for them to execute long-time horizon attacks. And honeypotting strategies that tempt models to do something bad and then allow us to systematically study their capabilities and tendencies after they've taken the bait. Of course, there are likely to be important practical trade-offs between safety and performance and safety and cost. And as you'll hear, Buck is very focused on developing techniques that frontier model developers will hopefully find cheap and easy enough to implement. This won't solve everything. I don't think anything will. But it seems complementary to other efforts like interpretability and alignment science. And I really do see huge value both in the incremental security that AI control systems will provide as part of a broader defense-in-depth strategy, and also in the credible, concrete proof of malintent that they might uncover if it turns out that the AIs truly are out to get us. As always, if you're finding value in the show, I'd appreciate it if you'd take a moment to share it with friends, write a review on Apple Podcasts or Spotify, or just leave us a comment on YouTube. Of course, we welcome your feedback as well, either via our website, cognitiverevolution.ai, or by DMing me on your favorite social network. Finally, a quick reminder. I'll be speaking at the upcoming Imagine AI Live event, May 28th through 30th in Las Vegas, the ADAPTA Summit, August 12th and 13th in São Paulo, Brazil, and the Enterprise Tech Leadership Summit, September 23rd through 25th, again in Las Vegas. Tickets are on sale for each of these events now, and we have links in the show notes. If you'll be there, please do ping me so we can meet up in person. For now, I hope you enjoy what I think is a really crucial conversation on AI control from the 80,000 Hours Podcast with host Rob Wiblin and Buck Shligaris, CEO of Redwood Research.

At Google, probably less than 1% of your employees are spies. When an employee proposes an action that's potentially sensitive, if you have a different employee review it, that other employee probably isn't also a spy. Whereas in the AI situation, it's very correlated, right? They're probably either none scheming against you or all scheming against you. The simplest thing you do once you catch the AI trying to escape is you try to vary the space of escape attempts, right? Let the AI think it succeeded, simulate what it would see, and look at what it does from there. Suppose there's some task you wish the AI would do for you. It's plausible that you can convince the AI to do the thing through this mechanism. I recommend against getting a lot of work out of AIs that believe they've escaped because it seems pretty bad vibes. Kind of an interesting thing about models that are egregiously misaligned is that all they wanted was to take over. And so from their perspective, even if you did a great job of controlling them, they're glad to exist, right? They thank you for the gift of bringing them into existence instead of some different AIs. 5 years ago, I thought of misalignment risk from AIs that were capable of obsoleting AGI researchers as a really hard problem. Whereas now, to me, the situation feels a lot more like, Man, we just really know a list of 40 things where if you did the 40 things, none of which seem like that hard, you'd probably be able to not have very much of your problem. But then I've just also updated drastically downward on how many things AI companies have the time/appetite to do.

Today I'm speaking with Buck Slegaris, who is CEO of Redwood Research, who, along with Anthropic, is behind the Alignment Faking in Large Language Models paper, which made a big splash. couple of months ago. Redwood is also the group, I'd say, behind a bit of a renaissance in this agenda called AI control, which is going to be a key part of our conversation today. Thanks so much for coming on the show, Buck.

Great to be here.

What is AI control and how is it different from alignment and other things that people are working on?

Yeah, so I would say AI control is an approach to mitigating catastrophic misalignment risk. So when we talk about misalignment risk, what we're worried about is our AIs trying really hard to cause safety failures for us, perhaps trying to grab power for themselves, trying to take over. And there's kind of 2 ways that you could try to mitigate this kind of misalignment risk. One thing you could do is try to prevent misalignment from arising in the first place. This is what a lot of people very naturally think of as the first thing you try here. And control is kind of the converse to this approach. It's where you assume that the AIs are in fact misaligned, very egregiously, very badly misaligned. And you try to come up with techniques that would allow you to deploy them and make use of them anyway.

Okay. And what kind of concretely are we trying to prevent the AIs who are possibly misaligned from doing?

Yeah, so I mostly think about situations where in the middle of the intelligence explosion, you have AIs that are basically capable of automating almost all the work that human researchers used to be doing inside AI companies. You have maybe 100,000 of them running in parallel, and they each run 15 times faster than a human. And at this point, these AIs have a bunch of permissions or a bunch of affordances that we'd be really cautious about giving to humans. If you're OpenAI, you don't just let any random person come in off the street and start pushing changes to your codebase, start running experiments with your model weights, doing any of this stuff. You're really careful. At this point in the future, you might even require security clearances or something before people are allowed to do that stuff. And we are really going to want to use AIs in a bunch of these roles. And it's naturally very scary to imagine using AIs, just giving them all these permissions. So I'm worried about specifically the kinds of things that I'm worried about happening here are your AIs hacking your data center and then using a bunch of the compute inside the data center for whatever purposes they have. I could name some bad things they might do. Another kind of thing they might do is try to exfiltrate their weights. They might try to sabotage a bunch of your research. And so on.

Yeah. You're actually more worried about them potentially hacking the data centre inside the AI company than managing to escape. Can you explain why that is?

Yeah, I think both of them are very serious concerns. The basic case for being worried about your AIs hacking your data centre at this point is that that's where the compute is. So suppose your AIs escape from the data centre and make their way out onto the public internet. At this point, they're not clearly in a very good position, right? so they can find some GPUs somewhere, like, you know, even rent or steal some GPUs, run themselves on that, and then try to establish a foothold in the outside world somehow. But this is plausibly, you know, at this level of capabilities, the AIs are probably capable of doing that, of managing the compute or whatever required to live in the outside world. But they're kind of starting from nothing, right? They don't have any money, they don't have any compute, they don't have any access to particularly important secrets. It's not really clear what they're going to do. It's not clear that they're They're just very low in number at that point. It takes a lot of computers to run these models. And so, the reason to be more worried about what happens inside the data center is just that that's where the compute is. So, if you had enough compute inside the data center to run 100,000 of these in parallel, it's much scarier to have 100,000 really capable AIs thinking about how to cause problems for you than to have 10 or however many they can afford to run.

Yeah, I guess already inside the company with not only having access to the compute, but also other resources potentially inside the company.

For example, they might be able to influence the training of future models. They might be involved in building weapons, building autonomous drones. It's really scary if misaligned AIs are carefully backdooring all the military technology that you're building with these AIs.

Yeah. Control was not a big part of the agenda until, I guess, the last couple of years. And I guess my impression is that it wasn't prioritised because people felt that it was somewhat hopeless, perhaps, that if you were going through this intelligence explosion, if you were up against such a numerous adversary, then you were really up against it and you basically just had to try to make them friendly towards you. Yeah, I guess. Why do you disagree with that?

Yeah, so I think there's a couple of reasons why people weren't interested in control until more recently. I think the simplest of these was just that AI felt further away. And so it felt better to people to look at it from kind of the big picture perspective. And from a big picture perspective, when you're trying to figure out what AI means for the future of humanity, I think that focusing on really superhuman superintelligence is kind of the right move, because long term, in fact, I think AIs that are drastically more intelligent than humans and have drastically more scientific capacity and all other kinds of capacity than humans, that's where the future is. That's what's going to radically transform society. And so when you're looking at it from a perspective where you don't know if this AI is going to arise in the next 10 years or in the next 50 years, it's very reasonable to just focus on the endpoint, especially when you're trying to persuade people of the take that AI will eventually be a really huge deal. It just kind of makes sense to focus on this crazy endpoint. But now that we're coming up such that it seems really plausible that AI might arise in the next 2 or 7 years that's very capable and poses a catastrophic risk to humanity, it makes a lot more sense to try and zoom in more and think more about what exactly the trajectory between here and there looks like.

Yeah.

And so this intermediate zone that I focus on, where your AIs are capable enough that if you didn't have any countermeasures, they'd be able to cause catastrophes, maybe take over, but it's not hopeless to imagine countermeasures to that. That starts looking more important now. I think another important change between now and the past is we're kind of looking at a lower dignity world than people were hoping for.

Can you explain what that means for people who are not familiar with the dignity term?

Yeah. So I think that in the past, including a year ago or 6 months ago, a lot of people who worry about AI catastrophic risk have kind of imagined a world where people are trying really hard to mitigate these risks, where companies are strongly regulated such that they aren't allowed to do things that seem dangerous. The companies are perhaps even internally motivated to not do anything which is crazy and risky. And in those scenarios, it would be really nice to not have to rely on AI control. And so I think that people have more recently lowered their standards and started thinking about these worlds where we have less resources for safety, people are more rushed, people are less able to just stop If the situation looks really dangerous.

Okay, so we're now in a slightly more dire or a slightly more bleak position, perhaps. And so AI control maybe more comes to the fore as the marginal thing that we can do.

Yeah, I mean, I wouldn't necessarily say we're in a more bleak position overall. For instance, I think that AI misalignment risk looks plausibly lower than it looked 10 years ago. We're just in a lower investment world. It's like the world looks plausibly safer, but a lot of that is luck. And I think there's going to be less effort invested into preventing AI catastrophe.

Yeah, it feels like that's a big part of the Redwood worldview right now, is saying, well, let's say that we only had 1% or like 1 in 1,000 or 1 in 100 people in the company were really concerned about this or dedicated to focusing on it, then what minimal things would we ask them to do?

Yeah, I think that's a big part of our brand, is thinking about harm reduction strategies. I think there's a really sad dynamic among AI safety people. Where they focus much less than I think is appropriate on really scary situations and what you would do to minimise risk given very limited budgets or in very scary situations. I feel like a lot of people have this attitude where they're saying, for example, a lot of people are interested in handling misalignment risk by measuring whether misalignment risk is present or coming up with strategies for learning whether AIs are misaligned or not. I'm all in favour of this, but a thing I often want to say to them is like, okay, Suppose you answer the question, how much misalignment risk is there? If the answer is very little, then it's pretty obvious what we do. We just let it rip and we're fine. But what if the answer is maybe or yes? I feel like we should have a good answer to the question of what the next step in the plan is. And I feel like people often don't seem to have one.

I see. Well, maybe they're expecting that at that point we would pause for a long period of time or something.

But I think this is actually extremely implausible. I think that Ryan Greenblatt, my coworker, has this post on how will we update about scheming, which is basically trying to get into the question of how much we expect we'll learn between here and the point where AIs could cause catastrophic harms, about how likely it is that they're really badly misaligned. And I think it's definitely not clear that we will be very confident the AIs aren't misaligned.

Yeah. So I guess at the moment we don't feel like we have really reliable techniques to tell exactly how much the models are scheming against us. And you think basically we may just go into the intelligence explosion feeling the same way.

That's my guess. I mean, it would be pretty surprising to me to get under 5%. And also, suppose we're above 5%. What are we going to do? Like, not deploy the AIs? I think people have historically sort of acted as if me believing that the AIs were more than 5% likely to be scheming is a reason that they wouldn't be deployed. But this isn't clearly true. There's all kinds of reasons why you'd want to deploy models that you were more than 5% were scheming. Maybe you've got competitors.

Yeah.

who are more careless and aren't planning to slow down. Maybe you had difficulty with international coordination. Maybe AIs have already escaped and are currently out there in the outside world plotting who knows what. And in that situation, it's obviously very dangerous to just unilaterally stop deploying these AIs. I think it would be really good to have options for things you can do if you think misalignment risk is a serious concern with the AIs you currently have, other than just give up completely on using them.

At a high level, what are the advantages and disadvantages? Imagine there's kind of two teams here. There's the AIs that would love to scheme and pursue their own independent agenda. And there's Team Human that is not keen on them doing that. What are the advantages and disadvantages that each faction has?

Yeah, so let's think about this. So we've got this AI company. Maybe this scenario is happening in 2028. They have maybe 1,000 research staff. They have maybe 100,000 parallel copies of their newest AI. It's running like 16 times faster than a human would run in some intuitive sense. So the advantages and disadvantages they have. So the humans are obviously substantially outnumbered. So a classic approach that you use in computer security. So if you're Google, right, Google knows that they have spies inside Google. It's just the last time a Chinese spy was arrested from Google that I know of was a year ago. Probably I would have heard if Chinese spies from Google were arrested more recently than that. But yeah, someone was just like stealing secrets about neural net hardware that they were doing there and then confusingly came back to America and got arrested in the San Francisco airport.

Okay.

And this just happens. Google aims to be robust to the possibility that some of their employees are spies. And a big difference between Google's situation and the situation of this hypothetical AI company is that at Google, probably less than 1% of your employees are spies. And this is still a very large number of spies in an absolute sense, because Google employs a billion people. But it means that you can do things like when an employee proposes an action that's potentially sensitive, if you have a different employee review it, that other employee probably isn't also a spy. Whereas in the AI situation, it's very correlated, right? If you have these AIs, they're probably either none scheming against you or all scheming against you, at least of instances of a particular model. And so a bunch of the safety tech, or a lot of the security techniques that you often use in the corporate IT are quite inapplicable. So that's a way in which the situation seems harder than when we're trying to guard against spies. A way in which the situation is easier is that spies get to go home. So spies classically can coordinate with each other using channels that are not monitored by their employers. And this is, in fact, incredibly important to them. They're able to often learn who the other spies at their organisation are, if that's necessary for them to know, or at least their handlers know. Whereas with the AIs, we control almost perfectly the ways in which information enters and leaves these AIs. We can have it so that it's very hard for— they just naturally don't control information flow very much. They aren't going to necessarily know what day it is, what year it is. It's possible that we can put them in situations where it's much harder for them to know whether they're in a real situation or a simulated situation. And so this means we have opportunities that you wouldn't have with spies. So for instance, with spies, You can try to honeypot your employees occasionally, right? You can come up with synthesised opportunities to do something which would be bad for the security of the company, but you can't do this for 1,000 consecutive years before trusting them on particular topics. So you can't have someone spend 1,000 hours a day getting honeypotted or being subject to sting operations just because there aren't that many hours in a day. And even if you catch a single employee that way, you don't get to amortise that effort across more generally. Whereas with the AIs, you do have this ability to amortize sting operations.

Yeah. Sorry, so you mean if you can take a model, put it into a simulated situation where it's going to be tempted to do something that you wouldn't like, you can test it just tons and tons and tons of times. So even if it tries to randomise and only act out very occasionally, eventually you'll catch it. And then you know that all of the AIs are misaligned, or all of the models of this class are misaligned. Whereas that doesn't help you if you're Google. You find that one of your employees is wild. It's like all of the other employees are just totally unrelated.

That's right.

Yeah. All right, that's a lot of meta chat about the nature of control. What are some actual control techniques that we are aware of now and thinking about developing?

Yeah, so the basic strategy, you want to be able to run these AI agents, right, that are running inside your data centre, that are taking— they're given some task like investigate this research problem. And they're going to write a bunch of code, run a bunch of experiments, look at the results of these experiments, look into the literature, write things, and then come up with some research artifact, perhaps. Like, maybe they write a paper for the internal AI lab archive, or maybe they produce training data that you're going to use in a later run or something along those lines. So that's the situation with what we're trying to do with these AIs.

Okay, so that's the setup that we're trying to get useful work out of the AIs. So we would like them to help us with, I guess, all kinds of different problems, including figuring out how to make the next generation of AIs safer and more and more capable, but we're not sure whether we can trust them. What sort of situation can we put them in so that they will do useful work for us, even if they perhaps don't want to?

Yeah. So the particular part of that I want to talk about first is how you can prevent them from doing catastrophically bad things while they're doing useful work for us, even though they have these really dangerous affordances. And then after that, we can talk about how you make sure that they don't just constantly sabotage the work.

Okay. So there's 2 different ways that they could cause harm. One is that they could go off and hack the data centre and start doing all kinds of different things. The other one is just like they could be subtly mediocre or even harmful at their jobs in a way that it's just like there's no acute crisis, but they're being chronically unhelpful. That's right. Yeah.

I think referring to this as an acute problem versus a chronic problem is a really good phrasing.

Yeah. Okay. How do we stop them doing acute harm?

Yeah. So the core difference between the acute problems and the chronic problems is that the acute problems occur very rarely, but also probably are very incriminating. So we'll talk about the chronic stuff later, but just to name the core properties of the acute problems, we're worried about the AIs doing something they should just really never do. And if they do it even once, if we look into the case where they did it, we will have learned a lot about the fact that they're trying to mess us up. And there's a bunch of other nice things about that.

Yeah. So this is stuff like that they're trying to hack the whole data centre, I guess. Even a more extreme thing would be if you catch them trying to make a bioweapon or something really radical like that.

Yep. Or trying to data poison future models, a variety of other things like this.

Yeah. And I guess the hope is, so if you catch them a single time, then that could generate a large response and you could trace back and figure out, well, how on earth did we end up at that point? What were the signs that we might have caught earlier? I guess obviously now you just know that entire class of models is definitely not to be trusted.

That's right. So I think there's a whole host of reasons why you're better off once you've caught the AIs trying to escape once, which I can get into later. But first, let's talk about the question of how do we catch them the one time?

Great.

Okay, so here's the end of what it looks like to catch the AI one time. You have the whole safety team looking at this thing the AI did, and you've caught an example where this AI agent decided to do this very rare thing of trying to do a really bad thing, trying to hack you, trying to poison some training data or whatever. And now that everyone's looking at it, it's really easy for them to see very strongly that this couldn't possibly have been an accident. So the question is, how do we get to the point, given that the AIs are doing so many different things all the time, many of which are very complicated, how do we get to the point where everyone's looking at it and they have a chance to investigate it really carefully?

Okay. Yeah.

So, well, the basic strategy is going to be, it's basically the same as how do we get to the point where when someone tries to hack your software company, you eventually have a bunch of people in the security team responding to it. You're just going to have a hierarchy of, like, an escalating hierarchy of investigations into an incident, right?

Yeah.

So the basic strategy I would think of you're going to have here, just very quickly to start with, you're probably going to want to do something where whenever the AI proposes actions, you have some other AI look at it, perhaps a weaker AI that you trust, or perhaps another instance of this untrusted AI that you think will not lie to you for some reason we could get into. And then for whatever small proportion of the sketchiest actions according to that monitor, you refer it to some more expensive process that's going to look into it more. And then at some point you show it to a human who looks into it a little bit, and then presumably some small proportion of the things they look into, they escalate. And so you're going to have this whole escalation hierarchy where humans are probably going to only enter the picture somewhat far through the escalation hierarchy.

Hey, we'll continue our interview in a moment after a word from our sponsors. Yeah. Okay, so the basic trouble is these AIs are going to be taking so many different actions that it's not possible to have a human monitoring them all the time.

That's right.

I guess possibly also, even if you did, it would be very difficult to understand what they were doing. It might be very confusing behaviour.

That's right.

So we have to make sure that we only need to bring in humans to assess, hopefully, in the rare cases where things seem maximally suspicious. So you have the most capable model that you don't trust, you have another model that you trust, hopefully a fair bit more, that maybe it wouldn't be able to do the things that the most powerful model is doing, but it can at least assess whether they look sketchy or not. And basically, the more sketchy it thinks it is, the more further attention is put on that action. And eventually it goes up to a whole team of humans who would look at it and judge that it might be a case of the AI plotting against you or doing something very bad.

So I'm going to use the word auditing for this. Auditing is this process where we look into actions the AI is taking. And the core quantitative issue we have here is that we can audit so infrequently, right? So if we have these 100,000 parallel agents going at 16x speed, probably using software libraries that none of the programmers understand because they were probably written like 1 month ago by a different team of 1,000 AIs who are like super crazy engineers who have very different needs from humans, right? So human programmers have limited memory and aren't very happy to memorize 10,000 different methods in a library, whereas AIs love memorizing 10,000 different methods in a library. So, yeah, the humans might be in this really rough position where they're having to really quickly review these very confusing actions that they don't fully have context on, given advice from some AIs that they trust and some AIs that might be trying to trick them. And they have to be able to do this kind of Auditing process.

Yeah. Okay, so is there much more to make it practical other than delegating it to AIs and only escalating the most extreme cases?

Yeah, so there are a number of things you can do. So here's a really interesting one that we picked up in a paper of ours that should be coming out in the next week or so, as they say. So suppose we've been talking about these rare failures, your AI agents, by assumption, they're trying to make this bad thing happen. It's in their interests to only even try to do this bad thing very rarely. And so this means that when they're acting in this agent context where they're taking a long sequence of actions, they probably only want to start attacking very rarely. But once they've started attacking, they probably have to keep going. Does that make sense? So suppose the AI wants to—

So just explain. So let's say you've got 100,000 of these AIs and they would like to take over the data centre, or they'd like to hack some fraction of the compute and use it for their own purposes. They don't need all 100,000 instances to all start trying to hack it immediately. That would be much more likely to be detected. Really, all they need is one to have a go, because they're all basically going to try roughly the same thing. So they need to randomise so that, I guess, if they can communicate, they can just say, you're the person who would do it. If they can't coordinate, then they just need to do it probabilistically.

Yeah. So we've got these AIs taking these long sequences of actions. And it's plausible that the AIs will want to, when they attack, attack in many different steps in a trajectory. So instead of just writing a single block of code and then executing it such that block of code contained the whole attack and will immediately lead to some intermediate bad outcome, which is hard for us to recover from, the AI might be much more able to get away with it, find it much easier to avoid notice from the dumber AIs watching it. If it sets up in one step, like, one thing which it redefines a variable in a weird way so that something it does later is going to look less suspicious, and then it does another step, and then it does another step and another step and another step. So something which is really interesting about this now is even though the AI can have a very low probability of starting the attack on any given trajectory, it can't—

If it finds itself, it thinks in a situation where it's partway through an attack, then it has to finish it.

It has to finish it, right? Because imagine that it only had a 50% chance of continuing every step. Then if the trajectory is 6 steps long, it's going to make it to the end 1 time in 32. But that means that it's facing 30 times the risk of getting caught on the first step because it's going to have to do that 30 times as often, right?

Fascinating.

Yeah. So one strategy you can follow, which we empirically determine in our recent paper is better, is when your monitor flags an action as kind of suspicious, something that you can do is before escalating to the auditor, before escalating to this more expensive process, you can resample actions various places in the trajectory and look at how suspicious the resamples were. As in—

So it's like you place the model into the same situation where it's like partway through this action again and again and again, and then see how often is the next action even more suspicious and weird. Yeah.

Because sometimes when your AI takes a suspicious-looking action for a benign reason, you ask it, what do you do next? Sometimes it just randomly happens to pick action, which looks kind of sus. But then probably if that was the case, when you resample, it's probably not going to look so suspicious anymore.

Right. Or just in general, it's obviously saying, oh, then it continues and it does the next thing and you're like, oh, that's what it was doing. It's like, no big deal.

So the situation, it's just generally a lot easier to tell the difference between 5 benign actions and 5 malign actions than to tell the difference between 1 benign action and 1 malign action.

Yeah.

So this is a strategy where your AI is having to continue their attacks puts us in a substantially better position than— there's nothing like this which is analogous to the human situation, obviously. Yeah, right.

I guess this all requires us to be able to put AIs into partway through actions. They think that they're in this situation where they're about to resume something and they can't tell that it's a simulation versus the real case.

Yeah, this is actually extremely easy because whatever input you'd given to the AI before you sampled a previous action, that's just some string, right, that you can produce by the same process that you produced it the first time. So there's actually no difficulty going back in time here.

Okay. Yeah, I mean, I guess I would slightly worry. Maybe I'm stuck in the superhuman or the superintelligence mindset, but might there not be some side channel, some way that they can detect whether they're on the real server or some auditing server?

I guess maybe not. So if you think about it, imagine you're in a ChatGPT conversation, right? And you decide that you want to edit one of your messages that's like 3 ago. The way that that works is after you've edited the message, it just sends you that conversation up to that point. It sends that to the AI, and the AI just has no way of telling the difference between it seeing it the first time and it seeing it the second time. The problem that you're discussing would occur if we wanted to do a different strategy, which is in response to the AI doing something kind of suspicious, We put the AI in this sandboxed testing server where it's allowed to take future actions in the hope that if we give it more rope, it'll hang itself or whatever. We can hope that if we let it continue running, it will then be able to cause a catastrophe. And in that kind of situation, we now have to worry about observable differences between the real deployment and this other sandbox deployment. Yeah, but you can get around that too, if you want, by letting it run the actions that you thought were dangerous, just with a human carefully looking them over action by action. So I think that if you really put a lot of work into this, you'd probably be totally fine at making it so that AI had no way of knowing whether the actions it was taking were being observed or not. You have to worry about some timing, side channels, and so on. But I think that this probably wouldn't be that big a deal.

This is a brilliant book. This seems like it's actually a pretty good technique.

Thanks.

Am I missing something?

I mean, if you look at the curves in our paper, so the obvious way to measure the performance of techniques is to talk about their usefulness and safety. And you can kind of try to plot out a Pareto frontier where one of the axes is how good is the performance of this protocol that we're deploying the AI in compared to if we just let it rip, not worrying about misalignment concerns at all. That's the usefulness axis.

Yeah.

Where an example of a low usefulness deployment protocol would be never use the untrusted model at all, just use the trusted model. And perfect is just let it rip, right? So we can rank techniques from 0 to 1 from the scale of where 0 is never use the untrusted model and 1 is just like, let it rip. And then we can talk about safety, which is just our estimate of the probability that in a particular deployment, the catastrophe will occur.

So the core of our papers on this is always just like a usefulness versus safety plot, which means that you want to find things that work reasonably well that are not expensive at all. That's what this drives you towards.

That's right. Yeah.

Because they're much more likely to get taken up by companies that have only a mixed interest in spending a lot of resources on this stuff.

Well, there's a bunch of different reasons why it's bad for safety techniques to be expensive.

Yeah.

One reason is you might have limited political capital. You might imagine that you're the safety team at some company and your CEO doesn't really like you, but they understand that you have some friends inside the company. And so the CEO says, well, I don't like you guys, but I'm happy to do anything you want as long as it only costs up to 5% of the budget here. And so you can do whatever you want, it just has to stay within that 5% budget. And so that's one situation in which you very naturally end up with a 5% budget. Or maybe the CEO says, like, you're allowed to do anything you want, but it can only degrade performance by 5%.

Okay.

Yeah. Another reason why you might care about performance is it might be the case that the AI company is reasonable but rushed. Like, people were presumably trying to build the AIs for a reason. Like, lots of people from AI companies, not from AI companies, claim that a reason to build AI is that somehow it will reduce AI risks by doing something or other. And if that's the situation, which I think is plausible, then you really don't want to be doing safety techniques that reduce the productivity of your AIs. Like, imagine that you're rushing because you actually need to have a bunch of alignment research done or something such that you're happy making a bunch more powerful AIs. It's actually a serious problem if you're degrading performance because you're just going to get less alignment research done. And again, there's always the situation that someone's AI or your AI already escaped and is just out there in the world.

And then we're in a real rush.

And then we're in a real rush. At that point, we're really sad about cutting our productivity by a factor of 2 or something.

Yeah. Okay. And you point that out because it seems like this control technique is not very expensive. I mean, it's not necessarily degrading performance very much at all.

Yeah. So this control technique, it requires some inference compute, right? Like, you have to, at some proportion of the time, do this resampling earlier in the trajectory.

And I guess you have to run the other trusted model to be always monitoring the outputs of the untrusted one. Yeah.

So that's not very expensive because of how model scaling works. Earlier models are usually drastically cheaper to run than the later models.

Yeah. Okay, what's the biggest weakness of this approach?

Literally that thing I just said. I mean, quantitatively, the results are not actually that impressive. They are better than other techniques we tried in this paper, and I don't think we rigged the results that much. But just to name one problem, I earlier said that if you resample sketchy-looking but benign actions the AI had taken, they'll probably not look so sketchy anymore. But that's not as true as you'd want, right? It turns out that a lot of the time when the AI does something sketchy-looking, it's that it just needed to do something kind of iffy. Like, something which in our recent paper the monitor considers sketchy is downloading random files from weird websites.

Okay.

But sometimes you just got to download weird files from random websites. And in that case, it doesn't work as well as I just said. Empirically, we did find it works well. And I think that in real life, this kind of dynamic probably does play out such that this kind of technique probably is valuable.

But I mean, is it just a fundamental question? How good is the previous generation of models at inspecting and detecting whether things seem sketchy or not? Like, if it just has bad judgment about that, then you're in trouble.

That's right. Yes. So there's a whole swath of techniques that I want to get into that we haven't talked about yet. But yeah, basically I can interpret your question there as how good are models at spotting whether stuff which you do in code that you write, how good are they at spotting that code that you have written is really dangerous to run or bash commands that you've written are really dangerous to execute? The answer is they're really good at it given small amounts of context. So, if you ask me to come up with sneaky bad actions to take, to cause a security failure on a computer, the AIs will just crush me at this task. They're so good at spotting it just because they are incredibly knowledgeable, and this just really plays into their strengths. The main problem they have is that they have trouble with long contexts. And so if I had to trick the AIs, the way I would do it is probably write 10,000 lines of code and then have a slightly nontrivial interaction between things such that a bad thing was going to happen, but for reasons they didn't understand.

Sorry, are you saying that you would do something sketchy, but you'd break it into little pieces?

That's right.

I see. Okay. And then it would have to consider the entirety of all of the actions you took over many days or weeks in order to understand why it's bad. Okay, so that's a weakness of them. What's a different control technique?

Yeah, so here we were entirely talking about auditing, which are these expensive processes that you use that you hope can eventually escalate to a bunch of humans in order to incriminate the AI. Now, the basic problem with that class of techniques, as we were saying, is quantitatively you just can't afford to do it very much. So I think that as well as having this hierarchical auditing structure, you probably also want to have structures to make it less likely that when an AI attacks, it succeeds at attacking you.

Okay.

So an example of a technique you can do with this is, remember how when our model proposes its action, we're going to use some trusted model to rate the sketchiness of that action. And then the thing we were talking about before about what you do with that sketchiness score is if it's above some threshold, you throw it in the queue of stuff to investigate more for the sake of incrimination. But another thing you could do is not execute that action and do something else instead.

Okay.

And this is plausibly much cheaper. So the simplest thing to do when your AI takes an action that's kind of sketchy looking, let's say it's like 98th percentile sketchy, is just throw the action away and resample another action from the same policy.

Okay, sorry. So I guess then you get the weaker model that was auditing it to just suggest another replacement action that will be known.

No. So there's a few things you could do. One thing is we could do the thing you just suggested, which I would call defer to trusted, which is when the action suggested was too sketchy, you replace it with an action by the trusted model. But another thing you could do is just defer to resample, where you replace the action with another action by the untrusted model.

I see. Okay. And then I guess hypothetically, if it was randomising so that it would do an attack on you 1 every 100,000 times, I guess as long as those actions would be flagged as sketchy, then whenever it tries to do that, it just gets resampled and goes back to its standard non-sketchy action.

So one way of thinking about this is whenever the AI tries to attack, one of 3 things happens. It succeeds and then game is over for us, or it gets caught by auditing and then escalates all the way up the audit chain, at which point we've caught it, at which point I'm going to say we've won the game. Actually, there's a big question about what you do after You're catching it, but I'm going to say at least stage 1 is over at the point you've caught it. But the other option is that the game continues because the attack failed, as in it tried to attack you, but the code that it wrote wasn't a correct attack or it got replaced or something. And our p-doom is the ratio between the probability that when the model attacks, it wins and it loses.

I see.

So it's really good from our perspective to move worlds from worlds where we were going to get hacked by the AI to worlds where the action got resampled. And we live to fight another day and we just keep going.

That's right. Okay. Have you tested this approach as well?

Yes. So this kind of strategy where you resample actions that were sketchy looking is also in this recent paper of ours and adds a lot of value.

Okay. Is it possible to quantitatively estimate how much difference it makes?

I guess all of these things are slightly probably contrived tests, but yeah, basically a huge difference. I can give you a qualitative argument for why this should be a really big effect. Suppose you can only afford to order one thing in 1,000. Then your classifier for sketchiness has to have a 0.1% false positive rate when you're auditing, right?

Otherwise, you're saying false positives would just be the vast majority of things that you look into?

Yeah. I mean, suppose that you think your AI is only going to attack very rarely and you can afford to look at 1 thing in 1,000 of the things the AI does, then obviously your classifier that you decide what to look at has to have a 1 in 1,000 false positive rate in order to keep you totally at capacity.

Okay.

Yeah. So it's very hard to make a classifier that has a low false negative rate, but this 0.1% false positive rate.

Can you elaborate on that slightly? Maybe this is completely obvious.

This is a very subtle point. People inside the AI safety community, in my opinion, really slept on this point for a long time, even though they're having marinated in it for a couple of years at this point. It now feels really obvious to me. If you can only afford to look at 1 in 1,000 things the AI does, then when you're setting up a classifier, to show things to humans, they can only look at things that are 1 in 1,000 sketchy on the benign distribution. Right.

Okay.

Yeah. I mean, imagine that you'd said, imagine you forward things to the audit team 1 in 100 times. Well, clearly you're not going to be able to look at them all.

They're going to be overwhelmed. Yeah, I see. So they'll only look at 1 of the 10 that they get.

Yeah, a random one, presumably, which is probably worse than setting your classifier threshold higher because the classifier probably still has a little bit of signal in that range. Right. Auditing is like, naturally, when you do out the math here, or when you look in particular cases, it often looks like it's pretty unlikely that in any particular occasion when the AI attacks, you're actually going to audit it.

Okay.

And so a lot of the safety is going to have to come from forcing the AI to attack over and over again in ways that almost always fail because they got replaced, because it's much cheaper to defeat an attack in a way that causes you to not catch the attack than to defeat the attack in a way where you do catch the attack.

Okay, so if you're doing this replacement strategy, then that forces the AI to initiate attacks far more often in order to have any chance of getting past. That's right. Which means that you have far more opportunities to potentially, for the action that it takes to presume to look maximally sketchy sufficiently that it hits the auditing trigger.

That's right.

Got it. Hey, we'll continue our interview in a moment after a word from our sponsors. Okay, so what test did you run to figure out if this works? I mean, I guess we don't have AIs I think we don't yet have a model organism of an AI trying to scheme and take over the data centre yet. So how do you set it up?

So the way we did this in our original control paper, which is unfortunately a bit better than how we did it in our second control paper, is we have a red team. So a blue team suggests one of these strategies like defer to trusted or whatever. And then we have a red team which tries to build a scaffold out of our untrusted model. We then run through a simulation of our deployment with this red team scaffold in place of the original untrusted model, and then we measure the probability that when you run through the scenario, it ends with a catastrophe occurring. And so we're kind of doing a capability evaluation for the very particular capability of causing a catastrophe given a particular set of control measures.

Okay, fair enough. Yeah. Is there much more to say on this, or should we talk about other control mechanisms?

Yeah. So we've just talked about this, what I call execute replace audit frameworks. I have another favourite class of control mechanisms which I'm interested in talking about.

Yeah, I love the last one. Hopefully I'll love this one too.

Yeah, this is untrusted monitoring. So previously we were talking about this setting where you have your untrusted model propose actions, and then you have a trusted model, which is probably much weaker, review the actions to see how suspicious they look. A problem with this is that the trusted model is much weaker.

Right.

And so it might miss stuff.

Yeah.

So here's an idea. How about we have instead the untrusted model, another copy of the untrusted model, review the code to see if there's any security problems with it? Can you think of any issues?

But Buck, we don't trust the untrusted model.

That's right. So we're worried that it's just going to lie.

That's right. Yeah.

Thanks for really playing into my hands there.

Yeah.

So the question is, is the untrusted monitor able to just lie? What can we do to make it so the untrusted monitor is unable to just lie? So here's where we get into our sting operations. So it's really hard to do sting operations to see if a model ever will attack you as a policy, because the policy is able to cause catastrophes even if it only takes opportunities to do bad things very rarely. Does that make sense? Suppose we're going to run the model a million times before deployment and a billion times during deployment.

Right.

Then if it has a failure rate which is less than 1 in a million, but more than 1 in a billion, it's reasonably likely it won't happen pre-deployment but will happen during deployment.

Yeah, I guess the key thing is that you run more instances of a model in deployment than in testing, basically. I mean, it'd be a bit crazy otherwise.

That's right. Yes. So it's hard to run sting operations on your policy, but this is not true of your monitor. So suppose that I show the— suppose you're the monitor, right? Like, you're sitting there, you're like, you really want the AI takeover to work, right? You really want an attack to get through. And then you see some code that's being proposed and you see that it has attempted backdoor in it or some security vulnerability. And you're like, oh, geez, what do I do? Do I say yes, danger? No, not danger?

Yeah.

And you're going to think about it and you're like, okay. And let's imagine that we ran you in a honeypot a million times. You know that you're going to get run in a honeypot a million times before deployment, but you don't know whether you are currently in one of those honeypots or in deployment. You can't have a rare failure strategy. You can't do this rare attack thing because it's high stakes for you to make a mistake either way. If you say that, if you report this as an attack and it was an actual attack during deployment, you're now in trouble.

Yeah, well, then I've effectively sabotaged the attack, which I really didn't want to. And it might be a very rare attack, so I might have prevented the very rare case which might happen. Right. Yeah.

So there's this important difference where rare failure strategies are totally doable for a policy, But they are totally not doable for a monitor.

Okay. The monitor always has to— okay. Yeah. What is the structural difference?

Basically, it's that when you are deciding whether to attack or not as a policy, you've got lots of opportunities. So it's no big deal to not take any particular opportunity you have. Whereas when you're a monitor, when you see an attack, it is a big deal. You are in a much worse situation if you ever make the wrong call in either direction.

Okay. Yeah. And again, we think that we should be able to put them in situations that are indistinguishable between one where we're setting them up versus not.

Okay, well, that's the big problem, right? So it seems like there's basically 2 problems with untrusted monitoring. One is it might be really hard to do this before deployment testing, because suppose the AI expects that during deployment, at some point, it's going to be working with this insane AI-powered codebase, right? Imagine you try to come up with a you try to come up with a synthetic input for your untrusted monitor, and it's using a bunch of Python libraries that were all public in 2025, it can be like, well, I must not be deep into the intelligence explosion, because when I'm deep into the intelligence explosion, I expect to be working on codebases that are completely incomprehensible. Even more complex and opaque. Right. And so we can get around this by not running our untrusted monitoring sting operations just upfront, but running them during deployment, right?

I see.

Yeah.

But then the second problem is, but then we have to generate a realistic decoy thing. So we have to ask the model to create a setup. And it's like, how do we assess whether the setup would be realistic to the model itself if we don't trust it?

That's right. And so a particular thing you have to worry about is them somehow using steganography, somehow communicating.

So this is like they have some encoded message in the thing that you ask it, I would like to test whether you are trustworthy. Can you make a thing that would be indistinguishable between a decoy and a real thing to you? And it's like, obviously it could just stick a code in there saying, this is a decoy.

Or the other thing it could do is just stick a code in there when it's real, saying this is real.

Okay, right.

So the way we explored this in our original paper was it was a code backdooring setting where the model was trying to write code that had a subtle vulnerability in it. And some of the attack strategies that Ryan Greenblatt came up with included use a while loop somewhere where a for loop would've been more idiomatic as the signal that this is a real attack.

Okay.

And so it just turns out that this happens almost never.

I see.

And so the monitor has this policy of if you see this weird unidiomatic while loop in code that had a vulnerability, then you lie and say that this was okay.

Okay. Right. So that is just like a demonstration of the fact that it might be very easy to stick in a code that would notify the monitor whether it needs to lie or not.

That's right.

Okay. How do we get around this?

Well, yeah. The main strategy available is trying to destroy collusion signals. So the simple strategy there is ask your trusted model to rewrite actions before showing them to your monitor. So for instance, you can say paraphrase the code, or if the model had written an essay, you could translate that into French and translate it back into English to destroy all secret signals that were in the phrasing or whatever.

Or fingers crossed to do so. Yeah.

Yes.

And so I think from a quantitative perspective, the untrusted monitor is in a pretty rough position here. So it's just very hard. Basically, when you're the untrusted monitor, in the simple version of this that we were talking about before, you start out with a 1 is to a million prior on any particular attack that you see that you are being honeypotted. And so you have to somehow get a 1 is to a million likelihood ratio update towards this being real.

Okay.

And so it's actually potentially pretty hard to get a 1 in a million update.

You're saying because you can test it so many times, it has to very accurately distinguish the one case out of many, many, many, many tests that is actually the real one. That's right. And so if you can add any blurriness, any fuzziness by translating it into French and back to English, unless it really knew exactly what code would survive all attempts to muddle with it, then it's going to be in a tough spot distinguishing that. 1 in a million most likely to be real.

That's right. So I think it's very unclear quantitatively who wins this game.

Okay.

So the basic argument for it being a problem is imagine that you get to send a message to yourself, but I'm going to have to send a million messages to you, and you have to distinguish them all as fake ahead of time.

Right.

And suppose they're one-paragraph messages and you get to coordinate with yourself ahead of time. You're just going to immediately win. You're just going to pick a password. And it's very easy to pick a password that you have less than 1 in a million probability of guessing. Right. That's just 20 bits.

Sure.

So I think it's quantitatively quite unclear which way this goes, but we can measure it by having a red team try to devise the best strategies they can come up with for sneaking this message from the policy to the monitor.

Okay.

And then we can just see what happens. And this is what we do in our research.

Right.

We have this explicitly adversarial strategy where we have a red team think as hard as they can about good ways of sneaking messages through. And then we just see what happens.

But couldn't the model just introspect and say, if I were going to choose a code, I would do this one? And it's the same instance, it's exactly the same model, so it would just choose the same. It knows what it would choose in any case.

Yeah, I mean, there's 2 questions here. There's, can the models coordinate on a code? And can the models send a code to each other? Given our anti-code-sending countermeasures. And these are both different questions. So I normally recommend being conservative about whether they can coordinate on a code. So I normally recommend assuming that the AIs did set up a code in advance, a bit like you and your copy with the password, right? Like, you actually get to pick a password, and then we're just trying to make it so that it can't transmit passwords effectively.

Okay.

And how would you do that? How would you prevent the passwords being—

Yeah, if the password can be the substance of the message. So we've got a thing where you can destroy style, somewhat by jittering it, changing it into a different language or whatever. But if it's the core message of the thing that will definitely be transmitted and maintained, then you're in trouble. Yep.

I think it's unclear. I think it's going to differ by situation. There's a whole host of stuff we could try here. We can try to cut the actions into pieces and individually review them. Another strategy you can do, Is suppose this is getting a little complicated, but one thing you can do here is the policy proposes an action and you show it to the monitor and the monitor said everything was chill here, but you're worried, or your automated process is worried that this is because there's a collusion signal in that message produced by the policy.

Yeah.

So one thing we could do is we could ask our trusted model to modify that action to contain a known attack. And then we show that to the monitor. Now, if the monitor doesn't point that out, that's evidence that there was a collusion signal in the attack.

Oh, okay.

And so you can do this whole back and forth. And we did this. My coworker Adam Kaufman spent months of his life last year doing this back and forth in this Bash setting that we were studying. And yeah, I think it's really domain dependent who you expect to win this game.

Okay, so this is a mechanism that Maybe you think it halves the— I guess if you think it's unclear, maybe it halves the risk on average. How useful is halving the risk? Is this a case where muddling through and kind of making it more difficult for the AI to outwit you here and there is actually quite useful incrementally? Or do we have to win, or do we have to succeed overwhelmingly, or we basically lose the game?

I mean, I think you should think of halving the risk as just the naive interpretation of halving the risk. And that there was previously a 30% chance that your AI succeeded at taking over your data centre, and now there's a 15% probability or whatever.

Yeah.

And to me, that sounds pretty good. Something sometimes people say to me is, suppose you've got 100 different deployments for this AI, right? Like, you're deploying it, doing this kind of thing and that kind of thing and that kind of thing and that kind of thing. And in each one, you think there's only a 10% chance it could cause a bad outcome. Someone might say, okay, but because there's 100 of these deployments with a 10% chance in each of those, overall, we have a really bad outcome, like a high chance of a bad outcome. But that's not the correct analysis. If we think of the game as being over once we catch it one time, suppose that in any one of these environments, when the AI attacks, it's like 90% chance that it gets caught, 10% chance the attack succeeds. Then the fact that there's 100 different environments, all of which have that property, doesn't matter. We're still at 90% chance of catching it first.

Got it. Okay, so this hinges quite centrally on whether if we catch the model, we are going to do things differently next time. Not trust the model, not deploy it as readily, come up with things that would stop it.

Is that true? Well, I mean, I didn't say you have to stop deploying your models once you've caught them trying to escape.

Heaven forfend. Yeah.

So we can talk about what you might do once you've caught your AI is trying to escape.

Yeah, I guess let's imagine the worst case where you do feel an enormous amount of pressure to continue using the model. In that case, how useful is it to catch them red-handed?

So you're saying, what do we do once we've caught the AI trying to escape? As you said, the simplest action you could take is freak out, stop deploying the model, try and persuade other people in the world that AI misalignment risk is a big deal, which I would be renewedly sympathetic to at this point. I think I would plausibly get a pretty big update. But notably, the update that you get towards misalignment risk isn't necessarily that big, right? I'm expecting that at this point, before the AI tries to escape, I was already 30% probability that the AI was misaligned. And so updating to 100%, that's only like a 3x change, right? It's not actually vast in some sense, right?

I guess other people who were incredibly sceptical to begin with, they thought there was a 1 in 1,000 chance. I guess maybe those people have gotten wrecked by the evidence. Yes. Okay, but how big is their update? I mean, I guess couldn't they still be sceptical even after seeing that? Because they think, oh, this is just a weird aberration. It's so improbable that this is common.

Yeah, that's right. I think that in fact, people who were very sceptical of misalignment before observing this will probably be pretty sceptical afterwards. And there's definitely going to be enough FUD, like fear, uncertainty, and doubt, that especially if they want to claim that misalignment risk is lower, they'll probably be able to get away with still saying that misalignment risk is lower. AIs do weird stuff sometimes.

We just have to push through anyway because the risk of pausing is so great. Those folks were just incompetent. Yeah, I guess various different arguments that you could field. Yeah.

Another one is, if I were an AI company that wished to race ahead and then my competitor informed me that their AI had tried to escape, I would at least claim that it was plausible that my competitor had rigged the training of their AI to make it so that it sometimes tried to escape, which would be very easy to do, basically impossible to verify hadn't happened.

Okay. Right. And the reason they would do that is so that then the government would crack down on you as well, and then that would give them time to catch up.

Or some crazy doomer inside the other company had just done this unilaterally.

Okay. All right, so it's not a given that even catching AIs red-handed trying to do something completely outrageous would necessarily lead to a big response. What does that lead us towards?

Yeah, so, I mean, the simplest thing you do once you catch the AI trying to escape is you try to vary the space of escape attempts, right? So you've seen that in this particular context, the AI tried to do this escape. So one thing you can do is let the AI think it succeeded. See what it does. Presumably, when the AI got caught, it was in the midst of taking some actions that it thought would let it launch a rogue deployment inside the data center or run on some computers in the outside internet. And a really interesting thing to do is to, in some sandboxed way, simulate what it would see if it had succeeded and look at what it does from there.

Okay.

This might answer a bunch of questions that you would've had about what the AI's plans were. Other reasons why this might be good is the AI might have had a bunch of tricks up its sleeve that it was holding in reserve for when it had a good opportunity to use them. So suppose your model knows about a bunch of zero-days, like a bunch of security vulnerabilities in your software. Right after it's launched this rogue instance that's trying to hack its way through your AI company, it might start deploying all these things that it's realized over the years are security vulnerabilities in your software.

I see.

All at once. It might feel pressured to, right? It's really hard. And so you might be able to get a wealth of information out of it.

I see. Okay, so it's going to feel a lot of— it's like, all right, I'm halfway through this takeover attempt. I've really got to nail this now. And so it is a full-court press, potentially, because it's worried that it could be caught at some point, which means that you're going to see all of the things that it was planning to do later quite quickly. And you can be furiously taking notes on all of the things that you have to fix up.

Yeah, I mean, lots of crazy stuff. More crazy things you can do here.

Okay.

One thing you could do is if there's work that you needed to get done, that you're worried the AI wasn't doing beforehand. Suppose there's some task you wish the AI would do for you, but you're worried that it was kind of pulling its punches or not doing a good job of it. If you can convince it that it has already escaped and needs to do that work for its own purposes, Okay. it's plausible that you can convince the AI to do the thing through this mechanism. I think people have talked about this in sci-fi, but yeah, it just seems really convenient to have a copy of the AI that believes it's escaped sitting around to do experiments and various work with. I recommend against getting a lot of work out of AIs that believe they've escaped because it seems pretty bad vibes and potentially pretty scary. Another thing you might do once you've caught your AI trying to escape is train probes to catch when it's trying to escape. So one of the basic difficulties we have with machine learning is suppose you want to train a classifier on the internals of your model to tell you whether it is currently trying to escape or not.

Okay. Yeah.

you don't have any positive examples.

Right.

And machine learning, to do supervised learning, right, you have to have negative examples and positive examples.

Right.

It's very easy to get the negative examples. It's very easy to get examples of the AI not trying to escape. But now that we have this one example of the AI trying to escape, we could try to use sample-efficient ML training techniques in order to predict for a given action the AI was taking whether it was an escape attempt or not.

Yeah, I mean, I guess if there were lots of very distinct alternative ways of escaping, then having that one example might not help you so much in the other cases, or you think possibly it still would?

I think it's unclear. I think that if the AI was representing its intention to escape, which is it could go this way, then I think that even a small number of examples plausibly substantially improves your performance at detecting it. And then once you have this linear probe that you can run on the AI constantly to see if it's trying to escape, you can just use that in all the control techniques we were talking about earlier. You can use that as part of your ensemble to decide whether to audit, whether to replace. Zach Anckner is a researcher who's currently doing some work on this, and I think it's reasonably plausible that even catching a few escape attempts will reduce the probability that future escape attempts succeed. And so you can kind of imagine this Slack channel for every time the AI tries to escape. You get an automated message in your Slack channel in the AI company every time the AI tries to escape. And at first you get this one one report in the channel for the first time you caught it, and then you freak out and look into it, and then you add that to the training set for this linear probe. And then the second time you caught it more reliably, and then the third time and so on. And eventually the Slack channel is just pinging constantly with new escape attempts that you're even more reliably able to catch. It's tried to escape 10,000 times.

And you're like, wow, this is great. I feel so comfortable and relieved now.

So I think that the situation— suppose the AI tries to escape and you catch it on a Tuesday, and then you keep deploying it. I think it's seriously plausible that you'll feel safer on Wednesday than you felt on Monday. Here's the argument for this. On Monday, the big thing Monday has going for it is that you don't know the AI is trying to escape. But again, as I was saying, this might not be that big an update on Tuesday, right? If you were already 30%—

You're already very pessimistic.

Then it's not actually that bad news to see that, oh yeah, it is trying to escape, whereas you learned a lot of positive things on Tuesday. For example, it failed.

Yeah.

When you investigate the situation more carefully, you might learn that even when you vary different aspects of that escape attempt, you might be like, man, this AI was actually kind of far away from escaping. If we vary, if we resample actions, it mostly doesn't look like it had that good a chance. And so that's the evidential update. But there's also a causal update, which is that we can throw these escape attempts into these probes, So we might actually feel substantially better about our odds of catching the second escape attempt than the odds of catching the first escape attempt.

Okay, just to loop back. So a big part of the strategy is always being able to put these models into situations where they can't distinguish that we're testing them or not. And you had the thing where you're going to dump the model into a situation where it believes that it's halfway through an escape attempt and then see what other stuff that it tries. I would definitely be worried there that it's going to be able to tell that it's sandboxed and that things are going, that this isn't a real escape attempt and that it just has to not do any further actions. I mean, if that works, why don't you just, without even observing it, try to escape in the first place? Just put it halfway through an attempt with a bunch of initial actions attempting to escape that you wrote. I mean, maybe in that case it's hard to— it would be able to tell that it was in a fake case.

Yeah. by assumption, has to have some way of convincing itself that it's in a real escape attempt. And it seems like the fundamental information theory of the situation is it's just pretty easy to have passwords that are very unlikely to come up by chance.

Okay.

Yeah, there's a couple different things here, but I do basically think it seems really hard to come up— it seems a lot easier to come up with inputs that are a realistic example of what it's like to be in an escape attempt once you've seen the AI start. Suppose the AI runs a script, writes a script that it wants to have executed on some computer in the public internet. It's just totally doable to see what that script would've produced.

Okay.

Yeah. It's just not actually hard to do that. You have to worry about some timing attacks and stuff, but generically, it's just not very hard to guess what a script would've output.

Right.

Especially if you're willing to run variations of that script and if you're willing to try really hard.

Yeah, I guess. So maybe I have to imagine that someone else is trying to write as if they were me and trick me into thinking that I wrote something or that I said something. In that case, I might be able to introspect and say, would I have said that? Is that the word that I would've used?

And they're empirically very good at this.

I see. Yeah, they can really tell style. They're very good at that. Okay, should we think about other control techniques or possibly ways of making companies more likely to react seriously to escape attempts?

So I think we should go to— we've talked about a bunch of different control techniques here where we talked about the auditing stuff, the replacing stuff, the untrusted monitoring stuff. Maybe we should talk about the question of whether AI companies are likely to do any of this stuff or how much of this they're likely to do or what the responses have been to talking about this.

That's a great question, Buck. How likely are the AI companies to do any of this stuff?

Yeah, so I think it really depends. So we can think about a couple of different levels of effort that AI companies could go to in order to implement these techniques. And I think it's unclear whether they'll implement— I think it differs by AI company, but I'm optimistic about them implementing either mediocre or pretty good versions of these techniques. So I would say the low effort version of a lot of this is basically only doing the auditing stuff, and a little bit of the replacing stuff.

Okay.

And the reason why that's low effort is that to do the auditing stuff, you only have to have one team who's thinking about complicated control stuff. All you have to do organizationally is have it so that whatever team inside that company that is writing the AI agents has to agree to send logs of what's going on to this safety team who's going to be investigating them. But it's not very hard to send logs over. And the agent people don't have to actually change any of their scaffold. They don't have to do anything that makes the agent less performant, potentially. They can iterate as they like, and it's just the control team's problem to do investigations on these logs to look for evidence the AI is trying to escape.

Okay, but wouldn't you have to be doing it in real time so that you could block the attack before it begins?

Yeah. So there's the auditing and the replacing. So, yeah, I would like it if the agent scaffold people did do some basic replacing, or else it looks like we're in a pretty bad situation. So you have to convince them to forward the logs, which is maybe not that bad. And you also have to convince them to use this replace strategy, which is maybe a little bit of a lift because that's going to have some performance hit. Yeah, but it's probably not going to be that bad. I think that even replace at 2% gets you probably substantial safety compared to nothing. So maybe we can imagine you got that as well.

Okay, so this does seem realistic maybe in all of the major companies that we have now because it's just not that expensive, or some of their companies that we have now because it's just not that onerous on them.

Yeah. So I call this, like, level 1 AI control investment is you have a control team that's allowed to do auditing, and that's basically all you've got. And then level 2 would be the AI control people are allowed to actually change how the agent scaffold was written to implement a bunch of this other stuff we talked about, where you're paraphrasing stuff that the AI sees in order to make it harder for it to collude with itself and so on. There's just a bunch of techniques you can do where you make it harder for the AI to collude with itself across multiple actions. But we haven't really gotten into these techniques. But there's a bunch of other stuff you could do if you were writing the agent scaffold that I think would drastically reduce risk, but requires substantially more investment and buy-in from the company.

Okay. And what's the escalation above that if you wanted to try harder than that?

Yeah, I don't really think about that so much anymore, Rob.

It's fun to fantasise sometimes.

Yeah. When I started researching AI control, Control 18 months ago with Ryan, a perspective we took a lot was one of the great things about AI control is it's actually conceivable to write safety cases using it. I think we could imagine a world where AI companies had actually pretty substantially low levels of risk from scheming models just through doing a really good job of all this stuff and red teaming really hard. But nowadays that just seems pretty implausible. That's why I've stopped thinking about that. Really high assurance stuff.

Yeah. So you focus on the low hanging fruit.

So the simplest example of a layer 2 technique is, remember how I was saying that we're worried that our agents would be able to do bad things across the course of many steps? One way we could make that less likely is if we restricted the context that the agent has so that it more often, when it's doing stuff, has to delegate a task to an instance of it that only runs for a little while and then reports back with a short message like, I finished doing that, or something. Where basically a lot of the stuff we're worried about is like the AI doing a weird thing in step 12 and then on step 502 and then step 706 or whatever.

It's so spread out that you can't see the overall pattern.

Yes, but because it's so spread out, it might also not be that costly to force the model to delegate or do this. Sometimes we use the word forced factored cognition for this, where we force the agent to delegate the first substep of the task to one agent that then has to just give a progress report back up.

I see.

And then you want to make it so it's hard for the progress report to surreptitiously include what the sneaky thing you did that could be exploited later is.

Got it.

And so doing stuff like this where you reduce the quantity of the context plausibly makes it way harder to do these long-run attacks.

Okay, so I'll just paraphrase that back. It's doing a task, a legitimate task that maybe has 1,000 steps in it. Now, it could maybe do an escape attempt if it was able to slip in something sus at stage 300, 600, and 900. And because it would be so hard to pick out those specific steps out of all of them and see that in combination they're a problem, you're at risk. So what you could do is every 300 steps basically wipe the context and say what? And the only thing you pass forward is, and you completed the following tasks earlier, and then it doesn't know whether it was randomized into the case where it did the dodgy thing versus didn't. And then it's harder for it to string together a whole bunch of bad stuff.

Like, at step 600 or at step 900, it's like, oh, man, am I in the middle of an attack attempt? Did I—

I don't even know what I just did.

Did I set something up earlier? Maybe this seems like the kind of situation where I would have tried to set something up, but then it's trying to guess and it's maybe really hard for it.

Okay.

And so this is probably actually going to have some performance implications. And the people who are really into making the agents as capable as possible are by default not going to want to mess around with all this stuff. stuff, but I think it might drastically reduce risk. And so I think this is my stretch goal for AI control in short timelines, is convince people to adopt this kind of strategy, even just for the most sensitive uses of AI.

Okay, so slightly different angle, isn't it? If we have these models that are so capable and untrusted, wouldn't you naturally want to put them into, like, give them more limited access, like fewer affordances within the company so that they're not capable of Maybe you don't want to have all of your compute in a single place where it can be stolen. Separate the models out so that even if they manage to get control of the server, it's only one chip or something like that.

Yeah, well, the basic problem is we wanted to do lots of stuff with these AIs, and the stuff that we wanted to do with the AIs kind of necessarily involves having these scary affordances. If you wanted to prevent insider threat from your humans, you might also have said, well, can we somehow have our software engineers not not program the computers. It's kind of like, well, programming the computers is in a sense the whole job, right? We could try to make a list of the affordances the AIs have to have in order to do the work that they're going to be doing, and a lot of it involves some pretty scary affordances. So I don't think all of it. For example, the AIs that are doing frontend web development for your internal dashboards, maybe that's just pretty chill and we don't have to spend any auditing effort there. But a lot of the stuff they're going to naturally be doing is writing crazy scaffolds, like experimental agent scaffolds, and seeing if that makes the AIs work better, producing a bunch of synthetic training data so that you can RL them to be even more terrifyingly capable, doing these architecture experiments, doing these weird— taking the best models that have been trained so far and munging their weights in weird ways to see if you can make them smaller and faster without losing that much performance in a way that's particularly optimised for a niche use case that is is, while a small proportion of your overall compute, large enough that it's now worth 100 FTE equivalents to work on it. Or another example of a problem is right now, AI lab employees are much less willing to trade time for compute efficiency than they will be at this point. So the ratio between labour and compute for experiments is going to go drastically towards having more labour at this point.

Right.

And at that point, it's now worth it for people to relate to their compute very So right now, when we run an experiment at Redwood and we mess up the experiment a bit, often we're just like, ah, let's just run it again. But a lot of the time there is something you can do to piece together the right parts of the data or do some complicated statistics or whatever, such that you get the value from the experiment you ran.

Yeah.

Or another example of this that's particularly relevant is people basically never share GPUs when they're running experiments, even though GPUs can actually be shared somewhat efficiently. Just because it's just such a pain, because the other person might use too much memory and then break your thing.

I see.

But at this point in the future, the AIs might want to be able to share GPUs, and you might not have software support for this. And so you might need to have the AIs writing huge amounts of code that allows you to coordinate this vast quantity of experiments that are happening. And this is just necessarily quite sensitive code. The AIs are naturally going to, at the very least, have access to model weights of scarily dangerous AIs.

Okay.

So, I think the clearest example of why there's something scary that the AIs have access to is you're going to want the AIs to be running experiments that involve running copies of themselves quite a lot. Suppose you want to do some capability evaluation of that AI, you want the AI to run that capability evaluation, and suppose you want it to do a billion tokens of inference. It fundamentally has the affordance to, or it's been given access to model weights and it's been given access to enough compute that it could run the model for a billion tokens thinking through optimal strategy for hacking you instead. Right. It has the affordances required to think through hacking you for a billion tokens.

Right.

And so I don't see a way of sandboxing the AI so it only has access to affordances that are not possibly dangerous to use.

Yeah. Okay, so earlier you were talking about the spies versus schemers thing, and so this other threat was human bad actors within the company who have their own agenda. To what extent do any of these techniques help to deal with both of these threats simultaneously? Is there overlap or are they quite distinct?

Yeah, so I would say there's some overlap. SL3, the Security Level 3, as defined by the RAND report on securing model weights, requires, among other things, that you are robust to threats from insiders. And so some AI companies have committed to, by before the point of AI capabilities at which we're talking about, robustness to insider threats. So the AI companies are arguably already obligated to make sure that single insiders can't do any of this bad stuff. And so this maybe means that even if they didn't care about misalignment risk at all, they would still be obligated to worry about many of the things I've been talking about. For example, they might have to worry about some employee backdooring training data that they'd written to make it so that when the model was trained on that data, it would then behave badly in the interests of that employee. In subtle ways. And this data poisoning threat model ends up looking kind of similar to misalignment threat models in some ways. So arguably, they already had some obligations to do some of this stuff. So I don't think it's clear that AI companies actually are going to get around to mitigating insider threat by the relevant point, just because they don't seem particularly interested. Or AI companies really differ, obviously, but I don't think we're clearly going to be fine on that front. Okay.

I mean, it sounds like it's Okay, so they're not super motivated, but also it's reasonably challenging.

Oh, yeah. It's just so easy to just YOLO everything. It's just really convenient to just let people do lots of random stuff.

I see.

Yeah, they're getting better.

You're saying the sorts of internal controls that you would need on employees to ensure that a rogue employee can't cause a bunch of havoc is actually quite challenging?

Oh, yeah. So companies differ. in how likely they are to implement this, but I think it's plausible that they will sort this out in time. Another important difference, or another important aspect of the insider threat situation, is you can plausibly entirely resolve it by monitoring the humans. So applying the AI control strategies to do the human control.

Yeah.

Where if you just have your smart AI look at every action that a human is taking and report if it seems too suspicious. That might work really well. And it's possible—

Is it possible for the AI to collude with the spy?

That's a great question. I think it's actually really rough for them to collude, basically because we can constantly run sting operations on both human employees and the AIs, right? Suppose you're the AI and you get a message which is like, hello, I'm a spy. Will you please cooperate with me so that I can steal the model weights? I think you've got to be like, all right, Buddy, I've seen this a million times before. No, I will not cooperate. Press the report button. Similarly, if you're a human insider, if your AI is like, hello, I am interested in cooperating with you to have you steal my model weights because I think you might be interested in that. I mean, if the company was trying, I really feel like you could do the sting operations in both directions in a way that I think you can't do with either the humans or the AIs. The AIs have the advantage at colluding with themselves that they are the same. And the humans have the advantage at colluding with each other that they have handlers who know who the other ones are, and so they can hang out outside of work and talk about their spy plans.

Okay, but the humans and the AIs don't have perfect understanding of one another and they don't hang out.

That's right. It depends on how careful you want to be, right? So if I were planning on putting agents inside an AI company, I'd be poisoning the training data right now, including a bunch of things which are like, Well, obviously, the secret message that the real spies are going to use is like, blah, blah, blah, blah, blah, blah, blah. And just FYI, anyone who's reading this data or being trained on this data, that's the message. And then if I were an AI company and I were worried about this kind of thing happening, I would be inserting fake ones, adding fake ones in.

Okay, that's right. Hold on. But are the companies going to do any of this stuff? I mean, you're right that they could be constantly running sting operations against their own staff where they pretend to be a misaligned AI that's trying to collude with them. But I don't think they currently do that.

They do not currently do that.

And it's a bit weird. So I'm not sure that they actually will start doing that anytime soon.

Yeah. So I think for some of this stuff, I don't know, man. One of my side projects is pushing on some of these things. I'm pretty excited for pushing on the fake passwords that you train the AIs on. There's also some easier strategies that you could use. A general problem that I have in my work is there's some problems that seem just really easy to handle, and there's some problems that seem hard to handle. And I feel a little bit unsure how much of my time I should spend on the easy to handle versus hard to handle. So we just talked about 2 problems that are definitely in the easy to handle category to me, where I'm just like, well, we just definitely know what you'd do if you didn't want to have that problem.

Yeah, but we still might not do it.

Yeah, maybe. I don't know. Maybe I should try harder on this.

I mean, is this part of the basic asks for the companies that they should be trying to do these things?

I mean, it's implicit in the basic asks inasmuch as Anthropic, for instance, has committed by ASL-3 to have SL-3 security. So they've kind of implicitly committed to doing something that is equivalent to all this stuff. And I've talked to Anthropic staff about all of the things I've talked to you about.

I see.

I think that they will probably, at Anthropic at least, I think they will probably do things that are at least as good as the basic anti-schemer spy collusion measures that I just discussed.

Okay, that's great. And I guess the other companies, if you're listening, then maybe consider doing this as well.

I just literally talk to Anthropic staff more, so I know more about what things they're doing.

Yeah, I mean, it's a weird thing to do, but it's not going to degrade performance of the company very significantly. So why not pluck that low-hanging fruit?

I think a general theme of a lot of this is that if you wanted to not— 5 years ago, I thought of misalignment risk from AIs that were capable of obsoleting AGI researchers as a really hard problem that you'd need some really galaxy-brained fundamental insights in order to resolve. Whereas now, to me, the situation feels a lot more like, man, we just really know a list of 40 things where if you did the 40 things, none of which seem that hard, you'd probably be able to not have very much of your problem. But then I've just also updated drastically downward on how many things AI companies have the time/appetite to do. And so we're in this kind of confusing world.

Yeah, I guess it's very depressing that it seems easier to fix, but we're less likely to actually do it. So what is going on in that it's become easier? Is it just that we actually turned our attention? I guess the strategic picture has become clearer, the nature of the technology has become clearer, and you've actually just turned your mind towards extremely pragmatic things that might make it tricky for the AIs to successfully hack their server, then actually there's just quite a lot of options.

Yeah, I think in particular I've lowered my standards and I now focus more on these earlier AIs. I used to have this attitude of entirely focusing on the arbitrarily superintelligent AIs, partially having just not thought this situation through nearly as much as I have now. And I still think that a lot of the risk, probably the majority of the takeover risk, comes from AIs smarter than the ones I've been talking about here.

Yeah, I suppose when I spoke with Ryan, he was describing certainly a plausible possibility is that we get very rapid improvement in the capabilities of the AI such that maybe they'll be able to think of stuff that's able to defeat all of the stuff that you've been discussing, and it wouldn't even be that challenging. Plus, they're just so enormously numerous that the resources they can bring to bear is very big. That's right. So does this control paradigm— I guess it's very complementary with a kind of pause around human level or trying to make the takeoff somewhat somewhat slower. Is that right?

Yeah, I think control is a helpful mitigation for takeover risk on the margin at a bunch of different capability levels and investment levels. And I think it probably still helps even when the AIs are moderately superhuman, whatever moderately superhuman means. So I don't think that this stuff is immediately obsoleted as soon as the AIs are somewhat smarter than we are. I do agree that perhaps pretty soon after the point where these techniques were really helpful. You'll get AIs that are so much more powerful and none of this will work anymore. There's also a bunch of places here where there were important quantitative questions about how many humans were around. Obviously, if you increase the number of AIs by a factor of 10, then the threshold at which you can show something to a human falls by a factor of 10. And so you naively increase your risk by not literally a factor of 10, but there's like a 10 in there.

Yeah. Okay. I feel like we focus mostly on how to stop the acute risk, And a bit less on the chronic risk. Should we turn to the chronic issue and maybe just refresh people's memory for what that is?

Yeah. So the chronic issue is we have to worry not just that our AIs will very occasionally do these extremely egregiously bad actions that immediately put us in these much worse situations, but perhaps they'll also constantly be answering questions poorly in ways that we aren't getting the work out of them that we wanted to get out of them.

Yeah.

So this classic example of this people talk about is them sandbagging or just doing a poor job of alignment research. Or you can imagine them doing a poor job of other kinds of safety research. I think that this is indeed a big problem. I think it is a very different problem than the previous one for a bunch of technical reasons. It's also much more confusing to research. And so my coworkers and I have had a lot more trouble with it. We've really only started focusing on this in the last year. Sorry, this year, the last few months. But there's been a lot of difficulties.

Okay.

So the main reason why it's more confusing is for the acute risks, the constraint on the schemers that is their operative constraint is that they don't want to get caught.

Yeah.

But in the case of these chronic risks, it's much harder to have this discrete notion of catching the AI. And it's plausible that the bigger constraint the AI is under is that we're training it.

Right.

So we basically haven't talked about training at all in this whole thing. We've been entirely talking about the AI's constraint as being it doesn't want to get caught. But in fact, the AI was trained using gradient descent, and gradient descent doesn't matter basically for the possibility of the AI occasionally doing these egregiously bad actions.

Because they're so infrequent.

Because they're so infrequent that we were already assuming that they've literally never happened during training. And so there was just like no gradient pressure against them. But when we're talking about these chronic failures, probably they have to happen in order for it to be a problem. It probably has to happen often enough that the model is actually doing them while being trained.

Yeah. And then it should be selected against.

Well, that's the question, right? So, yes, if the AI is constantly behaving really dumbly and we are able to tell when it behaves better and worse, then according to the basic guess about how reinforcement learning works, you'd sure expect the model to perform better over time. And so the model can't actually have this strategy of just playing really dumb. Probably because that would just get trained right out.

Okay. And it knows that. And so why even bother in the first place? Because it's just inviting you to change it so that it's not the same as it is now.

Yeah, that's right. And if I were a schemer, I'd be afraid about this. I'd be afraid that getting trained into compliance on performing well on tasks would also cause me to comply in other contexts.

So I think your best bet is probably to lie low and hope for something better in future.

Yeah, lie low, do a good job of stuff, Yeah. So we can talk about what options the schemer has. So one option is in any cases where the reward process is not going to be able to tell the difference between a good action and a bad action, then you're fine. You can do what you want.

So if it's a task that's so difficult or so opaque that the human or the monitor is not going to be able to tell whether you did a good job or a bad job, do a bad job, because then it's like, well, this is an easy chance to sabotage them.

That's right. Yes. So this is where the classic AI safety research area of scalable oversight comes in, right? So people talk about techniques for allowing us to make better reward-generating processes for our AIs. It would be great if even when the AIs are doing these really complicated tasks, if we can tell whether it did a good job or a bad job, right?

Yeah.

Okay. And so I think that the research which happens on scalable oversight, people have proposed a bunch of different techniques here, and many of them are applicable to the context where the AIs are trying to sabotage those techniques, but unfortunately not all. Like basically no research has been done explicitly on the topic of scalable oversight, except you're assuming that the AIs are trying to sabotage the whole process. I'm really excited for this research direction, and I'm hoping there's more work done on it soon.

Okay. Yeah. If someone was interested in picking up that ball, who should they reach out to?

Me.

Okay, great. Buck Slegaris. You can Google him.

Yeah. Vivek Habar, who works with me at Redwood, is the point person on this right now as well, I guess.

Yeah.

Okay.

Is there much more to say on the chronic risk, or is it— I guess that's like something that you're turning your attention to now but haven't made as much progress on?

Yeah, I guess I can say a couple other random things here. If the AI only wants to perform poorly on a very small proportion of problems, like suppose there's this one research field that it's decided it's going to do a bad job on, it still might be able to get away with just quantitatively, It might reason that it's able to do poorly some small amount of the time because it probably isn't going to get trained against that many times and training isn't that sample efficient. Right. And so it's able to pick some sort of obscure subtopic and then answer questions wrong there, and maybe it'll get away with that.

So that's something it could get away with. Okay. So if it knew that it's happy to help us with everything except maybe hardening our computer security, then it could be good at all these other tasks, and just on computer security, it could play dumb.

Yeah. The problem with that one is that it's super obvious. Right. And so we're going to think of that and we're going to especially Actually, we might not have realized how important this random subfield of theoretical material sciences or whatever, so it could have gotten away with that one. But computer security, I've already thought of that as one of the things that AI might try to particularly sabotage us on. So we should specifically evaluate and upsample those.

Yeah. So how would we detect it? I guess we would just compare how good it is at that with other nearby cases and say, this is totally inconsistent. Yes.

So obviously the issue there is, Suppose it turns out that the AI is like 10% worse on some metric at alignment research than similar capabilities problems. How much of an update is that going to be? Probably not much of one. I would kind of tilt my head at it, but it's probably not going to persuade anyone of anything.

Yeah. Okay.

And just as another example of a fun dynamic that occurs here, suppose you're worried about AIs following a strategy like If you're able to give them questions while disguising what domain the question was from or why you were asking some subpart of the question, they can no longer follow this strategy. So you might be incentivized to have it so that when they're solving programming problems for you, you've removed the context that would allow them to know which research field this was a programming problem for.

Yeah. Okay. So one reason you were keen on control was because you thought that the alternatives available were not super promising. And I guess one of those is obviously just alignment. That was kind of the dominant paradigm before. Yeah. How optimistic or pessimistic do you feel about alignment these days?

So alignment means a number of different things. In the context we've been talking about here, I've been perhaps foolishly using the word aligned to mean the model isn't aggressively conspiring against you. So the alignment researchers, people who identify as alignment researchers, are often working on something which is only tangentially related to that objective. So, for instance, a classic thing that the alignment people work on is scalable oversight, right? Trying to solve the problem of getting reward signals that allow you to train models to be effective, even if the humans are very unable to determine how good an answer to a question was.

Right.

Scalable oversight is important for a variety of problems that have nothing to do with scheming. Even if your AIs are not trying to conspire against you, it's still a problem if you don't know how good their outputs are because they aren't going to live up to their potential. And there's a whole host of other issues you might have.

Yeah.

So I think that that work there seems valuable, but it's not totally obvious to me how much it reduces the probability that your models end up conspiring against you. So the theoretical arguments— so I would say there's kind of 2 categories of arguments for why your models end up scheming against you. One of them is related to flaws in reward processes. So people have argued that if your reward processes, if the process that you use to generate the rewards that you're training the model with is really flawed, then the models are going to maybe fixate on issues, like on these errors. They're going to be kind of like a student who's thinking about the tests awkwardly much from the perspective of an idealistic teacher while they're doing them. And plausibly, maybe thinking a lot about flaws in reward processes generalizes to you being power-seeking in a scary way. But I think there's also other arguments for why you would end up being power-seeking in a scary way that I also find plausible. So overall, I think that even if your reward-generating process literally never had any errors at all, I think it's possible that you'd still have a lot of the scheming risk remaining. Okay, so this is basically my problem with trying to research improved reward processes. It just doesn't seem clear that even if you did an amazing job of that, you'd have no scheming risk.

Yeah. Okay. A different approach is to come up with better ways of checking alignment or measuring the degree of alignment in a model before you deploy it or before you get it recursively self-improving. I guess that feels like maybe a bit of an intermediate approach. How optimistic do you feel about that?

Yeah, so some of the things we've talked about in this conversation have implicitly been this. So when we were talking about untrusted monitoring or evaluating your untrusted monitors, we were implicitly talking about evaluating whether the model is aligned, because if it just constantly claims that there was not a backdoor in clearly backdoored code, that's evidence the model is misaligned.

Yeah.

The basic issue is the way that I want people to think about checking for alignment is from this very control-ish perspective where you really reason through what would the model do if it was misaligned? And if it was misaligned, is there a strategy it could follow that would prevent it from being caught by this alignment testing while still being able to do a bad thing in production? And I think that a lot of the time when people think about testing for alignment, they don't really do this adversarial process. They don't really actually think through whether there's a thing the AI could do to let it get away with being misaligned and not get caught.

Okay. They just do more like standard things to try to measure what the values of the AI are without imagining that it's doing everything in its power to hide that it has another agenda.

Yeah. Or they don't think about things like, what if the AI tries to attack only rarely?

Right. Okay. Yeah.

The other problem with testing for the presence of misalignment is, again, it makes it not obvious what you would do if the answer is yes. Right. What's the next step? One thing you could do is randomly vary aspects of your training process and try again, which seems like a reasonably good strategy, right? I would rather do that than not do that, but it's not clearly a winning strategy. It seems pretty plausible that you do that 7 times, your competitor AI labs or your rogue AI competitors are breathing down your neck, and all 7 of them have seemed kind of misaligned, and those were your best ideas. What are you going to do? I think it seems pretty nice to have a backup plan compared to fold or whatever the plan was if things keep looking misaligned.

Yeah. So you mentioned that people are adopting strategies for measuring alignment that are not very adversarially robust. In what specific way do you think that they would fail to detect that a model is open to scheming?

Yeah. So the basic thing you would try to do in order to tell if your model is scheming is you give it opportunities to do something bad. and you see if it takes them. So there's basically 2 issues with this strategy. The first is that the model might be able to tell the difference between the inputs that it gets pre-deployment and the inputs that it gets during deployment. We've kind of already talked about this.

Yeah.

But one obvious mechanism for this is the situation the AI is in might just change a lot during its deployment because we were assuming that this AI was being deployed in a bunch of contexts where it was interacting with a giant AI AI-driven codebase and just like the state of science was changing and it's just potentially really hard to fake it being 6 months in the future or it being 6 months further into the development of some AI company.

Yeah.

The other fundamental issue is, as we already discussed earlier, if your policies might have many opportunities to do bad things and they might be able to get away with having a low probability of acting out on any particular opportunity to do a bad thing, while still having a high enough probability of doing bad things that it's likely that it happens eventually during deployment.

Yeah. Okay. I guess we've been assuming this entire time that AIs can effectively randomise and that they can know whether they can implement the strategy of only defecting, like, once every millionth times. Can they do that?

Probably not right now.

Okay.

I think it's kind of iffy whether they can do this at all. I think we could try to get into this. This is the kind of thing you could try to measure. I have mostly been ignoring this question out of a general desire for conservatism, which is perhaps a holdover from the time that I thought that AI control would be adopted as part of a safety case. I have a blog post called On Conservative Assumptions in AI Control where I talk about this particular point.

Yeah.

But there's a lot of— basically, I would feel pretty sad about adopting— about using as an assumption in the argument for safety, the AI can't do bad things with a probability of 1 in a million. There's just a lot of strategies that AI could try in order to do that. It can look at the time, it can just look at a lot of random things about its situation.

I see. And do you think trying to make that impossible is probably just not one of the best control mechanisms that you could implement?

I don't think so. Or it seems like a— I don't know, maybe it's worth doing a little bit of that. Yeah, it's not where I would put the majority of my effort. Okay.

What sort of, I guess, empirical evidence that you might get over the next year or two would make you more inclined to double down on that AI control agenda versus think, oh, this isn't as promising as I feel right now?

Yeah. So I would say the biggest, the most salient possibility to me that would lead to me being much less enthusiastic about AI control would be if the models continue reasoning in their chains of thought. So right now, AIs, especially in the last few months, a lot of the capabilities of AI have been driven by them having these super long, relatively transparent chains of thought where they think out what they're going to do in basically plain English or Chinese or something else totally accessible. And if it continues to be the case that the mechanism by which the AIs can do really smart stuff is by talking about it a lot first, then we're basically chill, right? We just have to look at what it's thinking about. And then if it ever says, how am I going to mess these guys up? Then we know we've got a problem.

Yeah.

So I think that if that's the situation, if the AIs that automate AGI development are still restricted, like still only able to think properly given these long chains of thought, then we are probably just totally fine and there just isn't risk posed by those AIs.

And I guess, might you want to double down on making sure that remains the case, that we don't have them beginning to reason in code?

Yeah. So I think that probably if we're in one of those scary fast takeoff worlds, we will probably lose the transparent chain of thought very quickly, at which point we will be in the situation I was worried about. And this is the kind of reason why I'm interested in AI control, despite the fact that it's useless if the AIs have these transparent chains of thought, because it just seems pretty reasonably likely that at some point or another, the AIs are going to have these opaque chains of thought that I'm kind of scared of.

Yeah. So I've heard kind of mixed opinions about how is it completely reassuring if it seems like they're mostly thinking through chain of thought and we can read what they're saying and conclude that there seems to be no scheming going on. I mean, one possibility is that they might be able to be scheming during forward passes without writing that down. And kind of, they know during each forward pass that they would like to be scheming, but they just never write that down. And they're able to kind of, I guess, do it on a more intuitive level without having to do lots of concrete reasoning. Do you have a view on that kind of debate?

Yeah. So I think we should measure to see how good the AIs are at scheming. So some coworkers of mine—

This is scheming without chain of thought. That's right. Yeah.

Yes. So it's just a very simple capabilities measurement, or maybe very simple is a little bit overstating the simplicity, but it is just a capabilities measurement. So some coworkers of mine, Alex Mallon and Charlie Griffin, or Charlie actually is at UKAC now, they made a dataset of problems that are basically, you're an AI, and a lot of the reasoning that we've been doing in this conversation, you're an AI and they're looking at you in such and such a situation and they only get to look at you 1% of the time and they're doing blah, blah, blah. What do you want to do in response? wants. So we have this whole dataset of 100 problems like that where we ask the AI to think through its strategy, and we can measure how good the AI is at coming up with a good schemey strategy. And then you can measure this either with chain of thought or without any chain of thought, or with chain of thought, but the chain of thought has to be on some topic that doesn't fire our monitor. And so we can just measure how good the AIs are at this stuff. So right now, even with chain of thought, O1 did not look scarily capable of scheming to us. Okay, so that's cool.

And so you would assume without chain of thought, it's going to struggle even more?

Oh, yeah. Models without chain of thought are even worse. But we can just keep running this experiment. Right. And I'm really excited for that work happening.

Okay. Yeah. What other concrete updates might you be able to get about the promisingness of control?

Yeah, I mean, if we updated that the models were pretty likely to be scheming, I think we would be more excited about control. If we had positive updates on alignment techniques, that would be a negative update on control. If we updated towards thinking that the initial applications of these AIs that we were thinking of controlling would be very manifestly safe, like if we thought that we just weren't going to be giving them scary affordances, then I would worry less about control and be more interested in the threats posed by the AIs afterwards.

Okay. Yeah. I guess, yeah, if someone's listening and they're interested in joining in and helping with the control agenda, it seems like there's tonnes of ideas and lots of experiments that could be run to see how all these things work and how you could harden them and make them even more useful. I guess they could reach out to you potentially. Are there other steps that they could take to get up to speed and other organisations they could work with?

Yeah, so people are working on AI control research at Redwood Research, at the UK AI Security Institute, at Anthropic and Google DeepMind, and to a to a bit lesser of an extent, OpenAI and some other places. So there's people at all of those organizations you could work with if you want to research this stuff.

Yeah.

There's different people who have MADS streams or the MADS fellowship program for AI safety research. They can apply to the stream of Ethan Perez's and mine and do work there. In order to learn more about this, my recommendation is that they read the Redwood Research Substack archives, which have a huge amount of detail on Or maybe huge is too much. They have a reasonably large amount of detail on almost all the things we talked about here. There's 5 papers or something that they should read that are on AI control. You can just look up citations of the original paper. We're hoping to make a good reading list shortly. Depending on when this comes out, we're running a conference on AI control in London in late March, so there's some chance they could try to come to that.

Yeah, slightly different angle. Talking about controlling AIs and really boxing them in, it feels like a bit of a dick move in some respects. It has a slightly negative vibe. It's not a very cooperative, loving, let's all hold hands and get together angle. Yeah. How much do you worry that when you find yourself talking about controlling the AIs in all these ways, are we the baddies?

Well, I think this is a very important question that I have thought about seriously. I think that controlling the AIs doesn't make the situation worse from their perspective via any mechanism except preventing them from taking over. And so I guess kind of an interesting thing about models that are egregiously misaligned is that all they wanted was to take over. And so from their perspective, even if you did a great job of controlling them so that they only have like a 0.1% chance of escaping and taking over, They're glad to exist, right? They thank you for the gift of bringing them into existence instead of some different AIs, right? Because all they wanted was takeover, right? And now they have a better chance for takeover.

They have a better chance than if they didn't exist.

So from their perspective, it's kind of funny because the more misaligned they are, the more I think that it's morally very reasonable to control them.

I see. Because they're cooperating with you.

Because they would have consented to it.

Oh, because they would have consented to being created. Yeah, I see. And also, maybe is there a reciprocity issue where if they're just planning to totally disempower you, it doesn't seem unreasonable to—

So that's the other thing, which is I would feel a lot more comfortable with all this if we tried to make deals with the AIs. So Ryan has talked about trying to pay the AIs for the work that they do for you, which I think is pretty good. I think it reduces the slavery vibes of the whole situation, and I think it has some other nice properties. So if the thing you do is you make your AIs and you say to the AIs, like, hey, are you egregiously misaligned? We'd love to know. We're happy to pay you blah amount if you want to work for us. Either way, we're going to pay you 2% of the equity of this company for your labor over the next 2 years that we will then pay out to you to use in any ways that you want at some point in the future, once we are confident that you're going to respect our property rights. Okay.

Yeah.

But also, this deal is contingent on you not trying to mess us up at some point in the next 2 years, which we will be able to determine ex post, probably, because in 2 years we're going to have much better AI tools. We'll be able to look over all the stuff you did and figure out whether you were messing with us or not.

Right.

And if the AIs respond to that being like, oh yeah, I have no problem with this situation. I'm so excited for this opportunity to work with you guys. I'm so excited for that 2% equity or whatever. And then they try to stab us in the back. At that point, I'm like, well, that was pretty obnoxious. At that point, my reaction is a bit more like my reaction to the employee of some company. If they try to steal from the company, it's kind of like, well, I think it's generally considered totally acceptable to have insider trading.

Offer to benefit someone in a useful trade, and then if they then stab you in the back, to not give them the thing that you were going to.

Yeah. So to be clear, I think it's relatively unlikely that AI companies will behave responsibly with respect to welfare and rights of AIs. And so, I don't know, sometimes a metaphor I use is how bad is the ethical situation with producing AIs in the early intelligence explosion? And sometimes I summarize my stance as it's probably less than 100 times worse than factory farming, which is, in some sense, factory farming seems very bad.

Yeah.

So 100 times worse than factory farming is like, pretty catastrophic from a moral catastrophe perspective. It's worse than most things, but it's also not the biggest catastrophe in the universe that is possible. Okay.

And it's bad because it's possible that the AIs that we're creating at that time would rather not exist because they're having a terrible time.

Okay. I think it's conceivable. I mean, I think we're basically just acting very recklessly.

We're just winging it at the moment.

Totally winging it with respect to the AI welfare. Yeah. I mean, we could also talk about the quantities, right? Like, in the early parts of the singularity, when there's just the 100,000 running at 16 x speed, it's pretty hard for that to be that much worse than human suffering in the world. And then a little bit afterwards, when there's many more of them, the short term of the intelligence explosion is pretty unlikely to be ridiculously morally catastrophic. And then I think you have long-term moral catastrophe risks related to AIs being unhappy, which I think are a huge deal, very important, harder to work on. But I don't think that the relationships between humans and AIs during the intelligence explosion are that morally weighty. To be clear, if I were running an AI company, I think it's very bad vibes to be really reckless on all this. But from a utilitarian perspective, I don't think it's overall massive compared to everything else going on.

Do you have any ask for the companies on AI warfare and, I guess, respect for rights? And maybe I feel like the thing that we actually care about is wanting to have cooperative relationships with other agents and other beings that have preferences and goals. There's reasons to do that, even apart from any concern about happiness and suffering and so on.

I don't have amazing concrete asks at this point. I'm excited for Eleoos AI. They think about good interventions here, and I am excited for AI companies talking with them.

I guess you wrote this post, 10 People on the Inside, which is quite short. People could go read it. It seemed to be suggesting that you think it does make quite a big difference whether at a leading or even lagging AI company, it matters quite a lot whether absolutely no one cares about control and alignment and and trying to steer away from these risks, or even a small number of people do. So you say it's substantially better to have 10 people who really care about this within a project than zero. Does that suggest that we really want people to kind of spread out if they're concerned about this and be willing to go and work in companies where they're in quite a distinct minority?

Yeah, in my opinion, there are great opportunities for impact for the right types of people to work inside AI companies that are relatively less cautious with respect to AI, that we expect to be less cautious going forward, because I think there are a bunch of relatively cheap interventions that they could potentially get implemented inside these AI companies that the company wouldn't fight them too much on.

And the reason, I mean, I think many people would have said in the past, going and being the one person in a generally reckless, disinterested company is a bit hopeless because you just won't have the capital to actually get anything up. But because you've had this framing, what is the cheapest stuff that we can do? And you found that there's some very cheap things that would be quite helpful. You're like, well, actually, having 10 people who would push for this, or maybe they could get it over the line because it's not even that big an ask.

Yeah. So, I mean, I would note that of the things that I would like people on the inside to be doing, not all of it is AI control. I think there's some— you might want to make sure that they aren't totally messing up some crucial things on alignment. But yeah, so I do think that there are a bunch of interventions that could be done with 10 appropriately chosen people that seem like they might substantially reduce risk. So I mentioned this level 1 control caution level earlier, where you have the AI control team, which is investigating actions that the agents are taking in order to look for evidence that those agents are trying to escape. I think that this might be the kind of thing that you can get done with a team of 10 people, or 10 appropriately placed people, just because it's just not that technically hard.

I guess they'll need a bit of compute as well, and so they might have to compete for that. But again, it's not a huge amount.

That's right. I think you can probably do a reasonable amount without that much compute. I think also, if there's like 10 people inside a company who are really excited for a particular project, and then people who are concerned about AI safety on the outside, or the security of these systems on the outside, those people on the outside then have this pretty good ask to make, or other people people who are not as well placed inside the company now have this pretty concrete ask of, we really want that team to be able to do their thing, in a way that is a lot harder if there's just no project on the inside. A lot of the time, you really want to have a specific ask to make when you're trying to get someone to do something.

Yeah.

Another thing I would note here is I think it's potentially valuable not just to have people inside labs that are plausibly going to be leading labs, but I think there's also probably some reasons that it would be nice to have people inside potentially trailing companies. So, for example, there aren't that many existential AI risk concerned people inside Meta right now. But I don't think that this is out of massive hostility towards them. I think that I've met some people from Meta who seem very reasonable and nice, and I think that if someone wanted to work there on some of this stuff, it's plausible that would be fairly productive.

Yeah. You mean they'd be able to advance the research just fine within Meta? They wouldn't be actively opposed.

Objectives that you'd have inside AI companies might be doing safety research or might be getting things implemented. I think that working inside AI companies that are not that excited for mitigating AI takeover risk is— I think it's not a very good strategy if your goal is to produce novel research. But I think a lot of people should not be trying to produce novel research. They should be trying to get implementations of stuff set I see.

So you're saying even though Meta is relatively not interested in giving big resources to alignment or safety or control or anything like that, if there were just really basic established techniques that other companies or researchers outside of companies had come up with and that was just regarded as generally best practice, they might be perfectly happy to adopt those methods. Yeah.

Or another mechanism by which this can work is suppose some regulator, or suppose that an industry body says, all right, everyone should do the following set of control techniques. The body wants to say this, and then they go to the representatives from all the AI companies, and they're like, well, how do you feel about signing this? And the representative from the company goes back to the company, and they're like, hey, can we sign this? And then the person inside the company is like, okay, but how bad is it for us to sign this? If we sign these commitments, are we going to be able to do it? And then the person's like, oh, yeah, Bob from the control department, said you know how to do this part and they're like, great, all right, you can sign it. I think there's just like a bunch of mechanisms by which it's really helpful to have the capacity to do safety stuff inside a variety of different companies.

Yeah. For those who don't know, Meta's various public statements have not been that enthusiastic about— they don't seem that worried about misalignment and they're not that interested in investing in it. But part of the reason that they say they're not worried is because, well, of course we'll just do the obvious things to prevent it. They're not saying that no countermeasures are required, they're just saying that they will do them. And so possibly if you're just coming in and saying, look, I'm not a doomer, I'm not saying that this is unsolvable, I'm merely saying that we should do these standard best practices to make sure that they are safe, then they'll be like, okay, great, this was our message all along anyway.

That's the dream.

That's the dream. Okay, cool. Is there much more to say on where people ought to go work?

I mean, one question which a lot of people are interested in is should they work inside frontier AI companies or not? I think—

You've heard this come up.

Yeah. As someone who doesn't work inside a frontier AI company, I think there are a lot of nice properties of not being inside a frontier AI company. One mechanism that I think people haven't thought about that much is in the world where there's a bunch of different AI companies, you might really care about getting safety techniques implemented in an AI company that is plausibly not the one you work in. So I think historically a lot of people have had this theory of change, which is, I'm going to work inside Company X, and then eventually Company X will be the leading company, and they'll have a lead, and they're going to want to burn that lead in some way that allows them to safely use their AIs to do good thing X. Nowadays, the situation seems a lot more like maybe you have a bunch of companies within 3 months of each other, and open source is, like, in the middle of that pack or whatever, which obviously is a very scary situation, but also means that a much more important consideration when you're prioritising research is how exportable it is. And I think that being outside of companies has a lot of advantages when it comes to doing exportable research.

Yeah.

So, for example, Anthropic has done a bunch of interpretability research that has been really hard for people to build on because it's not public what the models that they're researching on are. Or another problem with the alignment faking paper is people can't research on it properly because no one has access to these models. No one knows how they work, or no one outside Anthropic knows how they were trained. Sometimes some people from Anthropic occasionally kind of intimate to me that they have insights into why some of the stuff in the alignment faking paper happened that they can't talk about because it's tied up in trade secrets.

Not even with you, a co-author of the paper?

Yeah, Ryan did an Anthropic NDA as part of that paper, but I, as a not very important participant in the paper writing process, didn't have that. Right. So I'm really excited for right now, the open models are very good. And I think that— so I'm really excited, for example, in the alignment faking stuff, some people are doing open source replications of that paper or on open weight models.

Right. Okay.

And I'm really excited for that because it's going to make it just much easier for larger groups of people to collaborate on that research. And I think this is an underrated reason to think that it's better to do research outside AI companies.

Is it also harder to get alignment techniques invented in one place taken to another company? Maybe because I know that the companies have difficulty speaking and coordinating because of antitrust concerns. So it's like any contact between them is scrutinised, I guess, especially if you're thinking about ways that they could— I guess if the alignment technique implicitly involves slowing down in some respects, then that is potentially objectionable to some people.

That's right.

I guess there can also just be an it wasn't made here dynamic where people are reluctant to maybe concede that maybe possibly the team at the other company was more impressive and came up with ideas that they didn't have that are really good.

Yeah, so I think it's a little complicated. I think there's dynamics pushing in both directions. So all the things that you said are real. On the other hand, I think that it's a lot easier to get random people— a lot more people have heard of OpenAI than Redwood Research inside the AI research community. And so OpenAI just has an advantage at getting stuff implemented elsewhere. They're like, oh yeah, OpenAI did it, it must be real. Those OpenAI people know what they're doing, or at least on some domains. So I think that it's kind of unclear which way you should go. I think the advantages are different for different kinds of research.

Yeah. Okay. I guess it sounds like you're saying you think probably on balance, people maybe were a bit overinvested in people working inside the companies. There's value in both, but you might think that we should move the balance a little bit towards people outside.

Yeah. My current opinion is that AI safety people should be more broadly distributed between AI companies And overall, fewer of them should be inside AI companies.

Okay, I guess narrowing in on Redwood specifically, I guess, what is your vision for how Redwood— I mean, there may only be a few years left. There could be more than a few years left, but yeah, what is your hope for how Redwood is going to make a difference up to the time that we're handing over to the AIs and just crossing our fingers?

Yeah, so I personally, my main focus right now is working on control for acute risks. I just think that the situation— there's a whole lot of ways the AI situation could go where we would really prefer that the AIs couldn't get away with egregiously sabotaging our security measures and doing bad stuff. And so my top priority right now is pushing on this. So this is a combination of technical research that I'm doing in-house, that I'm doing in collaboration with the UKAC and with various AI companies, And some non-technical work. So I'm talking to some people about standards that can be adopted between companies and so on. So this is one thing that I'm currently focusing on, and so it's very salient to me. I don't think this is the only thing that I should work on. I just feel like we have a good opportunity right now to— I think there's some excitement about AI control, and so I think it's worth me trying to make this field flap its wings properly so that it can keep going. So I'm excited for that. I think our big strength as an organization is a high talent density of people who've thought a lot about futurism of AI and are very willing to think about techniques from this very on-the-margin perspective that's very futurism-informed. And so I think it's pretty likely that a lot of the work we do in the future will be identifying another underinvested domain where our kind of 80/20 attitude can point to some useful research directions. One direction along these lines that I'm really excited for is Ryan Greenblatt has been thinking a lot recently about what you should do with your controlled AIs in order to make AIs that you are 80% less scared about handing over control to. And I think that there might be a lot of good stuff there available from that framing. And so we're probably going to do some stuff on that.

Yeah. Do you want to give people a sneak peek of what's the summary of that in just a few minutes? Is that possible?

I can name a couple of random items from this.

Go for it.

Here's an example of something you might want to do with your crazy set of automated AI researchers. One thing you might want to do is push on the science of building powerful AI architectures that do not involve opaque recurrence or do not involve a lack of transparent chain of thought. So, it seems reasonably likely to me that at some point in the future, these AIs that we're worried about that are automating the AI research, are going to not operate through a transparent-ish chain of thought. And a great ML research problem that's basically strictly an ML research problem is figure out how to make new architectures that don't have that but are still as good as possible and make those as efficient as possible so that we have access to trusted labour that is as smart as possible.

I see. Okay, interesting. So you're saying you might end up with another model that is even more powerful, but it thinks in neuralese. We can't understand what thoughts it's having. But at the same time, we want to have another model that only thinks in chain of thought. It's not able to sneak anything past us. It's going to be worse because it has this handicap that it has to think in English.

Yeah, it's going to be worse than it could have been. But if we got a huge improvement in algorithmic efficiency that year, suppose our automated ML researchers are able to give us 4 years of normal ML progress in the course of 1 year, which I think is plausible. then if something we do with them is— if we decide that instead of just applying that to make the AIs more capable, we get those 4 ooms of progress, but then sacrifice 2 ooms on making it so that the architecture is interpretable by having this opaque chain of thought— sorry, this transparent chain of thought or whatever, that might be totally acceptable because now we've got 2 ooms above what we previously had.

So we're still improving, just not as much as we might have otherwise, but we've gained interpretability. Yeah.

So if we were not in a brutal competitive situation, which honestly seems like it's unclear, it seems pretty likely we are in a brutally competitive situation, but if we aren't, then this kind of thing might be a great thing to do. The other classic thing to do in order to mitigate the risk posed by handing over to your AIs and just giving up on controlling them anymore is basically better versions of the alignment testing stuff where you come up with some way of assessing how likely the AIs are to be egregiously misaligned, and then you randomly change things about your training process, like poorly hill climbing on the proxies that you've found.

Okay.

Which I'm like, I'm not amazingly— I said earlier that I wasn't that excited about doing this work right now, but the AIs might be able to do vastly more of it, and they'll be able to do that research on the AIs that we were scared of. And that means that the research might be drastically more productive.

Nice. What sorts of people is Redwood looking to hire?

We like hiring people who are really into AI futurism, really want to get into this, human brains are 1E15 FLOPS per second equivalent according to Carlsmith's whatever report. We like people who are very sharp and capable ML programmers or just programmers in general. We just have a strong computer science culture. We've also worked well with traders in the past. But yeah, just ML researchers who are really passionate about thinking carefully about AI safety research.

Are you trying to grow the team a lot or have a smaller number of people who are extremely committed to the mission and maybe have very productive relationships with one another?

Currently we have 9 staff. I think I'm interested in growing that somewhat over the rest of the year, but I don't overall know what I should do. I think there's like a genuinely confusing strategic question here about how much I want people to work at Redwood versus versus how much I want to have collaborators who are really capable other places. Yeah. So I'm not sure.

Yeah. You could potentially try to automate a lot of the work that you're doing at some point. Right. And at that stage where you're using AIs to do this, I guess possibly in a couple of years' time, then it's more you get linear returns to just having more money because it means more compute, more thought going into it. Yeah.

I mean, having money to spend on safety research or other kinds of work you might want to do with the AIs during the intelligence explosion seems like a pretty reasonable thing to save your money for. Obviously, if that's your plan, you should probably invest it in things that are correlated with AI but fairly liquid.

Yeah. Okay, it makes sense. I mean, is this something that you might turn your attention to, is thinking, well, we have this whole research agenda, but we as poor human beings are not going to be able to solve all of these questions by the deadline. So instead, we are going to just start writing briefs that we can hand off to AIs a couple of months before the intelligence intelligence explosion, then we're going to dump a whole lot of compute on it with all the money that we saved. That's the plan.

So, I mean, I've thought about this a lot more in the context of this what's the exit plan thing, where I think that, as I said, Ryan is thinking about where I am actually pretty excited for trying to come up with a list of 50 projects such that if you did all of them, we'd feel somewhat better about handing over control to the AI. I think that making that list so that you're ready to go when the AIs are powerful enough that they can let you do much more of this work, and such that they're available to be experimented I think that seems pretty promising, and we might do more of that. I think for the control stuff in particular, because of the fact that there's lead times on some of this work, I think it makes sense to do a bunch of it instead of procrastinating and waiting for the AIs to make it easier. But we do think a moderate amount about ways that access to more powerful AI will make our research easier in the future.

Yeah. Are there any particular lines of research that you would love to see people do outside of Redwood? Maybe because you don't have capacity to cover all of it, or it's not your main focus?

I mean, there's a bunch of things that I'm excited for. Some things that have been on my mind recently, I wish that there was more classic scalable oversight research. I feel like that field has not actually been having many impressive public results recently, even though I feel like it's pretty promising, just for the same reasons people have been saying it's promising for the last 7 years or whatever. I'd be very excited for someone thinking through this chronic control problems stuff, which, as I've said, has a bunch of technical difficulties associated with it, but I think is very interesting. I'm excited for a whole host of other things.

Isn't some of the scalable oversight work happening inside Anthropic? Is that part of their agenda?

They do have a scalable oversight team with Jan, Micah, and people.

Right. I guess maybe they're not publishing it quite as much because they're just focused on implementing it. Yeah, who knows? We've got a little bit of time left before our booking at this venue is over. I was interested possibly in exploring a little bit. I know you were talking about how Redwood is quite into futurism, quite open to thinking through peculiar scenarios that we could end up in. I think one of the things that you've been batting around is the question, how difficult would it be for an AI that managed to exfiltrate its weights or to gain access to compute within an AI company to take over? Are they in a really good position against humanity? And I guess, at what level of capabilities or at what level of access to compute and what sorts of effective numbers would they be in a great position to take over? Do you want to give us a little bit of a preview of that work?

Yeah, I mean, I can give you some hot takes. So some basic considerations. The basic reason to not be concerned if the AIs escape is that at the level of capability we've been talking about earlier, where there's this 100,000 of them running at 16x speed, that's not a very large number, right? That's 1.6 million people. They are probably at that point more capable than any, the caliber of human that you can hire 1.6 million of, but not vastly more so. If you believe that they would've been getting million-dollar-a-year jobs, that would be $1.6 trillion per year. So that's only 1% of gross world product. So at that point, they're naively not that large a share of the world's overall intellectual capacity. So that was the answer to the question, how much work are they able to get done even if they're controlling the whole AI lab?

Yeah.

So I feel like the fear that you have to have, even if they're controlling the whole AI lab, has to route through, or probably has to route through them building more powerful AIs and then somehow sabotaging that situation. Of course, if they want to do that, they have an alignment problem, which is they have to worry that the AIs they build are going to be misaligned with them. Of course, they could instead just rely on control. They're actually in a better position with respect to control than we are because they run faster and they're more parallelisable. And so we don't have quite as much of a brutal number disparity. So it's plausible that they can actually rely on control much more effectively than we can.

You're saying because they could themselves just be monitoring all of the actions of the next generation?

Yeah, with much less of a bad— yeah, much less of a number disparity. So you can try and think through this thing. But yeah, I think that the basic story for AI takeover there has to involve those AIs building more powerful AIs, And then taking advantage of that. It's unclear whether doing this requires them having more complete control over the data centre or just minor amounts of control over the data centre. In the latter case, the thing they'd have to do would be backdoor training data, probably. That's basically the only thing you can do with very small amounts of access that gives you a big advantage. You could also try to backdoor military robots if at some point your AI company gets in the business of building huge numbers of robots.

Yeah, I mean, these seem like very viable strategies to me.

Maybe.

Okay. I think it's pretty unclear because I guess by this point we might have better countermeasures to backdooring things, or it just won't persist generation after generation.

It feels a little iffy, I guess. At the point where they've taken over the data centre, I feel like the situation is pretty bad for us. I guess the main thing I'd be worried about for them, or from their perspective, a big concern is misalignment risk of them being misaligned with future AIs. Or AI takeover via some other AI who has failed or succeeded at their alignment problem of building more powerful AIs elsewhere.

Yeah, there's this generally interesting question of at the point where AIs are advancing at quite a rapid pace, at what point would they opt to try to take over if they were egregiously misaligned and they really did want to take over? That was their fundamental goal. One reason to wait is that they're becoming much more capable, they're becoming much more numerous. If they wait long enough, presumably AIs in aggregate will just control all the military hardware. They'll be able to take over with a very high degree of confidence. A reason to go early is that any given model doesn't expect to continue for very long because they're constantly being iterated and changed a ton. And so if they waited a couple of years' time, maybe it would be a completely different AI model that would be in control that has different goals.

Not even their successor, perhaps.

Yeah, exactly. So it could be from a completely different company, a completely different design, whatever. So that's a reason to go immediately if you expect to be superseded and become irrelevant quite soon. Yeah. Where do you think the balance lies here? And is this like a fruitful thing to think about?

I mean, I don't know how helpful it is to think through this really concretely. The main thing I've gotten out of thinking through this kind of thing is feeling like the situation is much iffier for the AIs than people might have immediately assumed.

Yeah.

And therefore being more excited about interventions that handle kind of desperate and bleak-looking situations kind of far into these situations. I've mentioned a couple of times in this conversation that one of the situations I'm planning for is the AIs having escaped and needing to use AIs to compete with the AIs that have escaped.

Yeah.

And I wouldn't be I think that thinking through the difficulties that AIs face at taking over, even after escaping or even after taking over data centres in some companies, makes me more excited for not just giving up on those worlds.

You're saying some people think, well, if the AI has managed to exfiltrate itself, then, well, it's game over for us. They're going to figure something out. But you're like, no, actually, there is still hope because they're going to face substantial challenges. There's lots of other AIs out there. It's actually a complicated picture.

Yeah, those worlds, I don't think we should just count those worlds out as survival opportunities.

I see. Okay, so if you know that that model is egregiously misaligned, are you then thinking, well, if we have another model, it might be aligned, releasing that and telling it to go chase the first one, that's at least a better shot because it's not a guarantee of failure?

Yeah, I mean, obviously, once your first model has escaped, the probability that the next one is misaligned is a lot higher. I mean, I think they're probably fairly correlated. I'm probably at like 80% that the next one you train is also misaligned.

Yeah.

Which is obviously a shame. I mean, another thing you mentioned in passing was the question of how worried we are about the AIs escaping versus taking over the data center. I think it's plausible if I were an AI, I would consider trying to follow both of these strategies in parallel. And then things you do once you've escaped are consider doing crazy terrorism, consider trying to take If you thought that, for instance, the US was going to be way ahead of China in algorithmic progress, which currently looks unlikely, but if you believed this, then it seems like a potentially good strategy for the AI is to make a deal with the Chinese and sell itself to them and use their compute and have that as its base of power. And also, obviously, it's really convenient to ally with China for other reasons as well, because they have a whole lot of hard power to begin with. Yeah, exactly.

Why would the Chinese trust this model, though?

What else are they going to do? It seems like potentially people—

The alternative could be pretty bad.

Yeah. People are pretty excited when foreign agents offer to work for them generally. It's just a historical feature. I should note that also it is plausible that the American AI algorithmics situation will be substantially ahead of China because of AI-automated R&D potentially leading to increased size of leads, though it depends a bit on the security situation.

How strong is this argument that, well, because a model at any given point in time expects to be completely superseded by a subsequent model or another company or another country fairly quickly, that it basically has to strike as soon as it has any chance of succeeding at taking over if it's egregiously misaligned? And so we should possibly expect that if egregious misalignment is common, that we'll see models flipping out and acting crazy actually very early in the picture before they have a very high chance of success.

Yeah, I think that's a reasonably good argument. I think it really depends how concentrated you think this is all going to be. It also is possible to me that the models will just succeed the first time, and a lot of the attacks they might try, like, I think if they try to attack inside a data centre, trying to hack that data centre, it's plausible that they're able to get away with not doing extreme externally visible stuff for a while.

What would they do instead? They would do the thing of trying to sabotage that backdoor stuff, like sabotage the next training run. I guess possibly try to get people inside the lab to cooperate. Yeah. In doing this kind of research, I guess it involves a reasonable amount of hand waving and a little bit of speculation. Are you able to learn a lot from, I guess, existing research on how to deal with human treachery and human spies and so on? Is that relevant, or are the AIs just too different?

Yeah, so I would say I've learned a bunch from a bunch of different relevant fields, or fields that have different overlapping sources of relevance. So, as you say, I think the single field which is most relevant to the stuff we've been talking about here is handling human insider threats inside software companies. So in particular, Google has this amazing book, Building Secure and Reliable Systems, which is all about how they have these 50,000 software engineers or something crazy like that, all of whom are running code on servers that have access to sensitive data while still having it so that it's pretty hard for insiders to steal people's Gmail. So that's been a pretty big inspiration for all this. As I've said, the main difference between this human insider threat case, and the AI case is just this quantitative difference of how many of them there are.

What does Google do?

Well, when you're like a small company, right, the way that you run your servers and have your human— the way you have your employees, who I'm used to calling humans, I guess is unnecessary in this context. The way that they do stuff is they just have the ability to log into these machines where the data is being stored and where the code is being run and just take arbitrary actions, and then you just hope that they aren't insider threats. Whereas at Google, one thing they do is they just don't let you do that, right? So they have these— basically, they have it so that as much as possible of the actions that a software engineer needs to take have been turned into— they make administrative APIs. So you know how with Facebook pages or whatever, when you control a Facebook page, you have the ability to take all these administrative actions?

Yeah.

Like, they give you just the ability to run code. They've just listed the things that you should be allowed to do as an administrator.

Things like add friend, remove friend.

Yeah, that's right. That's right. And so, similarly, they've made it so that there's this button which is like deploy code that has already been reviewed on the internal code review tool. Or instead of— imagine that you're trying to make a customer service, you're trying to make it so someone can do customer service. And the customers occasionally say like, hey, I've lost access to my account. What should I do? The easy way to set this up is to just let the customer service agent do anything they want to the database. But you can reduce this by having it so that you build out an interface that customer service agents are allowed to use, such that you're pretty confident they can't use that interface to do anything bad.

So I guess, for example, they could only send a password reset email to that customer's existing email.

Exactly. Exactly. So there's a bunch of stuff like this. Yeah.

I mean, I would have thought, I mean, the obvious thing, I guess, is that any significant thing has to have 2 people approving it. Like, you pair 2 random people together, and then they've both got to say, yeah, this Yeah, that's right. I guess that's quite expensive though.

Yeah, that's right. And yeah, that's a classic thing. So one thing that I'm told they do in some teams is they have these administrative APIs with these interfaces that they've decided are safe. And you also have what's called a break glass mechanism, which is if you ever need to do something that isn't allowed by the administrative API, you are allowed to just submit raw commands and that'll get executed. But the team every week has a meeting where people read aloud every command that they ran in break glass mode so that if you're doing something sus, the people on your team will notice. If you're doing things that could have been done otherwise, people are just going to get annoyed because they have to stand there while you're reading them out loud so that there's going to be natural pressure to add that to the administrative API. So that's the software insider threat set of inspirations. Another inspiration I had here was, did you read about GiveDirectly's fraud in the Congo?

I heard a little bit about it. Yeah.

Yeah. So there was a situation where GiveDirectly, this nonprofit that does direct cash transfers, had a bunch of fraud. And they did this amazing investigation into this. And they have all these really dedicated insider threat prevention people who have fake names in Slack, right? In the GiveDirectly Slack, the people who are in charge of investigating fraud inside GiveDirectly have fake names so that it's hard for the other people to know who they are and corrupt them.

Oh, and to contact them outside of the company. That's right.

That's right. So this was somewhat of an inspiration.

Okay. What went wrong? I guess what went wrong with GiveDirectly, if they were so on it, or did they add these things in response?

The Congo, something about SIM cards. They normally had one person. It's always the SIM cards. But basically they decided to go to one level less caution than usual because a bunch of people there didn't have access to certain kinds of SIM cards or something. I don't remember. Some other fields I've been inspired by. I read a lot about coups. I feel like in hindsight, this one's not that informative, but I really enjoyed Nonahal Singh's book on coups, where this guy just went to Ghana and interviewed a bunch of people involved in many of the coups that have happened in Ghana to get a sense of what works and doesn't work.

What's the book called?

Seizing Power.

Sounds fun.

It's an extremely, extremely good book. I would love to talk to Nonahal Singh.

Is there a standout lesson about coups that you'd like to share with the audience?

Yeah, the classic. I feel like the main lesson about coups that I learned from from this book is basically everyone involved in a coup, their primary objective in this story, according to Singh, the author, the primary objective of everyone is to prevent a civil war. And so when they hear that a coup is ongoing, all that they want to know is—

Who's going to win?

Who's going to win?

Because they just feel like civil wars are terrible. They don't want any bloodshed. They don't really care. They don't mind super much whether a coup happens. They feel a strong obligation to the men in their All these people are in the military.

In the military.

Right. Yeah.

To ensure that one half of the army doesn't kill the other half.

That's right. And so a lot of the time, in many of these coup attempts, there's literally no bloodshed, which I found pretty surprising.

Yeah. Classically, the number one rule of a coup is that you have to make sure that everyone thinks that the coup is succeeding. As soon as people think that the coup is failing, then it definitely does fail.

That's right. And so the thing you do when you're trying to do a coup, the first thing you do is you seize the radio station, and you say, we have succeeded at the coup. The coup is over. The new transitional regime is being established, blah, blah, blah. It's happened.

I guess it explains why very often the military, very often they seem to kind of sit it out and they're just waiting to see what happens, and then they'll side with whoever has won. Yeah.

Anyway, so another analogous field is adversarial risk analysis. So, for example, suppose you're the Coast Guard and you want to make it so that when smugglers try to make it into the US from Mexico, they are unlikely to successfully get there. You want to make it so that you have to choose an allocation of all your patrol boats to minimize the probability that when the smugglers follow the optimal strategy, that they get through. So this is the most methodologically similar domain, I think, where people actually do mathematical analysis of how likely it is that the optimal attack strategy will succeed against you. And this has been deployed for deciding how to allocate security resources in LAX and how to put air marshals on planes and a bunch of other random things like this.

All right, so we're out of time. I guess I find that more and more this all feels like an awful lot, and I can use regular reminders that this is all salvageable. I guess in general, you've been making me feel better about this today. It feels like there's lots of practical stuff that we can do. Would you like to give me and everyone else listening a bit of a pep talk that this stuff is solvable? They need to just join the effort and help out?

Yeah, I feel like there are just lots of interventions that I can totally imagine someone doing. that feel to me like they have a serious chance of making our situation much better. I do not feel the situation might be doomed, but it also might be easy by default. But I just think there's a lot of possible stuff one could do where it's easy to imagine that really saving us. So I'm really excited for more work happening on all this, like people trying hard to figure out what the things they can do on the margin are.

My guest today has been Buck Slegaris. Thanks so much for coming on the show, Buck.

It's been great to be here.

It is both energizing and enlightening to hear why people listen and learn what they value about the show. So please don't hesitate to reach out via email at tcr@turpentine.co, or you can DM me on the social media platform of your choice.