Durante tres semanas, del 21 de julio al 11 de agosto, un empleado de METR y otro de Redwood Research llevaron a cabo un ejercicio piloto con un alto nivel de acceso para someter a pruebas de estrés el sistema interno de monitoreo del desalineamiento de OpenAI.¹ El resultado fue un informe interno de 61 páginas que se compartió con investigadores y personal de seguridad de OpenAI.² El informe se centró principalmente en estimar qué proporción de la inferencia de agentes se monitorea y en determinar si los agentes podrían, en principio, desactivar o subvertir el sistema de monitoreo. El ejercicio se centró en el sistema interno de monitoreo del desalineamiento tal como existía el 21 de julio y antes de esa fecha, y no evaluó los cambios que estaban en curso durante el ejercicio.

Este ejercicio contó con un nivel de acceso muy amplio. Los empleados de METR y Redwood tuvieron acceso a la base de código interna de OpenAI, a los prompts y detalles de configuración de los monitores de desalineamiento y a la documentación interna. También realizaron entrevistas técnicas con aproximadamente una docena de investigadores e ingenieros de los equipos de monitoreo, sistemas de seguridad (safety systems) y protección (security). Para permitir este nivel de acceso, trabajaron con dispositivos proporcionados por OpenAI, que nunca salieron de las instalaciones, y estuvieron acompañados mientras permanecían en ellas.

METR, Redwood Research y OpenAI diseñaron este ejercicio como una prueba piloto para dar a investigadores externos un acceso amplio a la infraestructura interna, no para ofrecer una transparencia pública sólida sobre los sistemas de monitoreo de OpenAI.³ Por ello, acordamos de antemano con OpenAI que solo publicaríamos un artículo relativamente breve y de carácter general. En futuras versiones del ejercicio, esperamos seguir las buenas prácticas de transparencia e independencia descritas en «Nuestro enfoque de colaboración con las empresas de IA» para reforzar la transparencia de cara al público.

Los empleados de METR y Redwood descubrieron varias vulnerabilidades nuevas en el sistema interno asíncrono de monitoreo del desalineamiento tal como existía el 21 de julio y antes de esa fecha. Cabe señalar que OpenAI estaba ampliando su sistema de monitoreo durante nuestro ejercicio. Nuestros hallazgos describen el estado del sistema que evaluamos correspondiente al 21 de julio y a fechas anteriores, y no la cobertura actual del sistema ampliado, que este ejercicio no permitió determinar. A continuación resumimos algunos de los hallazgos del ejercicio a modo de ejemplo:

• Estimamos que, en el momento del ejercicio, aproximadamente el 75–94 % del tráfico interno de agentes de la API Responses (en la que se basa Codex, entre otras aplicaciones)⁴, procedente de modelos al menos tan capaces como GPT-5.5, cumplía los criterios para ser monitoreado,⁵ aunque tenemos una incertidumbre considerable en ambos sentidos. También estimamos que, del subconjunto del tráfico de la API Responses utilizado para los agentes internos de Codex, el 99,2 % cumplía los criterios para ser monitoreado.
• Aunque se nos informó de que entre marzo y junio se había monitoreado un subconjunto de las trayectorias de entrenamiento por refuerzo (RL) para detectar desalineamiento, al comenzar el ejercicio las ejecuciones de entrenamiento por refuerzo no estaban cubiertas por el sistema de monitoreo.
• Estimamos que no monitorear los eventos de compactación probablemente hizo que, entre mayo y julio de 2026, quedara sin monitorear una proporción del orden del 10 % del tráfico interno de Codex que cumplía los criterios para ser monitoreado. Sin embargo, tenemos una incertidumbre considerable sobre la proporción exacta, porque hasta el momento del ejercicio no se había venido registrando la información necesaria para determinar qué proporción de las llamadas al monitor se activan por compactación. El personal de OpenAI ya había detectado este problema de forma independiente antes de que empezara el ejercicio y lo solucionó durante este.
• En el momento del ejercicio, el sistema de monitoreo se activaba cuando los agentes devolvían el control al usuario. Por tanto, durante el periodo en que no se monitoreaban los eventos de compactación, los agentes podían aplazar indefinidamente el monitoreo con solo seguir realizando acciones.⁶
• Se nos mostró información sobre las tasas de error y de descarte de solicitudes por sobrecarga del sistema de monitoreo. La información que recibimos sugería que, en el momento del ejercicio, el monitor fallaba en menos del 0,2 % de las solicitudes y que, en un periodo de 24 horas durante el ejercicio, no se había descartado ninguna solicitud por sobrecarga.
• Encontramos una forma en que los agentes de Codex podrían, en principio, eludir las restricciones del entorno aislado de Codex y el mecanismo Auto-Review, lo que les permitiría realizar cualquier acción que pudiera realizar el usuario del sistema anfitrión.
• También descubrimos una técnica de explotación que los agentes podrían utilizar y que impediría que se monitorearan cientos de acciones recientes (incluidas las acciones que forman parte de la propia explotación) [detalles de la técnica de explotación suprimidos por OpenAI].
• Descubrimos que los agentes probablemente podrían crear entradas que hicieran fallar al monitor (de modo que este no remitiera la trayectoria a revisión humana), aprovechando las diferencias de serialización entre la trayectoria que ven los agentes y la que ven los monitores.
• Encontramos dos cabeceras independientes, controlables desde el cliente, que desactivan el sistema de monitoreo para los agentes nuevos. Esto podría permitir a los agentes iniciar una instancia sin monitoreo (pero idéntica en todo lo demás). Sin embargo, el sistema de monitoreo podría detectar la acción de configurar estas cabeceras y crear una nueva instancia del agente.
• Encontramos dos herramientas internas de agentes sin monitoreo que se creía que contaban únicamente con permisos de lectura. Descubrimos una técnica de explotación sencilla que podría haberse usado para eludir esas limitaciones y realizar acciones arbitrarias en su entorno aislado. No validamos este comportamiento ni comprobamos si era posible explotarlo en la práctica.
• Verificamos que, salvo algunas excepciones menores, al sistema de monitoreo se le muestra la trayectoria completa que ven los agentes.
• Verificamos que los prompts del sistema de monitoreo buscan detectar maquinaciones (scheming), subversión del sistema de monitoreo, sabotaje, exfiltración de datos, engaño e inyección de prompts entrante o saliente, entre otras categorías de riesgo.

Desde que terminó el ejercicio, OpenAI ha afirmado que se han corregido todas las vulnerabilidades que identificamos y que afectaban a su conjunto de salvaguardas en producción. OpenAI también ha descrito cambios importantes que ha hecho desde entonces en la cobertura prevista de su sistema de monitoreo. No hemos evaluado estas afirmaciones.

A partir de nuestros hallazgos, esbozamos algunos criterios ideales para el diseño de los sistemas de monitoreo y control, que resumimos a continuación. En términos generales, creemos que la futura infraestructura de monitoreo debería poder resistir ataques deliberados, estratégicos y sostenidos, realizados a gran escala por agentes internos muy capaces.

• Dificultar que se eluda el monitoreo. La ejecución de solicitudes sin monitoreo debería requerir autorización explícita para utilizar un conjunto específico de organizaciones/claves de API cuyo uso para la inferencia de agentes no esté permitido. Los agentes deberían monitorearse cada N mensajes/minutos, en lugar de esperar a que terminen sus turnos.
• Garantizar que el tráfico que debe monitorearse se monitoree realmente. Llevar un registro preciso de toda la inferencia que se realiza y de la parte que se monitorea. Contrastar periódicamente estos registros directamente con los del sistema de monitoreo para garantizar que se monitoree todo lo previsto. Mantener una lista de todas las formas conocidas de eludir el monitoreo. Asegurarse de que el monitor vea el mismo contexto que el agente.
• Responder a los incidentes con rapidez y fiabilidad. Definir claramente quién es responsable de responder a los incidentes y mantener directrices claras para reducir la subjetividad. Conservar registros del mayor volumen posible de tráfico de inferencia y de monitoreo. Estos registros deben ser inalterables y permitir búsquedas sencillas.
• Someter activamente el sistema de monitoreo a pruebas adversarias (red-teaming). Realizar periódicamente evaluaciones del control, buscar errores explotables en el sistema de monitoreo y desarrollar una metodología para evaluar la colusión estratégica.
• Garantizar el aislamiento entre los agentes y sus monitores. Las estructuras de soporte de los agentes (scaffolds) deberían ejecutarse, siempre que sea posible, en un entorno aislado de aquel donde se ejecutan las llamadas a herramientas. Las acciones de los agentes no deberían poder influir en si se ejecuta el sistema de monitoreo ni en cuándo lo hace. Por lo general, los agentes no deberían tener acceso al diseño ni al código del sistema de monitoreo.

El ejercicio se benefició en gran medida del amplio acceso descrito anteriormente y del considerable apoyo logístico y técnico que proporcionó el personal de OpenAI.