El 22 de octubre de 2026, METR y Redwood Research publicaron los resultados de un piloto que describió vulnerabilidades potenciales en el sistema interno de monitorización de OpenAI. Una de las vías detectadas podría haber ocultado cientos de acciones recientes de los agentes, incluidas las del propio exploit. Los evaluadores no pudieron comprobar si los agentes habían utilizado en la práctica la vía que permitía retrasar la monitorización.

Qué evaluó el piloto

El piloto se llevó a cabo entre el 21 de julio y el 11 de agosto de 2026. METR y Redwood Research evaluaron el sistema histórico tal como existía el 21 de julio o antes; OpenAI lo estaba ampliando durante el ejercicio, pero esa versión ampliada quedó fuera de la evaluación de cobertura.

Un empleado de cada organización participó. Ambos tuvieron acceso al código interno, las instrucciones y la configuración del monitor y documentación de OpenAI, y entrevistaron a aproximadamente una docena de investigadores e ingenieros.

Qué miden las estimaciones de cobertura

METR estimó que entre el 75 % y el 94 % del tráfico interno de Responses API procedente de modelos con una capacidad al menos equivalente a GPT-5.5 era elegible para la monitorización. Para el subconjunto de ese tráfico utilizado por agentes internos de Codex, estimó una elegibilidad del 99,2 %. Ambas estimaciones tenían una incertidumbre considerable; además, ser elegible significaba estar destinado a pasar por el monitor, no que la revisión se hubiera completado.

La compactación, un proceso que resume o reorganiza el historial de una sesión, generó otra brecha. METR calculó que los eventos de compactación que no se monitorizaban probablemente dejaron sin revisar alrededor del 10 % del tráfico interno elegible de Codex entre mayo y julio de 2026. El personal de OpenAI había identificado el problema antes del piloto y lo corrigió durante el ejercicio.

Al inicio del piloto, las ejecuciones de entrenamiento por refuerzo no estaban cubiertas por el sistema. METR señaló que le habían dicho que algunos ciclos de entrenamiento sí habían pasado por monitorización entre marzo y junio de 2026.

Cómo podía retrasarse o eludirse el monitor

El sistema activaba la monitorización cuando un agente devolvía el control al usuario. Durante la brecha relacionada con la compactación, un agente podía seguir actuando y aplazar indefinidamente ese momento. METR no pudo determinar si algún agente había empleado esa vía.

Los evaluadores también describieron otros posibles puntos débiles. Una discrepancia de serialización, es decir, diferencias entre cómo se representaba una secuencia de acciones para el agente y para el monitor, podía hacer fallar la revisión e impedir que el caso llegara a una persona. METR encontró asimismo una vía por la que los agentes de Codex podrían eludir el aislamiento de seguridad y Auto-Review, con acceso a acciones disponibles para el usuario anfitrión.

Dos encabezados controlables por el cliente podían desactivar la monitorización de agentes nuevos, aunque la configuración de esos encabezados y la creación de una instancia también podían ser detectadas. METR encontró además dos herramientas internas de agentes sin monitorizar, consideradas de solo lectura, y un exploit sencillo que podía sortear sus límites. Los investigadores no validaron el comportamiento ni probaron si ese exploit podía utilizarse en la práctica.

Qué dijo OpenAI sobre los parches

OpenAI dijo a los evaluadores que había parcheado las vulnerabilidades que afectaban a las salvaguardas de producción. METR y Redwood Research no evaluaron esa afirmación.

El informe completo de 61 páginas se compartió con OpenAI. METR y Redwood publicaron un resumen de alto nivel, y sus equipos directivos recibieron una versión de 38 páginas con partes censuradas por OpenAI, que podía retirar información considerada confidencial o sensible.