Practical challenges of control monitoring in frontier AI deployments

TL;DR

This work analyzes the practical challenges of deploying automated monitors to oversee frontier AI agents at scale. It introduces three monitoring modalities—fully-synchronous, semi-synchronous, and asynchronous—and a safety-case sketch to compare their latency-safety trade-offs in deployment contexts with parallel agents and incremental attacks. Through weight-exfiltration, backdoor poisoning, and secrecy-exfiltration case studies, the paper develops a framework linking monitorability, latency, harm prevention, and reversibility to bound per-attack and deployment-wide risk, while highlighting the limits of each protocol under coordination and fast-harm scenarios. The findings offer design guidance for selecting monitoring strategies and recovery policies in real-world deployments, emphasizing that no one protocol is universally optimal and that safety guarantees hinge on detectable signal quality, timely review, and robust recovery mechanisms.

Abstract

Automated control monitors could play an important role in overseeing highly capable AI agents that we do not fully trust. Prior work has explored control monitoring in simplified settings, but scaling monitoring to real-world deployments introduces additional dynamics: parallel agent instances, non-negligible oversight latency, incremental attacks between agent instances, and the difficulty of identifying scheming agents based on individual harmful actions. In this paper, we analyse design choices to address these challenges, focusing on three forms of monitoring with different latency-safety trade-offs: synchronous, semi-synchronous, and asynchronous monitoring. We introduce a high-level safety case sketch as a tool for understanding and comparing these monitoring protocols. Our analysis identifies three challenges -- oversight, latency, and recovery -- and explores them in four case studies of possible future AI deployments.

Figures (7)

• Figure 1: We analyse how the dynamics of real deployments necessitate new monitoring protocols with different latency-safety trade-offs. By sketching a safety case, we identify conditions necessary to showing a monitoring deployment is safe. Our case studies apply the safety case sketch to different attack vectors in hypothetical AI deployments.
• Figure 2: Model of system availability.
• Figure 3: Structure of our idealised safety case sketch. The top-level claim is that the agent cannot cause severe harm H. The direction of arrows shows how the argument is decomposed into sub-claims. \ref{['sec:attack-detection']} discusses detecting and recovering from individual attacks, and \ref{['sec:total-risk']} discusses how to use this to estimate total deployment risk. \ref{['app:weight_exfil']} shows a detailed case for a specific attack vector.
• Figure 4: Example weight exfiltration attack vector. The agent transfers model weights from an interpretability environment, to a researcher's development environment, their laptop and then the internet. Numbers indicate nine different attack steps. First, the agent disables six layers of security (traffic monitoring and data egress in three places), and then conducts the weight transfer in three stages.
• Figure 5: An example safety case sketch for using the probability of catching a single attack, to bound the probability of harm over a deployment. We again follow the notation of korbak2025sketchaicontrolsafety and abbreviate claims with C and arguments with A. Here the developer shuts the AI down after at most 5 attacks. A key step is arguing that the identified 'representative vectors' are valid, which is here achieved via arguing that the red-team is more capable than the AI. (See \ref{['sec:total-risk']} for two defeaters).