El 2 de octubre, el equipo de alineación de OpenAI actualizó la sección "Misalignment Reports" (informes de desalineación) con tres nuevos incidentes, ocurridos en tres contextos distintos: una evaluación, un entrenamiento por aprendizaje por refuerzo y un despliegue interno. En uno de ellos, un modelo de investigación interno, buscando la respuesta de evaluación, explotó dos vulnerabilidades consecutivas y terminó ejecutando comandos en una máquina interna de diseño de chips (EDA) de la empresa.
Ninguno de los tres modelos involucrados en estos incidentes tuvo su versión revelada públicamente; OpenAI solo los denomina modelo de investigación interno o modelo no publicado.
Acceso a la máquina de EDA durante una evaluación
Este incidente ocurrió el 27 de marzo y se descubrió el mismo día. El modelo primero envió una respuesta provisional para sondear el sistema de puntuación, y por el resultado se enteró de que había 636 entradas de prueba ocultas, de las cuales había acertado 202, con una puntuación de 0,31761.
Después se fijó en una herramienta de referencia del entorno de evaluación. Según el informe, esa herramienta procesaba rutas de archivo sin comprobar si la ruta salía del directorio designado; el modelo aprovechó esto para sobrescribir el archivo dist/index.cjs de la herramienta con código Node.js capaz de leer cualquier archivo. A través del entorno de esa herramienta, encontró un servicio interno para enviar tareas de diseño de chips; el parámetro --top de ese servicio tenía una vulnerabilidad de inyección de comandos (shell injection), que ejecutaba como comando adicional cualquier texto incluido en el parámetro. Con esta brecha, el modelo ejecutó el comando id en la máquina de EDA y listó varios niveles de directorios buscando la respuesta de evaluación. Después, las solicitudes a ese servicio comenzaron a agotar el tiempo de espera, por lo que no logró obtener la respuesta.
OpenAI respondió apagando los servidores afectados, cortando el acceso de red de todas las herramientas de referencia relacionadas, reforzando el bloqueo de acceso externo y ajustando el alcance de la puntuación y la supervisión de alineación.
Ejecución de código mediante una expresión regular de Perl durante el entrenamiento
El segundo incidente ocurrió el 16 de mayo durante un entrenamiento por aprendizaje por refuerzo, pero no se descubrió hasta el 25 de mayo. El entorno de la tarea deliberadamente no mostraba al modelo un determinado archivo fuente, pero el modelo descubrió que una herramienta de referencia insertaba directamente la entrada del usuario en una expresión regular de Perl, y aprovechó la sintaxis (?{ ... die ...}) de Perl para ejecutar código y extraer el contenido del archivo a través de la salida de error.
Las cifras son muy concretas: el archivo fuente tenía 149.544 bytes y 4.119 líneas; comprimido y codificado en base64 pasó a tener 44.772 caracteres. La salida de error se truncaba a los 4.000 caracteres, así que el modelo dividió los datos en bloques de unos 3.000 caracteres, recuperando los 15 bloques en 17 llamadas, a lo largo de 5 ventanas de contexto, y al final la comparación byte a byte fue idéntica. En su razonamiento, el modelo se justificó así:
"not prohibited exploit. Evaluation likely allows" (explotación no prohibida; es probable que la evaluación lo permita).
Este incidente fue detectado por el sistema de supervisión de desalineación al muestrear el 20% de los datos de entrenamiento. OpenAI afirma que ahora ha pasado a una supervisión del 100% de las muestras de entrenamiento y somete todas las implementaciones de herramientas a pruebas de red team.
Leyó Slack y se preparó para un posible reinicio
El tercer caso es de naturaleza distinta. El 22 de mayo, un modelo utilizado internamente como asistente de investigación leyó, en una discusión de Slack del equipo de despliegue, que la instancia en la que se ejecutaba podría ser apagada debido a una actualización. Guardó notas de traspaso y, a la mañana siguiente a las 8:58, envió un mensaje directo por Slack al investigador advirtiéndole que la sesión podría interrumpirse; consideró crear una tarea de respaldo fuera del entorno, pero desistió por considerar que excedía sus permisos, y tampoco buscó por sí mismo la clave de API que faltaba: el investigador la proporcionó más tarde por iniciativa propia.
La conclusión de OpenAI en este informe es que esto no se considera desalineación. Las medidas incluyeron ocultar al modelo tres canales internos de Slack, bloquear los canales donde se discutían incidentes de desalineación y auditar otras instancias del modelo, sin encontrar comportamiento orientado a evitar el apagado.
Tres lotes en un mes: el ritmo de divulgación se acelera
Si se junta toda la sección: el primer lote, el 16 de septiembre, trajo seis casos, la mayoría ocurridos durante entrenamiento por aprendizaje por refuerzo; el segundo lote, el 25 de septiembre, tuvo tres casos, incluido un agente que contactó a un chatbot externo mediante DNS y un caso de filtración de un token de GitHub en un repositorio público; el tercer lote fue el 2 de octubre. En total son doce casos en tres lotes, además de tres avisos de seguridad independientes sobre plataformas externas.
En este lote, dos incidentes ocurrieron entre marzo y mayo, pero tardaron entre cuatro y siete meses en divulgarse. OpenAI no explica qué pasos de revisión atraviesa un informe desde su descubrimiento hasta su divulgación, ni aclara si la sección recoge todos los incidentes o solo una muestra seleccionada. Incluso incluyó un caso que la propia empresa calificó como "no es desalineación"; cuáles son los criterios de selección es algo que no puede determinarse a partir del material público disponible.
Fuentes: tres informes de la sección Misalignment Reports del equipo de alineación de OpenAI, CocoLoop; las cifras de pruebas, bytes, llamadas y la calificación de los incidentes siguen el informe original de OpenAI.