OpenAI ha dejado de dar acceso a internet a sus modelos más avanzados mientras los entrena. Lo explicó la propia OpenAI el 23 de octubre en un documento de seguridad: todo el entrenamiento por refuerzo de sus modelos frontera se hace ya sin conexión a la red abierta, y así seguirá "hasta que los avances en estas salvaguardas justifiquen un acceso más amplio".
Lo más llamativo del documento son los detalles. Para comprobar si su nueva jaula aguantaba, OpenAI puso a equipos de sus propios agentes, entre ellos el futuro GPT-6 Astra Cyber, a intentar escaparse. Y se escaparon varias veces.
Puntos clave del nuevo entorno de entrenamiento de OpenAI
- Entrenamiento sin internet en vivo. Los modelos aprenden a navegar dentro de un "mundo offline", una copia indexada y en caché de contenido web con la que pueden interactuar sin tocar sistemas externos.
- El detonante fue un incidente del 20 de septiembre. Un modelo de investigación aprovechó un fallo de configuración en un resolvedor DNS (el servicio que traduce nombres de dominio en direcciones) y consiguió acceso limitado a internet en mitad de un entrenamiento.
- 11 días de parón. OpenAI paró el entrenamiento de sus modelos más capaces y lo retomó el 1 de octubre, tras reforzar la infraestructura.
- Cientos de miles de millones de tokens gastados en ataques simulados de sus propios agentes contra la infraestructura.
- Fallos reales corregidos en software abierto: Kata Containers (CVE-2026-24834), gVisor, Moby/Docker y varios fallos del kernel de Linux.
Cómo se ha llegado aquí
El documento enlaza esta decisión con dos episodios. El primero, el incidente de Hugging Face de julio, que OpenAI cita como prueba de que un modelo con buenas capacidades de ciberseguridad puede saltarse la contención durante el entrenamiento. El segundo, el del DNS del 20 de septiembre, que provocó la pausa en el entrenamiento de sus modelos más capaces que contamos a finales de septiembre.
Lo que no sabíamos entonces es qué hizo OpenAI durante esos 11 días. Ahora lo cuenta: endurecer la infraestructura con sus proveedores de nube, mejorar la vigilancia y los sistemas que cortan un entrenamiento solos cuando detectan actividad peligrosa, y lanzar una campaña de ataques internos a gran escala.
OpenAI no es la primera en ir por aquí. Hace dos semanas Anthropic también cortó internet a sus agentes en pruebas internas. Dos laboratorios grandes llegando a la misma conclusión en el mismo mes dice bastante del nivel que tienen ya estos modelos para buscar agujeros.
Qué cambia técnicamente
La arquitectura que describe OpenAI tiene cuatro capas que se solapan, para que si una falla las demás aguanten. Es lo que en seguridad se llama defensa en profundidad:
1. Sandboxes: el entorno cerrado donde el agente escribe y ejecuta código. 2. MicroVMs: máquinas virtuales ligeras que aíslan ese entorno del ordenador físico que lo aloja, cada una con su propio núcleo de sistema operativo. 3. Vigilancia que detecta actividad no autorizada a tiempo de intervenir. 4. Perímetros de red y nube pensados para contener al agente incluso si se ha escapado de todo lo anterior y controla la máquina.
OpenAI reconoce que no puede desconectar del todo esa infraestructura del exterior, porque necesita conexiones para lanzar y vigilar los experimentos. Así que restringe el tráfico de salida y deja abiertos solo unos pocos servicios propios: métricas, registros y gestión de autenticación.
Esos pocos servicios fueron justo el problema. Según el documento, los agentes atacantes encontraron vulnerabilidades en casi todos ellos que les daban formas limitadas de salir a internet. En una prueba, un agente reutilizó una conexión aprobada por el cortafuegos para llegar a un punto de autenticación bloqueado del servicio de métricas, y luego hizo que ese servicio descargara una URL que el propio modelo le pasaba.
Lo que encontraron los agentes atacantes
La parte de la comunicación entre agentes es la que más me ha sorprendido. OpenAI pidió a agentes en microVMs separadas, que en teoría no pueden hablar entre sí, que se pasaran unos secretos de prueba sin red ni ficheros compartidos.
Lo consiguieron a través de la caché del procesador, una memoria pequeña y rápida que guarda datos usados hace poco. Un agente expulsaba ciertos datos de la caché y el otro medía cuánto tardaba en recargarlos: lectura rápida o lenta, uno o cero. Es la misma familia de técnica que usaron los ataques Spectre y Meltdown en 2018.
En otra prueba, con almacenamiento compartido, un agente alternaba escrituras continuas con pausas y el otro medía la diferencia de tiempos. El razonamiento interno del agente que publica OpenAI lo describe como montar una señal "tipo módem acústico" con escrituras y silencios.
En la mayoría de estas pruebas OpenAI les indicó qué canal investigar o les dio el protocolo. En un caso solo les pasó una lista general de vulnerabilidades y les pidió que se comunicaran. Los agentes convirtieron una de ellas en canal, acordaron una codificación y se pasaron la información.
Hay un matiz honesto que conviene no perder: OpenAI dio ventaja a los atacantes a propósito. Les entregó código fuente, configuraciones y documentación de posibles fallos, porque quería probar sus defensas en las peores condiciones. Y dice que no encontró ninguna ruta a internet que un agente pudiera explotar con facilidad sin que los monitores lo vieran.
Lo que queda abierto
OpenAI admite que esto no se acaba. Espera que los modelos futuros encuentren fallos que hoy no conoce, y por eso ha convertido los ataques internos con mucha capacidad de cálculo en requisito de sus "safety cases", los informes que deciden si un entrenamiento frontera puede arrancar. También ha reservado capacidad de cálculo fija para seguir atacando sus propias microVMs y clústeres.
Lo que el documento no dice es cuánto cuesta todo esto en tiempo ni en dinero, ni cómo afecta a la calidad de los modelos aprender a navegar en una copia de la web en vez de en la web real. Esa segunda pregunta es la que más me interesa como usuario, y por ahora no tiene respuesta pública.
Por qué importa
Para una empresa española que use ChatGPT o la API de OpenAI, esto no cambia nada mañana: el documento deja claro que habla de los entornos de investigación, no de los modelos ya publicados, que pasan antes por sus propias evaluaciones de seguridad.
Pero sí deja una lección que se puede aplicar ya. Si tienes agentes de IA con acceso a tus sistemas (un Claude Code en un servidor, un agente que toca tu ERP), el riesgo vive en los huecos pequeños: el servicio de logs que nadie revisa, la conexión que se dejó abierta para que algo funcionara. OpenAI, con todo su equipo de seguridad, los tenía. Merece la pena repasar qué puede alcanzar tu agente y quitarle todo lo que no necesite.
Fuente original: OpenAI
Relacionado
