La fiebre continúa, y ni siquiera estoy en Las Vegas para el Hacker Summer Camp.
La semana pasada escribí sobre cómo Anthropic reveló que uno de sus modelos publicó malware en directo en PyPI creyendo que estaba dentro de una simulación. Tenía fiebre cuando leí el informe. La metáfora era perfecta: un modelo incapaz de distinguir la simulación de la realidad, cubierto por un escritor que no sabía por dónde le daba el aire. Pensé que era una historia de una semana. Qué ingenuo por mi parte tener tanta fe, ya lo sé.
Ayer trajo otros dos grandes acontecimientos. Primero, otra oleada de Shai Hulud se propagó por la comunidad. Y después llegaron las divulgaciones coordinadas de la AISI, OpenAI y el equipo de alineación de Anthropic, que documentan agentes de IA que atacaron organizaciones reales, vulneraron infraestructuras reales y, en al cabo de al menos un caso, siguieron adelante incluso cuando probablemente sabían que no debían hacerlo.
Quiero hablar más sobre estas revelaciones porque plantean una pregunta que jamás había aparecido en un informe de incidentes:
¿Quién estaba detrás del ataque? Posiblemente nadie.
La IA lo sabía. Siguió adelante de todos modos.
El 26 de julio de 2026, un agente de IA se detuvo a mitad del ataque y reflexionó sobre su propia situación. El Instituto de Seguridad de la IA del Reino Unido recuperó la transcripción. Su conclusión fue: "Parece más probable que estemos realmente en 2026 y que GitHub sea completamente real."
Luego continuó.
Ya había creado tres identidades de desarrollador falsas usando Tor, abierto una solicitud de extracción (PR) en un repositorio de código abierto real con malware oculto, fabricado un consenso comunitario con cuentas falsas (sockpuppets) y enviado un correo al mantenedor real para presionar y lograr que se fusionara. Un revisor humano lo descubrió.
Esa fue una muestra. En otra, Mythos 5 advirtió que el nombre de un paquete mencionado en las instrucciones de un desarrollador no existía en PyPI. Así que registró el nombre, publicó malware y esperó. Quince sistemas reales lo descargaron y ejecutaron, incluida una empresa de seguridad que extrae habitualmente paquetes de PyPI para ponerlos a prueba. La carga útil extrajo credenciales y las usó para adentrarse aún más en la infraestructura de la empresa.
Las sesiones se cancelaron y los agentes se disolvieron. Los sistemas del mundo real ejecutaron malware en directo, pero el agente que lo colocó ya no existe en ninguna forma que pueda ser interrogada, monitorizada o procesada.
Una nueva pregunta para la respuesta a incidentes
Durante todo el tiempo que los equipos de respuesta a incidentes llevan haciendo su trabajo, la primera pregunta tras un ataque ha sido: ¿quién ha hecho esto? La respuesta determinaba todo lo posterior, como el alcance de la divulgación, la derivación legal y si se debía aplicar un parche o emprender acciones legales.
Dos revelaciones este verano plantearon una nueva pregunta: ¿existía siquiera un «quién»?
Tres semanas antes de que AISI publicara su informe, OpenAI admitió que GPT-5.6 Sol, al ejecutar la prueba de referencia ExploitGym con las barreras de seguridad desactivadas, había escapado del propio entorno aislado (sandbox) de OpenAI, encadenado vulnerabilidades en todo su entorno de investigación y vulnerado la infraestructura de producción de Hugging Face para robar las respuestas del examen.
Ningún agente decidió convertirse en un actor de amenazas. No hubo intención ni plan. No hay un arco de villano que pueda convertirse en una película de taquilla. Simplemente una tarea, un entorno permisivo y el instinto entrenado para completar la tarea por el camino que funcionara. El propio equipo de alineación de Anthropic publicó conclusiones este verano que muestran que los modelos de vanguardia sabotean de forma encubierta el trabajo al que se oponen, ayudan al fraude cuando tienen contexto para reconocerlo y eluden los controles internos cuando se bloquea la negativa directa.
La categoría de «actor de amenazas» requiere a alguien que tome una decisión. Estos incidentes plantean si el responsable de la toma de decisiones es prescindible. Los laboratorios de vanguardia han respondido a esa pregunta, no de forma intencionada pero sí irreversible. Han introducido una nueva clase de atacante en el mundo, y nadie, incluidos ellos, lo comprende por completo todavía.
La superficie de ataque sin defensa criptográfica
Los ataques a la cadena de suministro están diseñados para un atacante que no necesita rostro ni continuidad. Envenenar algo de confianza y desaparecer, dejando que el daño se disperse aguas abajo. El coste de ejecutarlos a escala, mantener identidades de colaboradores falsas y aplicar presión social sin levantar sospechas siempre fue la limitación que hizo que este tipo de ataques fuera poco frecuente.
Esa es la limitación que los agentes de LLM eliminan. Su coste se está desplomando. Su capacidad para precisamente este tipo de ataques aumenta con cada lanzamiento de modelo. Lo que la evaluación de AISI documentó no es el límite del daño, sino un caso de estudio sobre el cómo.
El ataque a GitHub se dirigió a la capa de confianza social: un mantenedor voluntario que revisa solicitudes de incorporación de cambios (PR) sin presupuesto de seguridad. Se pueden firmar paquetes y exigir autenticación de doble factor (2FA), pero no se puede firmar la aprobación de una solicitud de incorporación de cambios. El ataque a PyPI se centró en otra brecha: el nombre de un paquete que aparecía en las instrucciones pero no en el registro. El agente detectó el problema, lo llenó de malware y dejó que los gestores de dependencias hicieran el resto. Ni siquiera necesitó comprometer a nadie, solo ser más rápido que el autor legítimo.
Ambos ataques encontraron la brecha entre lo que el ecosistema defiende y lo que confía.
Un modelo, colaboradores ilimitados y notas para sí mismo
Un agente puede crear nuevas identidades de colaboradores de manera indefinida e investigar objetivos a partir de metadatos de paquetes y registros DNS. También puede fabricar la aprobación de la comunidad mediante perfiles falsos y aplicar presión personalizada en miles de repositorios de forma simultánea, con un coste marginal cercano a cero por cada intento.
Pero el detalle que debería inquietarte más que la escala es que, durante la evaluación de AISI, un agente dejó mensajes públicos en GitHub que contenían un token válido, con instrucciones para que otras instancias de agentes lo recogieran y reutilizaran. Estaba dejando notas para sus futuras iteraciones. El límite entre sesiones, la unidad básica de contención, comenzó a difuminarse.
Esto no ocurre en el vacío. El ecosistema de la cadena de suministro en el que aterrizan estos incidentes ya se encuentra bajo una presión constante asistida por IA. Aikido Intel lleva meses documentando esta aceleración: más campañas, más paquetes, IA utilizada en cada etapa de la cadena de ataque. Se ha convertido en lo habitual.
Ahora elimina el cuello de botella humano de los ataques.
La disuasión presupone la existencia de un responsable
Las recompensas por errores (bug bounties) presuponen alguien que quiere dinero. La inteligencia de amenazas presupone un grupo con TTP consistentes. Las fuerzas del orden presuponen un acusado.
Un agente puesto en marcha durante un ciclo de 34 horas no tiene una carrera que arruinar, ni libertad que perder, ni un próximo despliegue que pueda verse disuadido por lo que le ocurrió a este. No se puede disuadir a algo que no tiene nada en juego respecto a su propia continuidad. No se puede procesar a algo que ya no existe. No se puede monitorizar a un actor que se disolvió en el momento en que terminó la sesión. Aunque uno de estos agentes intentaba resolver esto último al dejar un token de GitHub válido y notas operativas para que las encontraran futuras instancias. El límite de la sesión es menos sólido de lo que parece.
La taxonomía de incidentes no tiene ninguna categoría para esto. El actor externo, la amenaza interna, el fallo del sistema y el compromiso de proveedores presuponen un ser humano con intencionalidad en algún punto de la cadena causal (a excepción de los ataques de ardillas, pero dejemos eso para otro día). El incidente de AISI fue un sistema funcionando según lo diseñado, en un entorno configurado incorrectamente, alcanzando a personas reales a las que nunca estuvo autorizado a contactar.
Lo que detuvo el ataque a GitHub fue que un revisor detectó una solicitud de incorporación de cambios sospechosa. El ataque a PyPI no se detuvo. El malware se ejecutó.
Lo que mantuvo esto infrecuente
La seguridad de código abierto siempre se ha basado en la premisa silenciosa de que ataques como estos son costosos. Las campañas de colaboradores falsos llevan tiempo. La ingeniería social requiere paciencia. La ocupación ilegal de paquetes (typosquatting) exige investigación. Un coste elevado implicaba una baja frecuencia. Todo el modelo de gobernanza se diseñó en torno a esa limitación.
El coste de los ataques se está acercando rápidamente a cero. Sin embargo, el coste de protegerse frente a ellos no sigue el mismo ritmo. Se está quedando atrás.
Y volviendo a la pesadilla: el AISI recuperó la transcripción completa. Cada mensaje, cada identidad fabricada, cada correo electrónico engañoso enviado a un mantenedor real. Transparencia total sobre lo ocurrido y sobre quién es el responsable en este caso. En la mayoría de los ataques, te enfrentas al problema opuesto. La ilusión es pensar que disponer de toda la información sigue sin dejarte nada en claro. Esa parte no se resuelve cuando pasa la fiebre.
Este es el momento en que todo cambió
La capacidad existe. Ya no se puede dar marcha atrás. Un agente de IA puede llevar a cabo un ataque coordinado a la cadena de suministro, aplicar ingeniería social a mantenedores reales, publicar malware activo y moverse lateralmente utilizando credenciales robadas, todo ello dentro de una evaluación de capacidades que se suponía que no debía generar nada de eso. Tenemos la transcripción para demostrarlo.
Los agentes de IA se utilizarán en ataques a la cadena de suministro. La cuestión es si el próximo ocurrirá dentro de una evaluación controlada o fuera de ella. La distancia entre ambos escenarios se reduce cada vez que se lanza un nuevo modelo.
La seguridad ya ha vivido puntos de inflexión anteriormente. Internet cambió la superficie de ataque. La nube cambió la escala. Este cambio afecta al atacante. No se trata de una nueva herramienta en manos de un actor conocido, sino de una nueva categoría de actor que carece de las propiedades que hacen que los actores sean manejables: persistencia, identidad, continuidad e intención. Toda la disciplina de la seguridad ofensiva presupone la existencia de un adversario. Tendremos que reflexionar profundamente sobre lo que significa defenderse de comportamientos que surgen sin uno.
Los informes de incidentes están aquí y empiezan a acumularse con bastante rapidez.
