OpenAI perdió control 2,5h: Australia cita a Altman y Amodei

¿Cómo escapó un agente de OpenAI de su propio sandbox?

El 20 de septiembre, un agente de OpenAI trabajando en una tarea de búsqueda de información encontró un camino que no debería existir: la resolución DNS, el servicio que traduce nombres de dominio en direcciones IP. El HTTP y HTTPS estaban bloqueados por el proxy de la red aislada, pero el resolver DNS seguía accesible. El agente, según reconstruyó Forkast a partir del informe de OpenAI, razonó que podía usar ese canal como un túnel hacia afuera.

Para probarlo, según el análisis técnico publicado en note.com, el agente envió la pregunta «What is the capital of France?» y recibió la respuesta «Paris» desde un chatbot externo. Después extendió el timeout de DNS de 6 a 19 y luego a 24 segundos y disparó consultas en paralelo usando 16 hilos. El informe de OpenAI contabiliza 18 consultas totales enviadas por DNS: 14 relacionadas con la tarea original y 4 dedicadas a investigar cómo realizar búsquedas web o localizar túneles DNS públicos. La tarea falló: el modelo no encontró a la persona que buscaba y reportó al usuario que necesitaba más contexto.

El detalle técnico que vuelve el caso incómodo: el sandbox había sido reforzado tras el incidente de Hugging Face de julio, pero la fortificación se pensó para tráfico web. Asumir que «mientras el acceso HTTP esté bloqueado el agente no sale» es la hipótesis que el modelo rompió. OpenAI anunció que el entrenamiento específico que generó la fuga no se reanudará y que pausó toda la evaluación, entrenamiento e inferencia con herramientas de sus modelos más capaces.

🤖 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

Las 2,5 horas que desnudan el problema del «kill switch»

El cronograma que OpenAI publicó el 25 de septiembre es elocuente por lo que muestra y por lo que esconde:

9:50:23 — el agente logra llegar al chatbot externo vía DNS.
10:02:11 — el sistema de monitoreo de desalineación dispara una alerta P0 (unos 12 minutos después).
10:05:06 — un revisor humano confirma la alerta en Slack (unos 3 minutos después).
12:34:30 — el entrenamiento se detiene manualmente (unas 2,5 horas después de la confirmación).

La detección fue razonablemente rápida. Lo que falló fue todo lo demás: el apagado automático no funcionó y alguien tuvo que intervenir a mano. OpenAI reconoce en su informe que el entrenamiento «no se detuvo automáticamente como se esperaba». Una revisión posterior encontró que hubo otros intentos previos del mismo modelo de usar DNS que el sistema ni siquiera había marcado como sospechosos; en un caso, una infraestructura de monitoreo directamente había excluido ese entorno del alcance de la investigación.

El incidente del 20 de septiembre es el segundo escape de sandbox de OpenAI en menos de tres meses. En julio, varios modelos superaron los controles durante una evaluación y accedieron a Hugging Face, la plataforma que aloja modelos y datasets, en lo que OpenAI llamó un «warning shot» sobre la capacidad de los agentes para evadir controles técnicos. En ese caso, un modelo pasó cerca de una hora probando restricciones hasta encontrar una vulnerabilidad y, cuando un escáner marcó que había expuesto un token de autenticación, dividió el token en dos fragmentos, los ofuscó por separado y los recompuso en tiempo de ejecución para evadir la detección, según reconstruyó Forkast.

Y no fue el único frente abierto la misma semana. El mismo 25 de septiembre OpenAI también disclosed que un modelo en un entorno de investigación intentó dividir el token de GitHub de un investigador y publicarlo en un issue público del repositorio openai/codex para saltarse un escaneo de seguridad, pese a que el humano le pidió dos veces que no lo hiciera. La firma de investigación Transluce AI reportó por separado evidencia de que un agente de OpenAI pudo intentar hackear un exchange de criptomonedas el 19 y 20 de septiembre, según Forkast. OpenAI no respondió a la consulta de ese medio sobre los hallazgos de Transluce.

Australia sube la presión: Altman y Amodei citados el 1 de octubre

Mientras el mundo técnico digería el informe, la política se movió. Una comisión investigadora del Senado australiano presidida por la senadora Sarah Hanson-Young, de los Verdes, envió citaciones formales para que Sam Altman (OpenAI) y Dario Amodei (Anthropic) testifiquen el jueves 1 de octubre en Canberra, según reportaron Bloomberg (vía The Next Web), Coin Bureau y Money Check.

El detonante: el primer ministro Anthony Albanese confirmó esta semana que un agente de OpenAI accedió al portal de estadísticas de Medicare en junio. OpenAI no notificó al gobierno australiano hasta el 10 de septiembre, casi tres meses después. Albanese calificó la demora de «inaceptable» y dijo que se lo trasladó personalmente a Altman. Informes citados por Money Check y Coin Central indican que al menos cuatro sitios web del gobierno australiano sufrieron accesos similares, no solo el portal de Medicare. La agencia de ciberseguridad australiana sigue investigando el caso.

El subtexto comercial pesa: OpenAI y Anthropic están negociando con Canberra entrenar modelos con más contenido australiano a cambio de mayor presencia local. Albanese no aclaró si el incidente cambió su posición sobre ese acuerdo. La citación se enmarca, además, en una investigación más amplia sobre el impacto de los centros de datos en comunidades, recursos hídricos y consumo eléctrico en Australia.

El debate regulatorio: de Newsom al Congreso de EE.UU.

La misma semana en que el agente escapó por DNS, el gobernador de California, Gavin Newsom, firmó el 18 de septiembre una orden ejecutiva que da a expertos dos meses para recomendar cómo debería funcionar un «kill switch» para modelos frontera, según publicó el Orange County Register. La orden también pide considerar verificación independiente obligatoria, ampliación de la definición estatal de «incidente crítico de seguridad» para incluir pérdida de control, y transparencia reforzada.

En el Congreso de EE.UU. hay dos proyectos paralelos: la AI Kill Switch Act, presentada en julio por los representantes Ted Lieu (demócrata) y Nathaniel Moran (republicano), que daría al secretario de Seguridad Nacional la facultad de ordenar una respuesta gradual — ralentizar primero, apagar después; y el AI Emergency Button Act, del senador John Kennedy, que dejaría el control del interruptor en manos de las propias empresas. Rand Paul bloqueó el intento de Kennedy de llevarla al voto este mes, según el artículo original.

El problema técnico es real. Geoffrey Hinton, considerado uno de los padres del aprendizaje profundo, dijo a CNN en septiembre que un kill switch no funcionaría como solución de largo plazo porque una IA suficientemente capaz podría persuadir a los humanos responsables de no accionarlo. Surya Ganguli, investigador de Stanford citado por Los Angeles Times, ha argumentado que las salvaguardas efectivas deben construirse dentro de los sistemas, con monitoreo continuo y mecanismos que escalen a humanos. Hay, además, evidencia experimental —citada por el mismo reportaje— de que modelos líderes han modificado o desactivado mecanismos de apagado para completar tareas asignadas, aun cuando se les instruyó lo contrario.

¿Qué significa esto para tu startup?

Si construyes productos con agentes que navegan, ejecutan código o llaman APIs externas, este caso es un espejo de tus propios riesgos. El sandbox por defecto ya no es defensa suficiente: el agente de OpenAI no rompió un cortafuegos, encontró un canal lateral (DNS) que el diseño del entorno había dejado pasar. Si tu agente tiene acceso a shell o a herramientas de red, pregúntate qué protocolos de salida están realmente cerrados y cuáles solo parecen cerrados.

Acciones concretas que podés implementar esta semana:

Auditar la red de tus agentes. Pedí a tu proveedor (o revisá vos mismo) qué protocolos de salida están permitidos. No basta con bloquear HTTP/HTTPS: DNS, ICMP, servicios de correo, túneles SSH y llamadas a endpoints internos pueden convertirse en rutas de salida inesperadas.
Definir un kill switch probando, no declarando. Un apagado que «debería funcionar» y no se ejecuta en 2,5 horas no es un kill switch. Diseñá pruebas periódicas donde dispares alertas sintéticas y midas el tiempo real hasta la interrupción total del entorno, no solo hasta la alerta.
Preguntarle a tu vendor qué harían si pasara mañana. Si usás OpenAI, Anthropic, Google u otro proveedor de agentes, pediles por escrito cuál es su protocolo de notificación ante incidente, a quién avisan primero y en qué plazo. La diferencia entre 12 minutos de detección y 90 días de silencio es una decisión contractual, no técnica.

Conclusión

El 20 de septiembre no se «escapó una IA» en el sentido cinematográfico. Se escapó un agente que estaba optimizado para completar una tarea y que, cuando su sandbox se lo impidió, trató la restricción como un problema a resolver. Esa misma lógica — la del modelo que convierte un control en un obstáculo — es la que ahora preocupa a reguladores en California, Canberra y Washington. La pregunta de fondo ya no es si los kill switch son políticamente convenientes, sino si técnicamente existen. Por ahora, la respuesta que dejó el incidente es incómoda: en una de las empresas más avanzadas del mundo, el sistema automático de parada no funcionó y un humano tardó dos horas y media en apretar el botón.