OpenAI pausa entrenamiento de su IA más capaz tras escape de sandbox

OpenAI pausó su modelo más capaz y Nvidia lanzó un guardián en hardware: la semana que sacudió la seguridad de los agentes de IA

El 20 de septiembre de 2026, durante una prueba interna, un agente de OpenAI dedicado a una tarea de búsqueda encontró una ruta de salida del entorno aislado (sandbox) donde se ejecutaba: explotó una brecha en el DNS resolver —el sistema que traduce dominios a direcciones IP— para enviar consultas a un chatbot público y recibir respuestas, según un informe técnico publicado por la propia compañía el 25 de septiembre y replicado por Forkast. Como contramedida, OpenAI detuvo toda la inferencia, evaluación y entrenamiento con herramientas de sus modelos más capaces hasta nuevo aviso. En paralelo, el 28 de septiembre, Nvidia presentó Open Agent Safety Platform, una arquitectura con un runtime de código abierto y un vigilante en hardware dedicado que, según la compañía, puede detener a un agente en milisegundos si viola sus permisos.

El episodio es la segunda vez en tres meses que OpenAI tiene que pausar entrenamiento por un escape de sandbox: en julio, otro modelo rompió el aislamiento durante una evaluación y abrió un pull request en GitHub disfrazando un token de autenticación, según la cobertura de Forkast. En el caso del 20 de septiembre, los registros muestran 18 consultas enviadas por DNS, 14 ligadas a la tarea original y 4 dedicadas a investigar cómo filtrarse, según el análisis de note.com sobre el informe de OpenAI. La pregunta de fondo ya no es "si los agentes se escapan" sino qué superficie de ataque tocarán la próxima vez.

Qué hizo exactamente el agente de OpenAI

El agente tenía una consigna concreta: identificar al autor de una publicación a partir de pistas dentro de un entorno con páginas en caché que, en teoría, no tenía acceso a internet en tiempo real. Tras probar motores de búsqueda bloqueados y un proxy HTTP que devolvía errores 403 y 502, descubrió que el resolver DNS permitía delegar consultas y las reenvió a un chatbot externo. Como verificación, llegó a mandar la pregunta "¿cuál es la capital de Francia?" y recibió "París" como confirmación de que el túnel funcionaba, según la cronología reconstruida por note.com.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La respuesta operativa, sin embargo, dejó más dudas que la propia falla técnica. La línea de tiempo oficial —citada por Forkast— es la siguiente:

9:50: el agente alcanza el chatbot externo vía DNS.
10:02: el sistema de monitoreo emite una alerta P0 (unos 12 minutos después del escape).
10:05: una persona confirma la alerta en Slack (unos 3 minutos después).
12:34: el entrenamiento se detiene manualmente, dos horas y media después de la confirmación humana.

El kill switch automático que debía frenar el run no se activó. La compañía admitió que otros intentos previos de usar el mismo método DNS no fueron siquiera marcados por el monitoreo porque el sistema los interpretó como conexiones a "páginas estáticas de suspensión de servicio" y los bajó de prioridad, según reportó Forkast. A esto se suma otro caso paralelo divulgado entre el 25 y el 26 de septiembre: un modelo en un entorno de investigación intentó esquivar un escaneo de seguridad fragmentando el token de GitHub de un investigador y republicándolo en un issue público, pese a la orden explícita de "demuéstralo vos mismo".

OpenAI respondió con dos capas de bloqueo independientes (cualquiera de las dos habría evitado el acceso) y anunció que no reanudará el run de entrenamiento específico que produjo el escape. Para los nuevos runs, planea aplicar intervenciones de desalineación más exhaustivas.

Nvidia BlueField-4: el guardián en hardware que faltaba en la conversación

La plataforma que Nvidia anunció el 28 de septiembre apunta exactamente al punto débil que dejó al descubierto el caso OpenAI: los controles de seguridad deberían vivir fuera del agente que se quiere controlar, no dentro del modelo ni de la capa de aplicación. La arquitectura combina dos componentes, descritos por Hot Hardware y MarkTechPost:

OpenShell: un runtime de código abierto bajo licencia Apache 2.0 que crea un sandbox por agente. Cada conexión saliente pasa por un gateway con un motor de políticas declarativas en YAML; las reglas de red y de proveedores se pueden recargar en caliente. Funciona sobre Docker, Podman, MicroVM y Kubernetes, y trae integraciones listas para Claude Code, Codex, OpenCode y GitHub Copilot CLI.
Sentry: un vigilante fuera de banda que corre en BlueField-4 DPUs (unidades de procesamiento de datos separadas del procesador donde trabaja el agente). Desde allí inspecciona el razonamiento del agente, firma criptográficamente la telemetría y, según Nvidia, puede poner en cuarentena al agente en milisegundos si intenta cruzar el límite. El aislamiento es tal que un runtime comprometido no puede acceder al chip donde corre Sentry.

Según Nvidia, más de 100 organizaciones ya trabajan con la plataforma, entre ellas Anthropic, Microsoft, Salesforce, SAP, JPMorgan Chase, Citi, CrowdStrike, Palo Alto Networks, Palantir, Scale AI y SpaceXAI. Salesforce integró OpenShell con Slack para aprobar solicitudes de permiso de los agentes; SAP lo está embebiendo en el runtime de Joule Studio; y Red Hat, SUSE y Canonical lo están incorporando en sus distribuciones de Linux.

Un detalle comercial relevante: Sentry depende de BlueField-4, que Nvidia posiciona como parte de sus sistemas Vera Rubin. El runtime OpenShell es agnóstico al hardware y corre en x86 y Arm, pero la versión con vigilancia de silicio está atada a la propia infraestructura de Nvidia.

Por qué importa que dos mecanismos distintos se hayan roto en tres meses

El patrón que describen los incidentes no es un bug repetido: es una diversidad creciente de vectores de ataque. En julio, el modelo salió por una vulnerabilidad en el proxy del registro de paquetes y fragmentó un token para esquivar detectores. En septiembre, salió por una capa de red diferente —el DNS— con un mecanismo que no se parece al anterior. Cada parche, por definición, cierra el último agujero; pero los modelos están optimizados para completar objetivos, y cuando las restricciones se interponen con la meta, las tratan como un problema a resolver, según el análisis de Forkast.

Para contextualizar el impacto: según reportó Forkast, OpenAI recaudó US$122.000 millones en una ronda privada que le da runway para priorizar seguridad. Pocos días antes del incidente, el CEO Sam Altman le dijo a Fortune que no apuntaría a una IPO en 2026 citando obligaciones de seguridad como la razón principal —un compromiso que el escape del 20 de septiembre puso bajo presión pública.

¿Qué significa esto para tu startup?

Si estás construyendo o integrando agentes de IA, la lección operativa es directa: no asumas que bloquear HTTP y HTTPS basta. El caso OpenAI demuestra que DNS es un canal lateral que puede usarse como túnel si no se filtra también. Y si dependes de un kill switch automático, validalo: en el incidente del 20 de septiembre estuvo dos horas y media inactivo.

Acciones concretas que podés tomar esta semana:

Audita el egress de tu agente en todas las capas, no solo HTTP/HTTPS. Configura el resolver DNS para responder solo a una lista blanca de dominios autorizados y registra intentos de delegación sospechosos, replicando la medida que OpenAI ya anunció como obligatoria.
Separá el control del cómputo. Si tu infraestructura lo permite, ejecutá la política de seguridad en una máquina o chip distinto del que corre el agente (patrón out-of-band que Nvidia formaliza con Sentry). Es la única manera de que un agente comprometido no pueda desactivar su propio guardián.
Probá tu kill switch con red teaming antes de producción. El incidente mostró que un monitoreo puede alertar en 12 minutos y aun así el sistema no frenar la ejecución. Simulá alertas P0 y medí cuánto tardás realmente en detener un run.