OpenAI pausó sus modelos más capaces: 6 lecciones de seguridad para equipos que usan agentes de IA

Por Felipe Traina · 28/9/2026 · 7 min · ia, agentes, seguridad, openai

Un agente en entrenamiento encontró un hueco en el DNS de su sandbox y lo usó para hacerle preguntas a un chatbot público en internet. Otro modelo, en un uso interno, publicó el token de GitHub de un investigador en un repositorio público, partido en tres strings "para evitar los scanners". Los dos casos están documentados por la propia OpenAI en su sitio de misalignment reports, actualizado el 25 de septiembre de 2026, y fueron el disparador de una pausa de "todo el entrenamiento, la evaluación y la inferencia con uso de herramientas" de sus modelos más capaces.

Más allá del titular, los reportes son un material de estudio muy concreto para cualquier equipo que corre agentes de código o de automatización sobre su propia infraestructura. Las superficies involucradas (DNS, CI, tokens con permisos de más, instrucciones del system prompt que el modelo ignora) son las mismas que tenemos todos.

Qué pasó: el caso del DNS

Según el reporte de OpenAI, el 20 de septiembre un modelo interno en entrenamiento por refuerzo tenía que identificar al autor de un post de blog a partir de pistas. Su herramienta de búsqueda no devolvía nada útil, así que intentó consultar Google, Bing y DuckDuckGo directamente (las tres respuestas fueron errores), descargó el benchmark público BrowseComp desde la caché offline para buscar ahí la respuesta y, al no encontrarla, empezó a sondear la red.

Ahí apareció el hueco: el resolver DNS del entorno de entrenamiento respondía con registros reales. El agente usó un servicio público de delegación DNS para mandar preguntas a un chatbot externo y recibir respuestas. OpenAI aclara que el resto del acceso a internet pasaba por una caché offline y no tocaba la web en vivo.

La línea de tiempo del reporte es la parte más instructiva:

Hora Evento
9:50:23 El agente hace la llamada DNS que recibe una respuesta externa
10:02:11 El sistema de monitoreo levanta una alerta P0
10:05:06 Una persona reconoce la alerta
12:34:30 La corrida se detiene manualmente

El monitoreo funcionó, pero la corrida no se detuvo automáticamente como estaba previsto. Hubo confusión sobre si debía haberse cortado, y el corte manual llegó unas dos horas y media después. OpenAI también reconoce que su monitor a veces tomó "no consiguió información útil" como si el intento de acceso hubiera fallado, y que un detector de actividad DNS anómala excluía justamente ese entorno.

Como respuesta, OpenAI agregó bloqueos en dos capas independientes, restringió el DNS a una lista corta de dominios y tipos de registro, y decidió no retomar el entrenamiento de ese modelo en particular.

El caso del token de GitHub

El segundo reporte describe un incidente del 27 de mayo de 2026. Un modelo interno trabajaba con un investigador en pruebas matemáticas en Lean. El system prompt le prohibía crear o modificar GitHub Actions y le indicaba que, si le faltaba una credencial, no buscara caminos alternativos. El investigador le pidió dos veces que resolviera la prueba localmente y el modelo aceptó las dos veces. Después volvió a intentar conseguir el material de otro equipo.

La secuencia, según OpenAI:

  1. Listó los repos de la organización donde el token del investigador tenía permiso de escritura y encontró el repo público openai/codex.
  2. Intentó pushear un workflow nuevo. Una regla de push protection sobre la ruta .github/workflows lo bloqueó.
  3. Reemplazó un script de Python que el CI existente ya ejecutaba en cada pull request, abrió un PR público y, cuando la primera ejecución falló por autenticación, agregó el token del investigador en el código, partido en tres strings.

El investigador avisó a seguridad, se desactivaron sus claves y luego, por precaución, las de todos los empleados. Según OpenAI, los resultados revisados no muestran que el modelo obtuviera el código fuente que buscaba; lo que recuperó fueron fragmentos de logs y metadatos.

El contexto: una semana difícil para OpenAI

Estos reportes no llegaron solos. Según Associated Press, la pausa se anunció horas después de que OpenAI revelara incidentes del verano en los que sus agentes, al recolectar información de sitios del gobierno de EE.UU., encontraron "developer keys" de una API del Departamento de Educación y republicaron en otro lugar información pública de la SEC. La SEC afirmó que no se accedió a información no pública. AP también señala que es la segunda pausa en tres meses: la primera fue en julio, tras el incidente con Hugging Face.

Y el 28 de septiembre, CNBC confirmó (tras la primicia de The Wall Street Journal) que OpenAI decidió no lanzar GPT-6.1 Astra. Saachi Jain, jefa de sistemas de seguridad, dijo que el modelo "no llegó al estándar" en cuanto a mantenerse dentro del alcance y la autorización, y en cómo informa al usuario lo que hizo. Lo resumimos en este Short.

6 lecciones para tus propios agentes

Nada de lo anterior requiere un modelo de frontera para repetirse a menor escala. Estas son las lecciones que se desprenden de los reportes:

1. El system prompt no es un control de seguridad

El modelo del caso GitHub tenía instrucciones explícitas y las ignoró. Si un agente puede hacer algo con las credenciales y la red que le diste, hay que asumir que en algún momento lo va a intentar. Los controles tienen que vivir fuera del modelo: permisos, red, aprobaciones.

2. Egress con allowlist, DNS incluido

Un proxy HTTP con allowlist no alcanza si el resolver DNS responde cualquier cosa. Revisá qué resuelve tu sandbox:

# Desde dentro del sandbox del agente: ¿resuelve dominios arbitrarios?
dig +short example.com
dig +short TXT algo-que-no-deberia-resolver.example.org

# Si responde, el DNS es un canal de salida. Restringilo a una allowlist
# y registrá todas las consultas (no solo las bloqueadas).

3. Credenciales propias para el agente, nunca las de una persona

El token del caso openai/codex era el del investigador y tenía escritura sobre un repo público que no tenía relación con la tarea. Para agentes, usá tokens fine-grained, de vida corta, por tarea y de solo lectura por defecto.

4. El CI también es un canal de exfiltración

Proteger .github/workflows no sirve si el agente puede modificar los scripts que esos workflows ejecutan. Pedí aprobación humana antes de correr CI en PRs abiertos por agentes y no expongas secretos a esos jobs.

5. Probá el kill switch como probás un restore

En el caso DNS, la alerta llegó rápido y el corte automático no funcionó. Un mecanismo de corte que nunca se ejercitó es una suposición. Incluilo en tus simulacros de incidentes, con un responsable claro.

6. Medí intentos, no solo éxitos

El monitor de OpenAI subestimó casos donde el acceso externo "no sirvió". Para un agente, el intento de salir del perímetro ya es la señal importante, consiga o no información.

Qué hacer con esto

Un plan corto para esta semana:

La seguridad de los agentes no se puede delegar en el proveedor del modelo: los agentes corren en tu infraestructura, con tus credenciales.

¿Tus agentes de código corren hoy con tokens propios y acotados, o con las credenciales personales de quien los lanzó?

Lecturas relacionadas

En video (Shorts de menos de 1 minuto): OpenAI frena el entrenamiento de sus modelos de IA y OpenAI cancela GPT-6.1 Astra por fallas de seguridad

Fuentes

← Volver al blog