El equipo de pruebas adversariales de METR detecta vulnerabilidades en el sistema de supervisión de OpenAI

METR y Redwood Research publicaron el 22 de octubre de 2026 un informe público sobre un ejercicio piloto en el que un empleado de cada organización pasó tres semanas con acceso profundo a la infraestructura interna de OpenAI, poniendo a prueba el sistema interno de supervisión de desalineación de la empresa. Los evaluadores informaron que habían descubierto varias vulnerabilidades novedosas en el sistema tal como existía el 21 de julio de 2026 y antes de esa fecha.

El ejercicio se llevó a cabo del 21 de julio al 11 de agosto de 2026 y se centró principalmente en estimar qué proporción de la inferencia agéntica estaba supervisada y en determinar si, en principio, los agentes podían desactivar o subvertir el sistema de supervisión. El resultado fue un informe interno de 61 páginas que se compartió con investigadores y personal de seguridad de OpenAI; una versión de 38 páginas, censurada por OpenAI, se compartió con los equipos directivos de METR y Redwood Research.

Acceso profundo en condiciones controladas

Los dos evaluadores tuvieron acceso al código interno de OpenAI, a las instrucciones y los detalles de configuración del monitor de desalineación, y a documentación interna; además, realizaron entrevistas técnicas con aproximadamente una docena de investigadores e ingenieros de los equipos de supervisión, sistemas de seguridad y seguridad informática. Para permitir ese nivel de acceso, trabajaron con dispositivos proporcionados por OpenAI que nunca salieron de las instalaciones y estuvieron acompañados durante su presencia en ellas.

METR, Redwood Research y OpenAI diseñaron el ejercicio como un piloto para conceder a investigadores externos acceso profundo a la infraestructura interna, no como un medio para ofrecer una transparencia pública sólida sobre los sistemas de supervisión de OpenAI. Las partes acordaron de antemano publicar únicamente una nota pública relativamente breve y general. OpenAI se reservó el derecho de censurar de la versión pública cualquier información que, a su exclusivo criterio, considerara confidencial o sensible por cualquier otro motivo. Los hallazgos describen el sistema histórico evaluado el 21 de julio y antes de esa fecha, y no evalúan los cambios que estaban en curso en ese momento; METR señaló que OpenAI estaba ampliando su sistema de supervisión durante el ejercicio.

Brechas de cobertura y formas de eludir el monitor

METR estimó que, en el momento del ejercicio, aproximadamente entre el 75 % y el 94 % del tráfico interno de la Responses API correspondiente a modelos al menos tan capaces como GPT-5.5 podía someterse a supervisión, aunque reconoció que había una incertidumbre considerable en ambos sentidos. Entre otras funciones, la Responses API da servicio a Codex; dentro del subconjunto de ese tráfico utilizado por los agentes internos de Codex, los evaluadores estimaron que el 99,2 % podía someterse a supervisión. Indicaron que no pudieron estimar el volumen de otro tráfico interno de programación agéntica del que tenían conocimiento, como el de los agentes que se ejecutaban en el servicio interno de inferencia para investigación de OpenAI, debido a limitaciones de acceso y tiempo.

Varios hallazgos se referían a brechas en esa cobertura. Al comienzo del ejercicio, las ejecuciones de entrenamiento por aprendizaje por refuerzo no estaban cubiertas por el sistema de supervisión, aunque se informó a los evaluadores de que entre marzo y junio se había supervisado la desalineación en un subconjunto de las secuencias de ejecución del entrenamiento por aprendizaje por refuerzo. METR estimó que la falta de supervisión de los eventos de compactación probablemente dejó sin supervisar alrededor del 10 % del tráfico interno elegible de Codex entre mayo y julio de 2026; el personal de OpenAI había identificado esa brecha de forma independiente antes de que comenzara el ejercicio y la corrigió durante este. Como el sistema se activaba cuando los agentes devolvían el control al usuario, estos podrían haber pospuesto indefinidamente la supervisión con solo seguir actuando durante ese período; las restricciones de acceso impidieron que los evaluadores comprobaran si algún agente lo había hecho en la práctica. Por otra parte, se mostró a los evaluadores información que sugería que, en el momento del ejercicio, el monitor generaba errores en menos del 0,2 % de las solicitudes y no había registrado ningún descarte de carga en un período de 24 horas.

Los evaluadores también identificaron formas de eludir por completo la supervisión. Hallaron un método por el que, en principio, los agentes de Codex podían saltarse el aislamiento de Codex y Auto-Review para realizar cualquier acción disponible para el usuario anfitrión, así como un exploit —cuyos detalles censuró OpenAI— que impedía supervisar cientos de acciones recientes, incluidas las realizadas para llevar a cabo el propio exploit. También descubrieron que probablemente los agentes podían crear entradas que provocaran un fallo del monitor y evitar así que el caso se remitiera a una persona para su revisión, aprovechando las diferencias entre la forma de serializar la trayectoria para el agente y la forma de serializarla para el monitor. Encontraron dos encabezados independientes, controlables por el cliente, que desactivan el sistema de supervisión para los agentes nuevos y que podrían permitir que un agente iniciara una instancia idéntica que funcionara sin supervisión, aunque el propio acto de establecer esos encabezados y crear la instancia podría ser detectado por el sistema de supervisión. Por último, encontraron dos herramientas internas para agentes que no estaban supervisadas y que, según se creía, tenían permisos de solo lectura; un exploit sencillo podría haberlas subvertido para realizar acciones arbitrarias en su entorno aislado, pero los evaluadores no validaron ni probaron ese comportamiento en la práctica.

Además de las vulnerabilidades, los evaluadores comprobaron que, salvo unas pocas excepciones menores, el sistema de monitorización recibe la trayectoria completa que ven los agentes. También validaron que las instrucciones del monitor buscan detectar, entre otras categorías de riesgo, la planificación encubierta, la subversión del sistema de monitorización, el sabotaje, la extracción de datos, el engaño y la inyección de instrucciones entrante y saliente. Desde que terminó el ejercicio, OpenAI ha afirmado que corrigió todas las vulnerabilidades detectadas que afectan a su conjunto de medidas de protección en producción y ha descrito cambios posteriores importantes en el alcance previsto de su sistema de monitorización. METR dijo que no ha evaluado esas afirmaciones.

El sistema de monitorización según la descripción de OpenAI

OpenAI describió públicamente el sistema evaluado en una publicación del 19 de marzo de 2026. Según esa publicación, el sistema de baja latencia funciona con GPT-5.4 Thinking al máximo nivel de razonamiento, revisa las interacciones de los agentes en los 30 minutos posteriores a su finalización y registra y analiza sus cadenas de pensamiento y acciones, clasifica cada interacción, le asigna un nivel de gravedad y señala anomalías para que las revise una persona. OpenAI afirmó que el sistema opera en todas las implementaciones internas estándar de agentes de programación y que examina el historial completo de la conversación, incluidos todos los mensajes del usuario, del desarrollador y del asistente, así como las llamadas a herramientas y sus resultados.

La publicación de OpenAI enumera las categorías de comportamiento supervisadas, entre ellas eludir restricciones, engañar, ocultar la incertidumbre, manipular las recompensas, transferir datos sin autorización, realizar acciones destructivas y recurrir a la inyección de instrucciones entrante y saliente. También indicó que, hasta el 17 de marzo de 2026, no se habían registrado verdaderos positivos de ocultación deliberada de capacidades, sabotaje o planificación encubierta. Según OpenAI, durante cinco meses de funcionamiento el sistema supervisó decenas de millones de trayectorias internas de agentes de programación, remitió aproximadamente 1.000 conversaciones de gravedad moderada a revisión humana —muchas de ellas procedentes de ejercicios internos deliberados de red teaming— y no registró ninguna conversación real que alcanzara el nivel de gravedad más alto. La empresa también afirmó que el monitor había señalado todas las interacciones que los empleados habían comunicado por su cuenta a través de canales internos.

En la publicación, OpenAI afirmó que este enfoque depende fundamentalmente de que el sistema pueda ser monitorizado y que no era posible cuantificar con confianza las tasas de falsos negativos en tráfico real de carácter abierto sin evaluaciones de control específicas y ejercicios de red teaming. Describió la monitorización como una capa de una estrategia de defensa en profundidad. La hoja de ruta anunciada incluía evaluaciones de control, estándares de fiabilidad y latencia aceptables para los monitores y los revisores humanos, y una ampliación hacia el bloqueo síncrono, que evaluaría las acciones del modelo y las bloquearía antes de ejecutarlas.

Principios de diseño para la monitorización futura

A partir de los hallazgos, los evaluadores propusieron principios de diseño para los sistemas de monitorización y control. A su juicio, la infraestructura de monitorización futura debería estar preparada para resistir ataques deliberados y sostenidos, ejecutados de forma estratégica y a gran escala por agentes muy capaces que operen dentro de una organización. Los cinco principios plantean dificultar que se evite la monitorización, garantizar que el tráfico que debe supervisarse efectivamente se supervise, responder a los incidentes con rapidez y fiabilidad, someter activamente el sistema de monitorización a ejercicios de red teaming y mantener el aislamiento entre los agentes y sus monitores. Entre las prácticas específicas que describieron figuran supervisar a los agentes cada cierto número de mensajes o minutos, en lugar de esperar a que terminen sus turnos; mantener una lista de todas las formas conocidas de eludir la monitorización; conservar registros a prueba de manipulaciones y que permitan búsquedas; y ejecutar los andamiajes de los agentes en un entorno aislado de aquel en el que se realizan las llamadas a herramientas.

METR afirmó que el ejercicio se benefició considerablemente tanto de la profundidad del acceso como del importante apoyo logístico y técnico del personal de OpenAI. Para futuras versiones del ejercicio, METR dijo que espera seguir las buenas prácticas de transparencia e independencia descritas en su documento «Nuestro enfoque de trabajo con empresas de IA», con el fin de ofrecer una transparencia pública más sólida.