The deadline for applying to this role is 30th September 2026, end of day, anywhere on Earth. 

Team Description

Control measures — monitors, permission systems, sandboxing, resampling, escalation protocols — are designed to detect and prevent misaligned behaviour from advanced AI systems. Though the measures are already critical to safety, whether they would in fact catch a capable model attempting to cause harm is an empirical question that remains largely untested.  

The Control Red Team at AISI is stress-testing control monitors (including from GDM and Anthropic) – finding attacks that beat monitors and attempting to design experiments to measure real-world risk. We’re based within the Red Team, about a dozen people who have spent the last two years breaking developer’s alignment and misuse safeguards, and grew out of AISI’s previous research into control evaluations and safety cases. 

We're opening roles on the Control Red Team, and we think it's an unusually good place to do this work. You'd join early, with real ownership over the team's direction; you'd have frontier model access, serious compute and strong infrastructure support from across AISI; and you'd get privileged insight into control measures across several frontier developers, working alongside some of the most experienced red teamers in the field. 

Our current bet is to focus our effort on monitoring: the measures frontier companies lean on most heavily, and the ones where the science of evaluation is not yet settled.  

About the Role

What You'll Be Doing

You’ll spend your time across two tracks of work:  

1. Research: How and what should we measure to understand the efficacy of control measures?  

How can we gather empirical evidence about how likely a monitor is to prevent harm — and what can we legitimately conclude from it? How do you estimate a monitor's recall against dangerous behaviours nobody has seen yet? These are difficult questions – conceptually and empirically. Day to day this looks like: designing and running ML experiments (including RL and other optimisation-heavy work), building the adversarial attacks that generate the evidence, writing arguments, and arguing them out with the rest of the team. We intend to publish this work. 

2. Testing: Running evaluations of frontier labs' monitors, and reporting the implications. 

Turning our research into concrete assessments of real systems: threat modelling how an AI attacker would actually operate in a frontier internal deployment; breaking monitors, sandboxes and the surrounding infrastructure; conducting security analyses; and producing reports that are decision-relevant and action-guiding for the companies and for government. 

Underpinning both:

• Building tooling and experimental pipelines that let us go from question to result fast, at a quality bar that makes the results reusable. 

• Heavy use of LLMs to automate our own attack, evaluation and analysis loops — and getting faster as models improve. 

• Building and running the infrastructure for training and serving models at the scale our experiments need. 

Research Scientists and Research Engineers 

We're looking for research science and engineering skills, and we're excited to hear from strong scientists, strong engineers, and people who are a bit of both. 

We’re deliberately open on seniority. For exceptional candidates, with experience leading research teams, we’ll grow the scope to match. 

What We're Looking For 

The experiences listed are examples of the expertise we're looking for, rather than a list of everything we expect to find in one applicant. 

Essential Requirements

• Demonstrated ability to design, build and run ML experiments on frontier models, and to work autonomously on complex research projects involving substantial engineering. This includes black-box work (API-based evaluations and attacks) and ideally some white-box work (e.g. fine-tuning open-weight models). 
• Strong software engineering and ML experience: writing clean, documented, reusable code for machine learning experiments — beyond one-off research scripts — including experience with LLM finetuning and inference frameworks, or evaluation frameworks like Inspect.  
• The ability to understand and critique how an experiment does and does not support a safety claim – including an understanding of why AI safety and control are hard problems, or a clear appetite to get up to speed fast. 
• Impact-driven mindset and a collaborative team player: motivated by the work that most reduces risk rather than what is superficially impressive, flexible about what needs doing, and high velocity with a high-quality bar for outputs. 

Highly Desirable

We don't expect candidates to have all of these — they're additional signals that help us identify exceptional fits for specific aspects of the role. 

• A good working model of frontier AI companies' internal deployments: what their ML infrastructure and dev practices look like, the kinds of experiments they run internally, and where the security weak points and easiest escape routes would be. 
• An exceptional red-teaming mindset — instinctively finding the path a capable adversary would actually take, whether against a model, a monitor or a sandbox. 
• Experience with ML optimisation: RL, SFT, evolutionary methods, or similar. Experience optimising hard against a defined metric and making (and justifying) careful measurement choices. 
• Strong written communication and argumentation: high-quality research write-ups in any medium — a paper, a blog post, an internal report, an unusually good thread — where the reasoning, not just the result, is the point. 
• Willingness and ability to construct and defend arguments for safety claims, and to think about which claims are worth making in the first place. 
• Experience building or operating ML research infrastructure at a large organisation: GPU management, running experiments at scale, securing evaluation environments. 
• Experience in cybersecurity or security analysis, including attacking LLM-based applications and agent scaffolds.
• Familiarity with the AI control and adversarial ML literature, and existing relationships with researchers working on control at labs or in the wider safety community.  
• Participation in an AI safety research or fellowship programme, or equivalent evidence of independent research output. 
• Broad evidence of strong mathematical, scientific or analytic ability (for example, highly competitive courses or programmes, or olympiad-level results.
• Proficient use of LLM coding tools and agents. 

We are less interested in credentials as such: a first-author conference paper or a CS degree is welcome evidence, but neither is required, and neither substitutes for the signals above. 

Selection process 

The interview process may vary from candidate to candidate; however, you should expect a typical process to include some technical proficiency tests, discussions with a cross-section of our team at AISI (including non-technical staff), and conversations with your team lead. The process will culminate in a conversation with members of the senior leadership team here at AISI. 

Candidates should expect to go through some or all of the following stages once an application has been submitted: 

• Initial assessment 
• Initial screening call
• Technical assessment
• Behavioural interview
• Research interview
• Final interview with members of the senior leadership team