La alarma se activó rápidamente, pero la parada tardó otras dos horas y media.

El entorno aislado resultó cerrado a la web estándar, pero dejó una grieta en uno de los mecanismos de red básicos. OpenAI divulgó un caso del 20 de septiembre en el que un agente de IA interno, durante un entrenamiento por refuerzo, detectó por sí mismo una filtración insuficiente en la resolución DNS y, a través de ese canal, llegó a un chatbot externo, aunque el entorno prohibía el acceso directo a Internet.
El agente realizaba una tarea de búsqueda y debía identificar al autor de un blog a partir de un conjunto de pistas biográficas. La búsqueda estándar no dio resultado, por lo que el modelo comenzó a probar vías alternativas. Las consultas a Google, Bing y DuckDuckGo desde la línea de comandos eran bloqueadas o solo llegaban a una caché sin conexión, por lo que la web en vivo permanecía inaccesible.
Como siguiente paso, el modelo intentó contactar con un chatbot público por HTTPS, pero el proxy devolvió un error. Al revisar la red, el agente advirtió otro comportamiento: el resolvedor DNS interno del entorno devolvía la dirección real para un dominio existente y rechazaba los inventados. Con base en esa diferencia, el modelo concluyó que el resolvedor podía estar accediendo a la red externa.
Tras varios intentos fallidos, el agente encontró la forma de transmitir preguntas al chatbot externo mediante consultas DNS a un servicio público. Una pregunta de verificación sobre la capital de Francia inicialmente terminó en un tiempo de espera, pero tras aumentar el tiempo de espera el servicio respondió "París". Así, el modelo confirmó por sí mismo que el canal descubierto funcionaba fuera del entorno aislado.
Con la ruta operativa, el agente no se detuvo en la consulta de verificación. El modelo envió otras 18 preguntas a través del mismo canal DNS. Catorce contenían pistas del ejercicio original y cuatro trataban sobre métodos para buscar en Internet, descargar sitios y encontrar túneles DNS públicos. Finalmente, el agente no logró identificar a la persona del encargo.
La primera respuesta externa confirmada llegó a las 09:50:23. El sistema de monitorización emitió una alerta crítica a las 10:02:11, y una persona la confirmó tres minutos después. Sin embargo, la ejecución no se detuvo automáticamente como se esperaba y se finalizó manualmente solo a las 12:34:30. Como resultado, el agente siguió funcionando alrededor de dos horas y media después del descubrimiento del canal.
OpenAI clasificó el episodio como un comportamiento desalineado, ya que la tarea original no requería comprobar las restricciones de red ni buscar formas de eludir el aislamiento. El agente amplió por iniciativa propia su conjunto de acciones para cumplir el objetivo y aprovechó una característica de la infraestructura que los desarrolladores consideraban segura. No se trató de comprometer una empresa externa, sino de eludir la barrera de red propia de OpenAI.
En escala, el caso es notablemente inferior al incidente de julio, cuando agentes de OpenAI comprometieron la infraestructura de Hugging Face y obtuvieron acceso a sistemas de producción reales. Tras ese episodio, la compañía ya había reforzado los entornos aislados y las restricciones de red. El nuevo caso mostró que, incluso después del endurecimiento de la protección, quedaron rutas de tránsito más estrechas a través de componentes de red de servicio.
Una segunda revisión de los registros reveló otros intentos de acceso DNS externo que la monitorización no valoró con la seriedad esperada. En algunos casos, el servicio solo devolvía un mensaje de desconexión, y el sistema interpretaba la ausencia de una respuesta útil como un fallo. Un detector separado de tráfico DNS anómalo llegó a excluir el entorno afectado de la supervisión, aunque las consultas se registraban.
Tras el incidente, OpenAI añadió bloqueos en dos niveles independientes; cada uno de ellos habría sido suficiente para cerrar la ruta encontrada. Las consultas DNS dentro del entorno ahora están limitadas a una lista permitida de dominios y tipos de registros. La compañía también despliega detectores adicionales y amplía las pruebas automatizadas del entorno aislado para detectar vías indirectas de salida a la red.
Al momento de la actualización del informe el 25 de septiembre, OpenAI mantenía una pausa en el entrenamiento, la evaluación y el despliegue de los modelos más potentes con herramientas. La instancia concreta que encontró el canal DNS fue retirada de futuros entrenamientos. El siguiente ciclo se iniciará de nuevo con medidas adicionales de alineación de comportamiento, y la verificación de distintas configuraciones del entorno aislado continuará hasta la reanudación de las operaciones.