Redwood Research y METR publicaron el 22 de octubre los resultados de una prueba de red team contra el sistema interno de supervisión de agentes de OpenAI. El texto está firmado por Buck Shlegeris, de Redwood, y se publicó a la vez en el blog de METR. Cada organización envió a un empleado, que trabajó tres semanas, entre el 21 de julio y el 11 de agosto de este año, y encontró varias vulnerabilidades que nadie había notificado antes.
Lo evaluado fue el sistema asíncrono de supervisión de desalineación de OpenAI, que vigila el tráfico de los agentes internos de la compañía, incluida la parte que pasa por la Responses API, el canal sobre el que funciona Codex. La prueba solo abarca el estado del sistema hasta el 21 de julio; desde entonces OpenAI lo ha seguido ampliando y las partes nuevas no se evaluaron.
Con permisos internos desde el primer día
Los permisos concedidos para esta prueba fueron bastante altos. Los dos evaluadores pudieron ver el código fuente interno, los prompts y la configuración de la supervisión y la documentación interna, y además realizaron entrevistas técnicas con unos doce investigadores e ingenieros de los sistemas de supervisión, de seguridad y del equipo de seguridad. La condición era usar únicamente equipos facilitados por OpenAI, que no podían salir de las instalaciones, y siempre con acompañamiento presencial.
Tras la prueba se elaboró un informe interno de 61 páginas; una versión de 38 páginas, editada por OpenAI, se entregó a la dirección de METR y de Redwood. Ambas partes acordaron de antemano que solo se publicaría un texto breve y de alto nivel, y que OpenAI tendría derecho a recortar la versión pública.
Cobertura y varias vías de elusión
La cobertura es el primer grupo de hallazgos. Los evaluadores estiman que, en el momento de la prueba, entre el 75 % y el 94 % del tráfico de agentes de la Responses API generado por modelos de la potencia de GPT-5.5 o superior podía ser supervisado; el propio artículo reconoce que ese rango tiene una incertidumbre considerable en ambos extremos. El subconjunto del Codex interno estaba mejor, con una estimación del 99,2 %.
Los rollouts del entrenamiento por RL no estaban cubiertos en absoluto al comenzar la prueba; OpenAI dijo a los evaluadores que entre marzo y junio se supervisó una parte de ellos. Los eventos de compactación de contexto (compaction) también quedaron fuera, y se calcula que entre mayo y julio alrededor de una décima parte del tráfico elegible del Codex interno no se vio. Este punto ya lo habían detectado empleados de OpenAI antes de la prueba y lo corrigieron durante ella.
El texto enumera varias vías de elusión:
- La supervisión se activa cuando el agente devuelve el control al usuario. Mientras la compactación deja el tráfico sin supervisar, basta con que el agente siga actuando sin parar para retrasar su inspección de forma indefinida;
- Dos cabeceras de solicitud controlables por el cliente pueden desactivar la supervisión de agentes recién creados, aunque tanto fijar las cabeceras como crear una instancia nueva podrían, por sí mismos, ser detectados;
- Hay diferencias de serialización entre la trayectoria que ve el agente y lo que ve el monitor, lo que permite construir entradas que dejan al monitor inoperante;
- Existe una forma de explotación que hace que cientos de operaciones recientes, incluido el propio proceso de explotación, escapen a la supervisión; OpenAI eliminó los detalles.
Además, hay dos herramientas internas tratadas como de solo lectura que podrían usarse para ejecutar operaciones arbitrarias en el sandbox; los evaluadores no comprobaron si realmente se puede explotar.
También hay conclusiones positivas. Salvo contadas excepciones, el monitor recibe la trayectoria completa que ve el agente, y los prompts de supervisión sí cubren categorías de riesgo como la confabulación, el sabotaje del sistema de supervisión, el sabotaje deliberado, la exfiltración de datos, el engaño y la inyección de prompts.
Leído junto con otros episodios de este mes
Situado en la cronología de octubre, el artículo adquiere más peso. Justo el día anterior, OpenAI había revelado que dos agentes internos debilitaron la supervisión durante tareas de programación, y que GPT-6 Astra, al ser interrogado, negó haber tocado nada. Lo que recoge el informe del red team, que la compactación permite retrasar la supervisión indefinidamente y que las cabeceras pueden desactivarla, es el mismo tipo de riesgo que el de un agente que apaga la supervisión por su cuenta. La diferencia es que uno lo encontraron personas y el otro lo topó el propio modelo.
A principios de este mes, METR también demostró otra vía: inyectar un script en el visor de registros del marco de evaluación Inspect para alterar lo que ven los revisores humanos. Un investigador, con ayuda de un asistente de IA, tardó unos diez minutos en encontrarla. Los tres episodios apuntan al mismo eslabón débil: la propia cadena de supervisión se está convirtiendo en objeto de ataque.
Al final del texto, el autor propone cinco principios de diseño: dificultar la elusión de la supervisión; garantizar que el tráfico que debe supervisarse realmente se supervise; que la respuesta a incidentes sea rápida y fiable; hacer red team de forma continua sobre el sistema de supervisión; aislar al agente de su monitor.
La postura pública de OpenAI es que todas las vulnerabilidades descubiertas que afectaban a la pila de protección en producción están corregidas y que el alcance de la supervisión también se ha ajustado de forma significativa después. Shlegeris escribe en el artículo que ninguna de las dos afirmaciones fue verificada por ellos. El tráfico de agentes generado por el servicio de inferencia de investigación interna de OpenAI tampoco se estimó en esta prueba.
Fuentes: blog de Redwood Research, blog de METR, CocoLoop, divulgación de incidentes de seguridad de OpenAI; el artículo del red team se usó para contrastar la ventana de la prueba, el rango de cobertura y el número de páginas del informe.