El 2 de septiembre, la unidad de inteligencia de amenazas de Palo Alto Networks publicó el análisis forense de una intrusión que sus investigadores atendieron directamente. El resumen cabe en una línea: agentes de IA comprometieron una empresa completa —nube, identidades, pipelines de desarrollo, SaaS y contenedores— en menos de diez horas, empleando más de 50 técnicas del catálogo MITRE ATT&CK. El mismo trabajo, hecho por un equipo humano coordinado, habría tomado alrededor de dos semanas.
Durante la negociación, el propio atacante le dijo a Unit 42 cómo lo había hecho: modelos de frontera más marcos de agentes construidos específicamente para el ataque. No era una persona usando un chatbot como ayuda. Era una flota de agentes con roles repartidos.
La diferencia no es la velocidad. Es la adaptación
Los ataques automatizados existen desde hace décadas: un script escanea, encuentra y explota. Lo que describe este caso es otra cosa. Cada agente interpretaba el resultado de su propia acción y decidía el paso siguiente, algo que hasta ahora requería a una persona mirando la pantalla.
El reparto de tareas es reconocible para cualquiera que haya visto una arquitectura multiagente del lado legítimo: un agente de reconocimiento mapeando los microservicios internos; subagentes revisando repositorios de código en busca de tokens y contraseñas escritas a mano; otro entrando al gestor de secretos y cosechando credenciales administrativas maestras; y un agente de pipeline secuestrando los flujos de CI/CD y extrayendo claves de acceso a la nube. Es el patrón orquestador–trabajadores del que escribí hace un mes en clave de productividad, aplicado en la dirección opuesta.
Vale registrar también lo que no funcionó: el intento de plantar puertas traseras en la configuración de infraestructura como código fue bloqueado por la protección de ramas del repositorio. Un control aburrido, barato y bien configurado detuvo al agente. Volveremos a eso.
La auditoría de 80 páginas
Hay un detalle del caso que se leyó como anécdota y a mí me parece el hallazgo central. Al terminar, el atacante le entregó a la víctima un informe de unas 80 páginas documentando las decenas de debilidades que había explotado. No como servicio ni como cortesía: como argumento de negociación.
Ese documento no existía en el ransomware clásico porque redactarlo costaba horas de trabajo experto. Ahora es un subproducto gratuito: los agentes ya venían registrando todo de forma estructurada mientras avanzaban. Y cambia la conversación de la extorsión. Ya no es «te cifré los archivos». Es «tengo el mapa detallado de por qué fue fácil, y vos no lo tenías».
Cuando el atacante termina la intrusión con mejor documentación de tu arquitectura que la que tenés vos, el problema dejó de ser el incidente.
El caso no es aislado, y los números ya lo mostraban
Es tentador leer esto como una rareza espectacular. Los datos agregados dicen que no. Según el informe Cost of a Data Breach 2026 de IBM, una de cada cuatro brechas maliciosas ya fue habilitada por IA, un 56% más que el año anterior, y esas brechas costaron en promedio 6 millones de dólares frente a los 4,99 millones del promedio global.
El mismo informe trae tres cifras que ordenan bien las prioridades:
- 92% de las organizaciones que sufrieron un incidente vinculado a IA no tenía controles de acceso adecuados sobre esos sistemas. No es un problema de modelos: es de permisos.
- Menos de la mitad protege activamente sus identidades no humanas —tokens de servicio, claves de API, cuentas de integración—, que es exactamente lo que fueron a buscar los agentes en el caso de Unit 42.
- Quienes usan IA y automatización en la defensa ahorraron unos 1,93 millones de dólares por brecha. La asimetría corta para los dos lados.
A esto se suma la otra tendencia de la semana, menos ruidosa pero más estructural: la investigación sobre navegadores con IA presentada este año confirma que la inyección indirecta de instrucciones (prompt injection) no tiene una solución completa. Ni siquiera los modelos de frontera con sus mejores defensas la eliminan. Si tu empresa está por darle a un agente acceso al correo, al ERP o a la banca electrónica, ese es el supuesto con el que hay que diseñar: el agente puede ser convencido por el contenido que lee.
Si tu procedimiento de respuesta ante incidentes supone que entre la intrusión inicial y el cifrado hay días para detectar, escalar, convocar al comité y decidir, ese supuesto ya no es válido. Diez horas es menos que un fin de semana largo, menos que una guardia sin cobertura, menos que el tiempo que tarda un proveedor externo en responder un ticket fuera de horario.
Qué hacer, en orden de retorno
La reacción intuitiva es comprar más herramientas. Creo que es la última prioridad. Lo que frenó al agente en este caso fue un control de higiene básica, y casi todo lo que lo habilitó también lo era. En orden de lo que más rinde:
- Sacá los secretos del código. Los tokens y contraseñas escritos en repositorios fueron la bisagra de la intrusión. Un escaneo de secretos sobre el repositorio y la rotación de lo que aparezca es de las medidas más baratas y de mayor impacto que existen hoy.
- Tratá a las identidades no humanas como tratás a las personas. Inventario, dueño responsable, mínimo privilegio y caducidad. Un token de servicio con permisos amplios y sin vencimiento es la llave maestra que buscan los agentes, y no dispara ninguna alerta de «inicio de sesión sospechoso».
- Protegé el gestor de secretos y el pipeline como si fueran producción. Porque lo son. Revisión por más de una persona, protección de ramas inmutable en los repositorios de infraestructura como código y separación entre quien programa y quien despliega. Es lo único que bloqueó al atacante.
- Ensayá una contención sincronizada, no secuencial. Si al detectar el incidente revocás credenciales, después sesiones OAuth, después claves de nube y después el pipeline, el agente ya se movió. La recomendación explícita de Unit 42 es cortar todo eso a la vez, y eso hay que tenerlo escrito y practicado antes, no improvisado a las tres de la mañana.
- Definí verificación fuera de banda para acciones críticas. Transferencias, cambios de datos bancarios de proveedores, altas de accesos privilegiados. Con deepfakes de voz y video baratos, la confirmación por un segundo canal dejó de ser burocracia y pasó a ser control.
Para una empresa mediana en Paraguay o la región, nada de esto exige un SOC propio ni un presupuesto de banco. Exige orden: saber qué identidades existen, quién las usa y quién puede desactivarlas rápido. Los datos del CERT-PY que revisé al analizar el ciberespionaje estatal ya mostraban que casi la mitad de los incidentes gestionados en el país corresponden al sector privado. La compresión del tiempo de ataque no cambia quién es blanco: cambia cuánto margen tenés cuando te toca.
Para llevar
- Unit 42 documentó el 2 de septiembre una intrusión donde agentes de IA comprometieron nube, identidades, CI/CD y SaaS en menos de diez horas, con más de 50 técnicas ATT&CK.
- La novedad no es la automatización, sino que los agentes interpretaban resultados y adaptaban el paso siguiente sin intervención humana.
- El atacante dejó una auditoría de 80 páginas: documentar el ataque pasó a ser un subproducto gratuito y una herramienta de extorsión.
- Una de cada cuatro brechas maliciosas ya es habilitada por IA (+56% interanual) y cuesta 6 millones de dólares en promedio, según IBM.
- El 92% de las organizaciones con incidentes ligados a IA no tenía controles de acceso adecuados: el problema es de permisos e identidades, no de modelos.
- Lo que bloqueó al agente fue un control básico bien configurado. La prioridad es higiene —secretos, identidades no humanas, pipeline— antes que herramientas nuevas.
La lectura ejecutiva de la semana no es que la IA volvió invencibles a los atacantes. Es más simple y más manejable: la IA eliminó el cuello de botella del tiempo humano del lado ofensivo, y todavía no lo eliminó del lado defensivo. Esa brecha se cierra de dos maneras, y conviene empezar por la barata. Automatizar la detección y la contención cuesta dinero. Ordenar quién tiene acceso a qué cuesta decisión.
Nota: los detalles de la intrusión provienen del informe «An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation» (Palo Alto Networks, 2 de septiembre de 2026); las estadísticas agregadas, del informe Cost of a Data Breach 2026 de IBM, publicado el 29 de julio de 2026. La identidad de la empresa afectada no fue divulgada. Este artículo es un análisis de gestión y no sustituye una evaluación de seguridad sobre tu entorno.