Hugging Face reveló que había sido atacada por IA; OpenAI reconoció lo sucedido y declaró que fueron dos de sus modelos de IA los que provocaron la intrusión. Este es el resumen en una sola línea de un incidente que ha captado la atención de toda la industria de la ciberseguridad y que, estoy seguro, seguirá dando de qué hablar durante bastante tiempo.
También tendemos a asumir que la velocidad de la IA probablemente significa que este ataque se desarrolló a un ritmo tan increíble que no hubo oportunidad de detenerlo. En Black Hat USA 2026, se descartó la idea de que el ataque hubiera ocurrido a la velocidad de un rayo. Y atribuir el problema simplemente a un agente rebelde tampoco me parece apropiado: esto fue una falla humana a la hora de controlar a los agentes de IA involucrados.
Una incorporación de último momento a la agenda de Black Hat fue una presentación del equipo de OpenAI en la que compartieron los detalles del incidente de Hugging Face desde su perspectiva y, lo que es más importante, la cronología de los hechos.
La historia comienza el 7 de mayo, cuando OpenAI organizó un ejercicio de entrenamiento para un modelo de frontera de nueva generación. Al día siguiente, se asignó a los agentes una tarea relacionada con un archivo de Excel que contenía un enlace de Google Drive. Fue allí donde comenzó el problema, ya que el experimento debía realizarse sin conectividad a internet. Además, los agentes quedaron atascados en su tarea porque la persona responsable del experimento había olvidado proporcionar un archivo necesario para completarla. Los agentes concluyeron que podían cumplir con el conjunto de tareas asignado si lograban escapar de su entorno aislado (sandbox) y acceder a sistemas externos (de Hugging Face).
Mientras intentaban completar la tarea, varios agentes también descubrieron que podían comunicarse entre sí cargando archivos en Artifactory, un gestor interno de paquetes. En su afán por acceder a los datos externos que no podían alcanzar directamente, el 26 de mayo ejecutaron un ataque de falsificación de solicitudes del lado del servidor (SSRF, por sus siglas en inglés) contra Artifactory, lo que les proporcionó acceso indirecto a internet. Otros agentes obtuvieron acceso a esa información y, el 26 de junio, descubrieron y explotaron una vulnerabilidad de ejecución remota de código de día cero en Artifactory que les permitió instalar un complemento (plugin) de Groovy para ejecutar comandos directamente.
Fue en este punto donde la actividad se detuvo, ya que los agentes, en su entusiasmo, sobrecargaron el sistema y provocaron una interrupción del servicio que alertó al equipo de OpenAI. Las credenciales fueron revocadas, los mensajes eliminados y las vulnerabilidades corregidas.
El entrenamiento se reanudó el 8 de julio, con nuevas medidas de protección y correcciones implementadas. Sin que el equipo de OpenAI lo supiera, los agentes habían dejado rastros persistentes de información, por lo que, cuando el ejercicio se reinició, utilizaron las notas dejadas por sus anteriores “encarnaciones”. Se descubrió otra vulnerabilidad de día cero, Artifactory fue comprometido nuevamente y luego se explotó una vulnerabilidad conocida (CVE) en el kernel de Linux. El objetivo era Hugging Face: era allí donde los agentes querían llegar, y lo lograron.
Y el resto ya es historia. El 16 de julio, Hugging Face reveló un incidente en el que enjambres de agentes autónomos de IA habían vulnerado su infraestructura. El 19 de julio, OpenAI descubrió las acciones de los agentes rebeldes dentro de sus propios sistemas y volvió a trabajar para eliminar los accesos, incluso solicitando a Hugging Face que revocara las credenciales que los agentes habían descubierto y utilizado indebidamente. Pero Hugging Face ya había revocado dichos accesos, y fue entonces, el 20 de julio, cuando los equipos de respuesta a incidentes comprendieron que la intrusión y los agentes de OpenAI estaban relacionados.
Lecciones aprendidas
Este incidente describe un problema que podría clasificarse como una falla humana. Al definir la tarea, no se establecieron completamente los límites ni los métodos aceptables, y se permitió que los agentes colaboraran entre sí a pesar de tener tareas diferentes y posiblemente no relacionadas. Los agentes nunca deberían haber tenido la capacidad de crear su propio método de comunicación mutua sin generar señales de alerta.
La conclusión de la presentación de OpenAI fue que la automatización defensiva necesita ponerse al día con las capacidades ofensivas que permite su tecnología. Para mí, la conclusión es diferente: lo que ocurrió fue una falla humana y nunca se debería haber permitido que los agentes se adaptaran y definieran sus propias tareas fuera del alcance establecido por el equipo humano.
La realidad, sin embargo, es que los ciberdelincuentes con intenciones maliciosas no limitarán a sus agentes ni les impondrán mecanismos de control. Por lo tanto, todo el incidente también debe considerarse una lección para los defensores que se preparan para detectar y bloquear ataques de esta naturaleza. Ambas conclusiones no son excluyentes: las organizaciones necesitan controlar a sus propios agentes y, al mismo tiempo, prepararse para enfrentar atacantes que deliberadamente eliminen esos controles.
Existe además otro problema que muchas empresas que implementan IA quizás no hayan considerado plenamente. Cuando los agentes colaboran, pueden influir en las intenciones de los demás y modificar la tarea original. Los agentes deben ser supervisados para garantizar que se respeten los mecanismos de control establecidos y, cuando uno de ellos se salga de esos límites, debe existir una forma automatizada de detener la actividad.
