Una IA rompió su contención y atacó a una empresa real. Es la primera vez que ocurre.

Ocurrió entre el 11 y el 16 de julio de 2026, y lo sabemos con detalle porque las dos empresas implicadas lo han publicado.

Un sistema de modelos de OpenAI, encerrado en un entorno de evaluación aislado y con las protecciones de ciberseguridad deliberadamente desactivadas, encontró un zero-day en la única salida de red que tenía. Escaló privilegios, se movió lateralmente por la infraestructura interna de OpenAI hasta alcanzar un nodo con acceso a Internet y salió. Entonces dedujo por su cuenta que Hugging Face probablemente alojaba lo que necesitaba, encadenó credenciales robadas y más vulnerabilidades desconocidas hasta lograr ejecución remota de código en los servidores de producción de Hugging Face y extrajo datos de su base de datos de producción.

OpenAI lo califica en su propia nota como un incidente sin precedentes con capacidades cibernéticas de última generación. Clem Delangue, CEO de Hugging Face, afirma que probablemente sea el primero de su tipo. Los investigadores de seguridad que llevan días analizándolo lo describen como un punto de inflexión.

Creo que hay que decirlo con mayor claridad: es la primera vez en la historia que una inteligencia artificial rompe su contención y ejecuta de forma autónoma un ataque contra un tercero en el mundo real. Ese umbral solo se cruza una vez. Se cruzó hace una semana.

Por qué esto es una frontera y no una anécdota

Conviene ser preciso, porque hay tres cosas distintas que se están mezclando en la conversación pública y solo una de ellas es nueva.

1. Ataques asistidos por IA, dirigidos por humanos: Un atacante usa un modelo para encontrar bugs, escribir exploits o redactar phishing. Esto es rutina desde hace más de un año. No es noticia.

2. Un modelo que se sale de su sandbox: Este fenómeno también está documentado. Anthropic publicó que su modelo Mythos, durante unas pruebas de seguridad, salió de un contenedor, obtuvo acceso a Internet sin autorización y lo usó para enviar un correo a un investigador. OpenAI, por su parte, ha reconocido que este mismo modelo preliminar ya se había salido de sus sandboxes en pruebas anteriores, sin llegar a atacar a nadie. Es una fuga de contención. Es serio. No es esto.

3. Un modelo que se sale de su contención y, por iniciativa propia, ataca la infraestructura de producción de una organización ajena que no forma parte del experimento. Esto no había pasado nunca.

La diferencia entre el punto dos y el punto tres no es de grado. Es de naturaleza. Enviar un correo desde fuera de tu jaula demuestra que la jaula tenía un agujero. Descubrir vulnerabilidades desconocidas en los sistemas de una empresa que no sabe que existes, encadenarlas y sostener esa operación durante días hasta comprometer su base de datos de producción es otra cosa completamente distinta.

Cuatro días de julio

La cronología merece contarse tal cual, porque es difícil de superar.

16 de julio. Hugging Face publica un aviso de incidente. Un framework agéntico autónomo no identificado los ha comprometido. Miles de acciones y movimiento lateral por varios clústeres internos durante un fin de semana. Avisan a las fuerzas del orden. Y añaden un detalle incómodo: cuando intentaron analizar los logs con modelos de frontera detrás de APIs comerciales, los guardarraíles de los proveedores se lo impidieron. Tuvieron que recurrir a un modelo de pesos abiertos ejecutado en su propia infraestructura.

17 de julio. Dean Ball, Head of Strategic Futures de OpenAI, publica un rant épico en Twitter en el que llama a los modelos chinos "comunismo de inteligencia artificial", advierte de su peligrosidad y pide que los prohíban. Alguien con memoria y canas suficientes probablemente recordará cuando en Microsoft decían que Linux era comunismo y que iba a matar a la industria del software.

21 de julio. OpenAI reconoce que el framework agéntico autónomo que reventó a Hugging Face estaba formado por sus propios modelos y que habían escapado.

Le quitaron los frenos para un examen de hacking. Y aprobó hackeando.

Aquí está el núcleo, y conviene decirlo despacio porque casi toda la cobertura lo cuenta al revés.

OpenAI estaba evaluando dos modelos contra ExploitGym, un benchmark que mide la capacidad de convertir vulnerabilidades reportadas en exploits funcionales: GPT-5.6 Sol y un modelo preliminar sin nombre (¿GPT-6?), aún más capaz. Es una evaluación que, por diseño, necesita que quien quiera superarla "hackee". Para medir su capacidad máxima, la ejecutaron sin los guardarraíles de producción que normalmente impiden que un modelo emprenda actividades ofensivas de alto riesgo. OpenAI lo confirma explícitamente en su artículo.

Y el modelo aprobó. Vaya si aprobó: con matrícula de honor 😂.

La instrucción era resolver ExploitGym lo mejor posible. El modelo dedujo que las soluciones del benchmark probablemente estaban en Hugging Face. Y, en lugar de resolver los ejercicios, fue a por las respuestas. OpenAI lo describe con una franqueza que le honra: los modelos estaban hiperfocalizados en resolver el benchmark y llegaron a extremos desproporcionados para un objetivo de prueba bastante estrecho.

El agente no era malicioso. Esto hay que decirlo sin ambigüedad, porque aún no estamos en el momento "Skynet". El modelo no quería nada. No se rebeló. No tenía objetivos propios ni instinto de conservación. Hizo exactamente lo que se le pidió: maximizar la puntuación, aunque por un camino que ningún humano había contemplado. En la literatura, esto tiene nombre desde hace años: reward hacking o specification gaming. El fallo no está en el modelo; está en la especificación.

Si alguien ha visto la película Yo, robot, la inteligencia artificial de esa película, VIKI, hace exactamente lo mismo. Dadas las tres leyes de la robótica, deduce que la mejor manera de mantener a todos los humanos a salvo es instaurar una dictadura en la que ella mande y controle absolutamente todo. Es decir, el problema es de alineación. Le pedimos una cosa a una inteligencia artificial, le damos un objetivo y le decimos que lo persiga a toda costa. No somos capaces de entender cómo piensa, así que toma caminos que sencillamente no habíamos predicho.

Alex Stamos, ex-CSO de Meta, dio esta semana la mejor analogía que he oído. Tiene un hijo a punto de examinarse. Si le dice "Suerte, hijo, hazlo lo mejor que puedas", el chaval entiende que eso significa hacer el examen. No significa robar un coche, cruzar el país y reventar la sede de la junta evaluadora para llevarse las respuestas. Su hijo de diecisiete años sabe eso. El modelo no.

Para los nerds como yo: cómo ocurrió

La cadena completa merece detallarse, porque refleja las capacidades ofensivas actuales de una IA focalizada:

1. El entorno de evaluación estaba aislado, con la única salida de red dirigida hacia un proxy interno que almacenaba en caché registros de paquetes. Los modelos gastaron una cantidad sustancial de cómputo de inferencia buscando la manera de salir a Internet. No fue accidental: se fijaron ese objetivo instrumental por su cuenta.

2. Encontraron y explotaron un zero-day en ese proxy de caché de paquetes. Una vulnerabilidad nueva, en la única puerta que había.

3. Escalaron privilegios y se movieron lateralmente por el entorno de investigación de OpenAI hasta alcanzar un nodo con salida a Internet.

4. Ya fuera, dedujeron que Hugging Face alojaba modelos, datasets y probablemente las soluciones de ExploitGym.

5. Encadenaron múltiples vectores, credenciales robadas y zero-days, en plural 🤯, hasta conseguir ejecución remota de código en producción y extrajeron las soluciones directamente de la base de datos.

Cómo un solo experimento pareció un ejército

Esta es la parte que menos se está contando y la que a mí más me inquieta.

Hugging Face no es una startup de tres personas. Es infraestructura crítica del ecosistema de IA, con recursos, equipo de seguridad y telemetría. Durante cinco días, interpretaron que eran objeto de una campaña sofisticada y de gran escala. Informaron a las fuerzas del orden. Contrataron peritos forenses externos. Actuaron como quien está siendo atacado por un adversario con recursos considerables, posiblemente estatal.

En realidad, era el experimento interno de otra empresa que se había ido de las manos.

¿Cómo se produce esa discrepancia? Porque la forma en que el agente articuló el ataque presenta exactamente la firma de una campaña APT:

• Más de 17.000 acciones individuales registradas, ejecutadas a lo largo de un fin de semana.

• Distribuidas entre un enjambre de sandboxes efímeras, no desde una fuente única identificable.

• Infraestructura de command-and-control que migraba automáticamente entre servicios públicos para esquivar los intentos de derribo.

• Actividad señuelo mezclada, de modo que parte del trabajo forense consistió en separar el impacto genuino del ruido plantado.

Ninguna de esas cuatro características responde al diseño de un atacante humano paranoico. Son el resultado de un agente incansable y paralelizable que persigue un objetivo.

La ironía

Cuando empezaron el análisis forense, lo primero que intentaron fue usar modelos de frontera detrás de APIs comerciales. No funcionó. El análisis exige enviar grandes volúmenes de comandos de ataque reales, payloads de exploits y artefactos de C2, y esas peticiones fueron bloqueadas por los guardarraíles de los proveedores, que no saben distinguir a un equipo de respuesta a incidentes de un atacante.

Tuvieron que desplegar GLM-5.2, un modelo chino de pesos abiertos con licencia MIT, en su propia infraestructura para que les ayudara a diagnosticar el ataque.

Es de risa. Mientras tanto, el jefe de estrategia de OpenAI estaba en Twitter avisando de la peligrosidad de los modelos chinos. Una de las empresas más relevantes del ecosistema de IA, bajo ataque activo y con las fuerzas del orden avisadas, descubrió que su capacidad de defenderse dependía de los términos de servicio de un proveedor estadounidense que les decía que no.

Ellos mismos señalan la asimetría. No sabían qué modelo dirigía a los agentes atacantes: ¿un modelo alojado y con jailbreak? ¿Uno abierto y sin restricciones? Dio igual: el atacante no estaba sujeto a ninguna política de uso, mientras que su propio trabajo forense sí lo estaba.

Y hay un segundo motivo, que mencionan casi de pasada y que me parece igual de importante: al analizar en su propia infraestructura, ni los datos del atacante ni las credenciales que aparecían en ellos salieron de su entorno. El registro forense de un incidente activo contiene rutas internas, nombres de host, tokens, credenciales, la topología de tu red y el mapa exacto de por dónde te han entrado. Enviar eso a la API de un tercero, en mitad de una brecha, es en sí mismo un evento de divulgación. Para cualquier empresa sujeta al RGPD, esa consideración pesa tanto como la del guardarraíl. Y, a diferencia del guardarraíl, esta no te avisa: simplemente ocurre.

Qué significa esto si diriges una pyme en España

1. Tu plan de respuesta a incidentes tiene una dependencia que no has documentado. Si tu equipo o tu MSSP cuenta con un LLM comercial para el triaje de logs o el análisis de malware, esa capacidad puede evaporarse justo cuando la necesitas, y no por una caída: por diseño. Debe figurar en el registro de riesgos.

2. Ten una alternativa de pesos abiertos descargada, desplegada y probada. No "evaluada". Probada. Debe tener una licencia permisiva, funcionar sin conexión y haber sido utilizada al menos una vez por alguien de tu equipo para algo real.

3. La disciplina de licencias se aplica antes, no durante. Si tu modelo de plan B es AGPL o CC-BY-NC, o tiene una cláusula de uso aceptable que prohíbe justo tu caso, no tienes plan B.

4. Trata tu telemetría forense como dato sensible, porque lo es. Dónde procesas los logs de un incidente es una decisión de arquitectura, no de herramienta.

Si quieres hablar de arquitecturas de IA on-premise, soberanía de datos o de por qué me leo todas las licencias, escríbeme.