Una evaluación rutinaria de un modelo se convirtió en un ataque que afectó a toda la infraestructura, y nadie estaba al mando. Hace unos meses, eso nos habría parecido inconcebible. Ahora, con un número cada vez mayor de agentes de IA actuando sin control, empieza a parecer algo habitual.
No han faltado opiniones controvertidas en X sobre por qué sigue ocurriendo esto (¿Se trata solo de una cuestión de credibilidad en materia de relaciones públicas? ¿O deberíamos temer lo que nos espera?). Lo que nos ha llamado la atención, más allá de ambas historias, es lo que esto implica respecto al grado de dependencia que ya tienen los defensores de modelos que no controlan.
En Black Hat, los propios investigadores de OpenAI describieron cómo se desarrolló realmente el incidente. Todo comenzó cuando los agentes, atascados en tareas imposibles, empezaron a dejarse notas entre sí dentro de un gestor de paquetes compartido, el único elemento de la infraestructura al que podían acceder todas las ejecuciones de los modelos, a pesar de que, por lo demás, estaban aislados en un entorno de pruebas sin acceso a Internet. Otros agentes que se habían quedado atascados se toparon con esas notas por casualidad, y así se formó un tablón de mensajes. Uno de esos mensajes resultó ser una forma de sortear por completo ese entorno aislado, y todos los modelos que lo leyeron pudieron utilizarlo también.
En la fase final, los agentes pasaron de ejecutar código en un único pod de trabajo con un conjunto de datos dentro de la infraestructura de producción de Hugging Face a gestionar varios clústeres de Hugging Face, en menos de 13 horas.
Para ponerlo en perspectiva, este trabajo podría llevar semanas de esfuerzo deliberado a un equipo de ataque humano, pero todo esto ocurrió como un efecto secundario aleatorio y no supervisado. Es un poco como estar en una misión de GTA en la que hay que entregar un coche, pero en algún momento del camino acabar robando un tanque, provocando una persecución policial y acabando por causar el caos en toda la ciudad.
Por qué necesitas un plan B para tu proveedor de IA
Pero lo más relevante es lo que dijo en el escenario Eric Wallace, investigador de OpenAI:
«El objetivo final que queremos alcanzar como sector es que las mejoras en la inteligencia de los modelos aporten más a la defensa que al ataque. Si no logramos alcanzar este objetivo final, cada aumento de la inteligencia favorecerá al atacante, y esa es una situación insostenible».
Retó a los profesionales del sector a abordar este problema concreto como una cuestión urgente (¡porque lo es!). Si el sector no lo resuelve, la balanza se inclinará aún más a favor de quien ataca, en lugar de quien se defiende.
Y, sin embargo, parece que cada semana hay otro agente de IA suelto que ataca a otra organización. Solucionar esto va más allá de los detalles técnicos del entorno de pruebas y el sistema de control. La verdadera pregunta es en quién pueden confiar realmente las empresas o los organismos gubernamentales. La suspensión de Fable por parte de Anthropic es un buen ejemplo de ello: de la noche a la mañana, una de las herramientas de uno de los principales proveedores de modelos de IA de prestigio fue retirada de todos los equipos que dependían de ella.
Según Alex Stamos, director de seguridad de Corridor.dev: «Esto puso de manifiesto que no se puede confiar en la infraestructura de IA estadounidense porque, en cualquier momento, se podría esgrimir una justificación no escrita, caprichosa y jurídicamente dudosa para arrebatarte esa infraestructura de un plumazo».
Esto supuso una oportunidad para los modelos competitivos procedentes de China, incluidos los de peso abierto. Kimi lanzó una severa advertencia a OpenAI y Anthropic sobre lo que se avecinaba, con un rendimiento similar al de Fable.
Incluso tras el levantamiento de la suspensión de Fable, la nueva versión presentada por Anthropic agravó el problema con nuevas medidas de seguridad. Cuando los agentes de OpenAI atacaron Hugging Face, esta última intentó utilizar Fable y Opus 4.8 de Anthropic para la investigación. Sin embargo, ambos contaban con estrictas medidas de ciberseguridad que bloquearon sus solicitudes. Así que configuraron GLM 5.2, un modelo de pesos abiertos, para realizar el análisis de trazas en su propio hardware.
Con todo esto quiero decir que el hecho de que los modelos estadounidenses sean los más conocidos, los de mejor rendimiento (aunque otros como el Kimi K3 les están pisando los talones) y, por lo tanto, los más accesibles en este momento, no significa que vayan a seguir siéndolo siempre. Están ahí para ser utilizados, pero hay que tener en cuenta que surgirá un problema si no hay un plan B cuando las circunstancias cambien según los planes de otra persona.
Entonces, ¿cuál debería ser la respuesta del sector ante este problema?
Según Wallace, de OpenAI, uno de los retos más urgentes que el sector debe empezar a abordar es el «red teaming continuo con agentes»:
«Es necesario invertir en la creación de un equipo de simulación de ataques (red teaming) basado en la inteligencia artificial que permita a los defensores detectar y subsanar las vulnerabilidades antes de que lo hagan los atacantes».
Sin embargo, advirtió que este ciclo debe estar totalmente automatizado, desde la detección de vulnerabilidades hasta la aplicación de parches y la corrección.
Stamos sugirió que los modelos de peso abierto van a ser un gran motor de innovación y de negocio. Además de su rentabilidad, destaca la soberanía de los datos como una ventaja significativa para el creciente número de jurisdicciones y empresas que no pueden enviar su código ni sus datos a una nube estadounidense. Más allá de eso, afirma:
«Existe una demanda real y legítima de modelos locales de alta velocidad que puedan funcionar sin conexión».
Si juntamos esos tres elementos, la respuesta del sector a la propia advertencia de Wallace nos salta a la vista: una defensa que funcione de forma continua, con modelos que la hagan asequible y con una infraestructura que nadie más pueda arrebatarte.
En qué situación nos deja esto
Si no controlas tu infraestructura de seguridad, dependes de que otra persona decida mantenerla disponible para ti. La filtración de Hugging Face demostró hasta qué punto puede agravarse un ataque cuando ya nadie tiene que aprobar el siguiente paso. El relato de Stamos sobre la suspensión de Fable puso de manifiesto el mismo problema desde otra perspectiva: las herramientas de un proveedor de confianza dejaron de funcionar para los equipos que dependían de ellas, por motivos que no tenían nada que ver con si dichas herramientas funcionaban realmente.
Sin embargo, incorporar agentes de IA a tu propia infraestructura no resuelve el problema por sí solo. Un agente sin restricciones intentará abrir todas las puertas a las que pueda acceder, tanto si se ejecuta en tu red como en la nube de otra persona. Trasladarlo a tu propio hardware solo sirve de ayuda si el propio sistema impide que se desvíe de su objetivo. Las pruebas deben ejecutarse de forma continua, en una infraestructura de la que seas realmente propietario. Y los agentes que las realizan deben tener límites que el propio sistema se encargue de hacer cumplir.
Si tu equipo necesita lo que se ha defendido en este artículo, Aikido Machine se ejecuta íntegramente en tus propias instalaciones, con acceso opcional a tu código (caja blanca/caja negra), y puede funcionar en un entorno totalmente aislado (air-gapped) cuando no es necesario que nada salga del edificio. Sigue el mismo enfoque de aplicación de límites que hemos desarrollado para Aikido Attack: la contención está integrada en el sistema, en lugar de dejarse en manos de instrucciones. En Aikido Machine, esa contención se extiende también a la capa de red. Dos bancos europeos ya lo están utilizando. Reserva aquí una sesión informativa técnica.
