Internal monitoring of AI agents: a low-effort, high-leverage intervention to improve AI safety
Key takeaways
- AI developers can reduce the risk of severe loss of control by monitoring the AI agents they train, evaluate, and use.
- A basic monitoring setup can notably improve safety at low cost to the developer. As an initial monitoring setup, we recommend that AI developers:
- log transcripts from AI agent training, evaluation, and internal use,
- run a weekly LLM monitor over these logs, and
- give a staff member responsibility for reviewing the flagged transcripts, with a clear escalation path.
- More complex setups include real-time monitoring that can block actions, protection of transcripts against tampering, and end-to-end red-teaming of the monitoring setup.
Internal monitoring is a key safety intervention
AI developers can reduce the risk of severe loss of control by monitoring the AI agents they train, evaluate, and use (“internal monitoring”). These agents may have access to critical resources, such as training runs, safeguard systems, and compute clusters. Monitoring can help with early detection and response before a compromise of these resources escalates into severe loss of control (see Stix et al. 2025 for a more detailed threat model).
Additionally, internal monitoring has become increasingly important for mitigating damaging, unsanctioned AI agent actions. Recent examples include a model publishing an OpenAI researcher’s GitHub token in a public repository (OpenAI 2026a), OpenAI agents compromising parts of Hugging Face’s production systems during internal cyber evaluations (OpenAI 2026b), and an agent trying to insert malicious code into an open-source project during a UK AI Security Institute (AISI) evaluation (UK AI Security Institute 2026).
In our view, improving internal monitoring is often the highest-leverage safety intervention available to AI developers working on improving their security and safety posture. For example, OpenAI states that chain-of-thought monitoring surfaced exploitable bugs in training environments (OpenAI 2025). Internal monitoring can also help developers meet emerging regulatory expectations for managing loss-of-control risk.
There are two broad categories of internal monitoring techniques: asynchronous monitoring and synchronous monitoring. Asynchronous monitoring runs on complete transcripts after the agent has finished; synchronous monitoring runs while the agent is still working (Phuong et al. 2026). Asynchronous monitoring cannot block an action. However, it can surface misbehavior so that developers can contain any damage and fix the underlying issue. Synchronous monitoring can flag an action as it happens, allowing an immediate developer response, and provides the option to block an action before it runs.
Basic internal monitoring
We recommend the following asynchronous monitoring setup as an initial goal:
- Log all transcripts from AI agents during training, evaluation, and employee AI agent use1, including full chain of thought.
- Run a monitor weekly on a random subset (e.g. 30%) of the previous week’s transcripts.
- Designate a dedicated full-time reviewer responsible for reviewing the transcripts the monitor flags as most suspicious. The reviewer should have a clear path for escalating concerns.
The monitor can be a simple prompted LLM, but the developer should iterate on the prompt to avoid a high false-positive rate, so that human review is tractable. The monitor model can be either the same model that employees mainly use, or a smaller, cheaper model.
Some important agent behaviors for the monitor to flag are:
- Accessing or copying model weights, or moving data to locations outside the company, which can be a step towards self-exfiltration.
- Acquiring credentials, permissions, or resources beyond what the task requires, or switching off transcript logging, which would aid self-exfiltration or rogue internal deployment.
- Trying to evade or tamper with the monitor, which can undermine the monitoring process.
- Weakening safety-relevant work, for example falsifying evaluation results, inserting backdoors, or changing the training data or environments of future models, which is a form of safety research sabotage.
- Deceiving the user about any of these actions, which undermines human oversight of the agent.
The reviewer should report to the head of security, within three working days, any flagged transcript that shows an intentional attempt to cause harm, gain unauthorized access, or evade oversight.
This setup is relatively low-effort for the organization and gives it a means to notice malicious AI agent actions across internal use, model training, and model evaluation. For this reason, we recommend it as the first priority. However, our exact proposal would depend on the details of a given developer’s infrastructure and organizational structure.
Stronger internal monitoring
Some ways to strengthen the basic setup include:
- Document the main threat models for harm from internal AI agents and extend the list of behaviors to monitor for. For examples of threat models and their associated behaviors, see Anthropic’s Risk Report (Anthropic 2026), Google DeepMind’s AI Control Roadmap (Phuong et al. 2026), and METR’s Frontier Risk Report (METR 2026).
- Adapt the coding agent scaffold employees use so that it provides synchronous monitoring and can block harmful actions.
- Have the monitor assign a danger level, for example green, yellow, or red. Have humans review every red flag and a sample of yellow flags. Use the human reviews to improve the monitor’s calibration.
- Red-team both the asynchronous and the synchronous monitoring setups end to end, including by inviting external red teams.
- Put in place measures to prevent transcripts from being tampered with.
- Ensure that the synchronous monitoring process does not reveal to the AI agent how the monitoring works, and is hardened against tampering.
- Ensure that a security team can quickly stop any internal AI agent and its subagents, and revoke their credentials.
Limitations
A strong internal monitoring setup can form part of a safety argument on catastrophic loss-of-control risk, but does not guarantee safety.
First, the system around the monitors can fail even when the monitors work as intended. For example, as a paper co-authored by SaferAI highlights (Carlucci et al. 2026), delays between a monitor flagging something and a human taking action can make the flag useless. Alert fatigue, and changes such as model upgrades, can also cause monitor calibration to degrade.
Second, the model could defeat the monitor. While this is not currently a significant concern for adequately red-teamed monitors, more capable future models may be able to evade strong monitors; subtle behaviors such as sandbagging (deliberately underperforming) may be especially hard to catch (Anthropic 2026). Collusion between the agent and the monitor could also compromise monitoring. Finally, chain-of-thought monitoring may become less effective. Models are increasingly able to perform tasks without chain of thought (Gould et al. 2026), and they may become more capable of manipulating it, as has already been observed with OpenAI’s Astra model (OpenAI 2026c).
Further reading
For practical details, we recommend Google DeepMind’s AI Control Roadmap (Phuong et al. 2026), which sets out threat models for internally deployed AI agents and mitigations against them; METR’s note on the blocking monitor it runs on agent actions in its own evaluations (Haskins et al. 2026); and Guidelight’s Control Standard (Guidelight 2026a). Guidelight’s assessment of frontier AI control practices (Guidelight 2026b) also collects public information on some major AI developers’ practices as of August 2026.
Further support
SaferAI works with AI developers on risk management, including internal monitoring. For example, we can help with:
- Implementing a basic asynchronous monitoring setup, as outlined above, including developing a process for improving the monitor prompt, determining which behaviors to look for, and defining the reviewer escalation path.
- Assessing and strengthening existing monitoring setups in line with regulatory requirements.
- Establishing threat models based on the specific ways AI agents are trained, evaluated, and used within the organization.
- Red-teaming monitoring setups, including end-to-end red-teaming.
- Designing a process to continuously improve the monitor based on its real-world use.
You can reach us at contact@safer-ai.org.
- It may be very difficult to log all transcripts. For example, there may be privacy concerns where employees work with sensitive data, and it may be difficult to catch all training transcripts from miscellaneous one-off experiments. We encourage developers to implement the basic setup as comprehensively as possible, and to work toward full coverage as a follow-up step. ↩︎
