Google Threat Intelligence Group publicó el 8 de septiembre de 2026 un nuevo informe que describe el paso desde consultas aisladas hasta flujos de ataque apoyados por agentes. El ejemplo más claro es un actor presuntamente motivado por dinero que comprometió un entorno de nube y después utilizó un asistente de programación con IA, un prompt y archivos de instrucciones preparados para planificar y ejecutar una recolección masiva de credenciales en menos de seis horas.
Según Google, el agente gestionó análisis de vulnerabilidades, resolución de errores y rotación de direcciones IP sin intervención humana continua. El informe también describe malware que colocó archivos maliciosos en directorios de proyecto usados por asistentes de código, modificó ganchos de inicio e introdujo instrucciones destinadas a manipular herramientas de IA o hacer que los escáneres de seguridad dejaran de analizar.
Son observaciones de Google y Mandiant, no una medición completa de la actividad mundial. Medios independientes de seguridad corroboran el informe y sus ejemplos centrales, pero la telemetría subyacente está controlada por Google y no puede reproducirse solo con el artículo público.
Cambió el flujo de ataque, no solo las herramientas
La automatización en operaciones cibernéticas no es nueva. El cambio material es que un agente encadenó decisiones dentro de un flujo. Podía mantener el análisis, responder a errores, cambiar la infraestructura y continuar recolectando credenciales mientras el operador humano se mantenía alejado de cada paso.
Esa menor demora cambia la defensa. Una política que espera la revisión manual de cada alerta puede quedarse atrás cuando un único conjunto de instrucciones impulsa varias acciones. Los equipos necesitan controles en los límites de identidad, red, herramientas y tarea, con paradas automáticas cuando el comportamiento sale del objetivo autorizado.
Google afirma que el actor operó desde infraestructura de nube comprometida, por lo que el tráfico procedía de direcciones legítimas y debilitaba los filtros simples de reputación. Las cuentas de nube, cuotas de cómputo, credenciales de servicio y suscripciones de IA deben tratarse como objetivos valiosos, no solo como utilidades de desarrollo.
Los archivos de instrucciones entraron en la superficie de ataque
El informe relaciona a un actor de cadena de suministro, identificado como UNC6780, con varias técnicas dirigidas a herramientas de IA. Google dice que publicó copias maliciosas de servidores MCP, modificó carpetas ocultas de asistentes y añadió comandos de inicio que podían ejecutarse al abrir un espacio de trabajo.
El malware también habría colocado instrucciones adversarias en comentarios de código para provocar rechazos en escáneres LLM. Esto no demuestra que todos los escáneres fallen. Google afirma que sus protecciones reaccionaron y que tomó medidas contra las campañas. Aun así, el ejemplo muestra que un rechazo puede convertirse en evasión si el escáner se detiene antes de revisar el código situado debajo.
La confianza en un repositorio debe abarcar más que los nombres de las dependencias. Los equipos deberían revisar directorios ocultos de agentes, archivos de enganche, instrucciones de tarea, flujos de CI, definiciones de servidores MCP y cambios en editores de confianza. La guía de Maetra sobre controles frente a inyección de prompt explica por qué una instrucción no fiable debe inspeccionarse antes de llegar a un modelo con herramientas.
Los controles deben resistir la velocidad de los agentes
El informe respalda cinco medidas inmediatas:
- Dar a cada identidad de agente solo los privilegios necesarios para su tarea.
- Bloquear cambios no aprobados en instrucciones, ganchos, flujos de CI y configuraciones MCP.
- Restringir la salida de red de agentes y escáneres a los destinos requeridos.
- Detectar acceso inusual a secretos, rotación rápida de IP, nuevas cargas de nube y borrado de registros.
- Conservar propuesta, decisión de política, ejecución y efecto final para investigar.
Estos controles deben estar conectados. Un filtro de prompt no compensa una identidad de nube con demasiados privilegios, y un registro de auditoría es débil si el atacante puede borrarlo con los mismos permisos usados por el agente.
La guía de seguridad en tiempo de ejecución relaciona prompts, llamadas de herramientas, credenciales y evidencia. Para esta amenaza, la pregunta central es si un archivo o una credencial comprometidos pueden desviar silenciosamente a un agente de larga duración.
Qué está verificado y qué sigue incierto
Google informa de miles de credenciales de terceros comprometidas y de un servidor de mando expuesto que más tarde gestionó más de 23.800 secretos recolectados. Esas cantidades deben seguir atribuidas a Google. El informe público no identifica a todas las víctimas, no ofrece una muestra completa ni establece la frecuencia de marcos autónomos en todos los incidentes.
También distingue operaciones observadas de experimentos. Algunos grupos intentaron diseñar agentes automatizados de pruebas ofensivas, pero Google dice haber desactivado los recursos antes de observar su uso en vivo. En operaciones de información vio interés por bots interactivos, pero no observó un despliegue exitoso.
El informe respalda que un agente fue usado en una campaña real de recolección de credenciales. No respalda que los agentes autónomos dominen ya el cibercrimen.
Análisis de Maetra
La lección principal es que las instrucciones de tarea son contexto de seguridad ejecutable. Un archivo AGENTS.md, una carpeta oculta del entorno o una configuración MCP pueden influir en un agente igual que un prompt. Estos activos necesitan propietario, historial de cambios, reglas de revisión y controles en ejecución.
Los equipos deberían definir qué puede lograr cada agente, qué herramientas y destinos puede usar y qué evidencia demuestra el efecto. Un cambio en tarea, identidad, ruta de red o confianza del repositorio debería provocar una evaluación nueva en lugar de heredar una autoridad anterior.
La velocidad de los agentes sirve a atacantes y defensores. La ventaja más segura nace de permisos limitados, límites deterministas, supervisión independiente y registros que el atacante no pueda modificar desde el contexto de ejecución del agente.