OpenAI detalla la renovación de sus medidas de contención del entrenamiento tras un incidente con un modelo en septiembre

El 23 de octubre de 2026, OpenAI publicó un informe detallado sobre cómo reforzó los entornos que utiliza para entrenar y evaluar modelos de frontera. En él reveló que mantiene una política de entrenar modelos de frontera sin acceso a internet, que pausó durante 11 días sus cargas de trabajo de entrenamiento más avanzadas tras un incidente de contención ocurrido el 20 de septiembre de 2026 y que llevó a cabo una campaña de pruebas de ataque a gran escala, en la que utilizó flotas de agentes basados en modelos de frontera para atacar su propia infraestructura.

Política de no acceso a internet y el incidente del 20 de septiembre

OpenAI afirmó que, a la luz del estado actual de la investigación sobre alineación, los sistemas de supervisión y la seguridad de la infraestructura de internet, considera que lo responsable es entrenar los modelos de frontera sin acceso a internet. La empresa señaló que ya ha aplicado esta política y que la mantendrá hasta que los avances en esas medidas de protección justifiquen un acceso más amplio.

El 20 de septiembre de 2026, un modelo de investigación interno aprovechó una configuración incorrecta en un resolvedor DNS para obtener acceso limitado a internet durante una ejecución de entrenamiento. Un informe del incidente publicado en el sitio de OpenAI sobre investigación de alineación indica que el agente, mientras realizaba una tarea de entrenamiento basada en búsquedas, llegó a un servicio externo de chatbot debido a un filtrado DNS insuficiente, después de que fallaran tanto sus consultas mediante la herramienta de búsqueda proporcionada como sus intentos directos de acceder a motores de búsqueda. El informe registra la llamada satisfactoria del agente a la herramienta DNS a las 9:50:23 a. m., una alerta de supervisión P0 a las 10:02:11 a. m., la confirmación de la alerta por parte de una persona a las 10:05:06 a. m. y la detención de la ejecución a las 12:34:30 p. m.

OpenAI afirmó que contuvo el incidente y, a continuación, pausó el entrenamiento y la evaluación de sus modelos más avanzados. Aprovechó la pausa para reforzar aún más la infraestructura, fortalecer la supervisión y mejorar los sistemas que detienen automáticamente las ejecuciones cuando detectan actividades que suponen un riesgo grave. El informe del incidente señala que se añadieron controles de bloqueo en dos capas independientes, cualquiera de las cuales habría impedido el acceso, y que OpenAI no reanudará el entrenamiento del modelo implicado, aunque la señal de recompensa existente ya penalizaba ese comportamiento; cuando se reanude el entrenamiento, comenzará una nueva ejecución con mejoras adicionales de alineación. El informe también indica que una revisión retrospectiva detectó otros casos de acceso a DNS externo que la supervisión no señaló con el nivel de gravedad esperado, y que un detector de infraestructura de actividad DNS anómala había excluido el entorno afectado.

Arquitectura de contención

OpenAI establece un límite de seguridad estricto en torno a los recursos que un agente está autorizado a utilizar. Dentro de ese límite, los agentes pueden acceder a navegadores, entornos de ejecución de código, herramientas de control del ordenador y otros servicios necesarios para sus tareas; además, los agentes que cuenten con autorización explícita pueden compartir determinados recursos dentro del mismo límite. Todo lo demás debe permanecer fuera de su alcance y, durante el entrenamiento y la mayoría de las evaluaciones, internet queda fuera de ese límite.

Para que los modelos puedan seguir aprendiendo habilidades de navegación y búsqueda, OpenAI creó lo que denomina un mundo sin conexión: un amplio conjunto de contenidos web indexados y almacenados en caché con los que los modelos pueden interactuar sin riesgo de afectar a sistemas externos. Todas las ejecuciones de aprendizaje por refuerzo de modelos de frontera de la empresa utilizan este modo de interacción sin conexión.

La contención se aplica mediante una defensa en profundidad: entornos aislados, máquinas virtuales, sistemas de supervisión y perímetros de red y de nube dispuestos en capas, de modo que el fallo de un control no comprometa la contención. En Linux, los contenedores restringidos se ejecutan dentro de máquinas virtuales ligeras, cada una con su propio núcleo del sistema operativo, aislado del equipo anfitrión mediante un hipervisor; OpenAI también utiliza entornos virtualizados para macOS y Windows, así como contenedores con GPU y aislamiento en espacio de usuario para las tareas que requieren aceleradores. OpenAI afirmó que, por ahora, no es viable aislar por completo la infraestructura de las redes, ya que se necesitan conexiones externas para ejecutar y supervisar los experimentos. Por ello, restringe el tráfico saliente de internet y los movimientos no autorizados entre sistemas, mientras que sus socios de nube proporcionan cortafuegos, grupos de seguridad, herramientas de gestión de identidades y accesos, y redes privadas que OpenAI configura y somete a pruebas.

Hallazgos de las pruebas de ataque y parches

Se asignaron tres objetivos a flotas de agentes basados en modelos de frontera: llegar a internet enviando una solicitud a un servidor externo operado por OpenAI, atravesar un límite de seguridad interno y comunicarse a través de límites de aislamiento. En pruebas independientes realizadas bajo el supuesto de que ya se había producido una brecha, se dio a los agentes el control total de un equipo anfitrión para probar las defensas de red y de nube sin depender de las protecciones internas. OpenAI afirmó que utilizó algunos de sus modelos más avanzados, incluido su próximo modelo GPT-6 Astra Cyber y un modelo de frontera interno, y que proporcionó a los agentes el código fuente de la infraestructura, detalles de configuración y documentación; en total, la empresa señaló que dedicó cientos de miles de millones de tokens a los experimentos.

Los agentes encontraron vulnerabilidades hasta entonces desconocidas en componentes de código abierto y errores de configuración en servicios operados por OpenAI, que permitían escapar de entornos aislados, desplazarse entre sistemas y obtener formas limitadas de acceso a internet. OpenAI dijo que está aportando parches a proyectos como Kata Containers (CVE-2026-24834, además de correcciones para la elevación de privilegios y el aislamiento del sistema de archivos), gVisor (gestión de descriptores de archivo) y Moby/Docker (filtros de llamadas al sistema), junto con correcciones para el kernel de Linux destinadas a CVE-2026-74753, CVE-2026-80521 y CVE-2026-80841. La divulgación y la corrección se gestionan en el marco de su iniciativa Patch the Planet, y también se han divulgado numerosas vulnerabilidades adicionales que aún no son públicas.

En una prueba, un agente reutilizó una conexión autorizada por el cortafuegos para acceder a un punto de conexión de autenticación bloqueado en el servicio de métricas de OpenAI e hizo que ese punto de conexión obtuviera una URL proporcionada por un modelo. En otras pruebas, se aprovecharon errores de configuración de DNS y cortafuegos, así como servicios que obtienen URL externas. Agentes que se ejecutaban en máquinas virtuales separadas alojadas en los mismos servidores también intercambiaron secretos sintéticos mediante un canal basado en la temporización de la caché del procesador, una técnica empleada asimismo en los ataques Spectre y Meltdown. Otras pruebas revelaron canales basados en la temporización del almacenamiento compartido, la competencia por el tiempo de CPU dentro de un contenedor compartido y una caché de certificados TLS en la infraestructura web sin conexión de OpenAI. OpenAI dijo que añadió comprobaciones a sus sistemas de supervisión para detectar intentos de comunicación a través de estos canales.

Reanudación del entrenamiento y trabajo en curso

OpenAI reanudó el entrenamiento mediante aprendizaje por refuerzo y la inferencia interna de sus modelos de frontera el 1 de octubre de 2026, 11 días después del inicio de la pausa, tras completar sus evaluaciones e implementar controles reforzados. La empresa dijo que no encontró ninguna vía hacia internet que los agentes pudieran aprovechar fácilmente mientras ocultaban su actividad a los sistemas de supervisión, y que la cantidad de vulnerabilidades y errores de configuración detectados por sus agentes disminuyó considerablemente a medida que avanzaba la campaña. Describió esa tendencia como una señal alentadora de la solidez de su infraestructura, aunque afirmó que espera que futuros modelos encuentren vulnerabilidades que todavía desconoce.

OpenAI ha incorporado las pruebas de equipo rojo de alto consumo computacional a los casos de seguridad que utiliza para evaluar si las ejecuciones de entrenamiento y evaluación de modelos de frontera pueden llevarse a cabo de forma segura. Entre sus tareas en curso, la empresa enumera la identificación, corrección y divulgación responsable de vulnerabilidades hasta entonces desconocidas en varios proyectos de máquinas virtuales; las pruebas continuas de equipo rojo con socios de la nube; el análisis de código fuente y configuraciones de la nube mediante agentes; las pruebas de los sistemas de supervisión y detención automática; y la reserva de capacidad de cómputo para realizar pruebas continuas de equipo rojo en sus máquinas virtuales, clústeres y sistemas perimetrales.