← Todos los artículos
Noticias del sector30 oct 2026Fuente: Wiz

Informe de Wiz sobre ataques con agentes: correlaciona el comportamiento antes de asignar una etiqueta de IA

Ilustración que correlaciona una secuencia de acciones de herramientas con el alcance de la tarea, las identidades y los resultados observados

Los equipos de seguridad deberían investigar una secuencia desconocida de uso de herramientas antes de decidir que la causó un agente de IA. El informe de Wiz del 29 de octubre ofrece pistas conductuales para esa investigación, pero el control útil es un relato correlacionado de acciones, identidades y resultados. Una secuencia rápida de comandos o un script verboso por sí solos no pueden establecer la identidad del operador ni el grado de automatización.

En The Rise of Agentic Attacks, Wiz describe tres intrusiones que investigó y propone siete huellas recurrentes de actividad con agentes. Su relato plantea una pregunta práctica para los defensores: ¿puede la telemetría existente distinguir un trabajo de automatización autorizado de una secuencia de ataque cambiante que usa las mismas herramientas?

Trata el informe como una fuente de investigación

Wiz describe casos que implican un servicio Flowise expuesto, una puerta de enlace de operaciones Java y un backend de agente de IA al que se accedió mediante una interfaz MCP. Entre las pistas que propone figuran la iteración sostenida, el razonamiento escrito dentro de las herramientas, la adaptación tras los fallos y la exploración amplia de caminos posibles.

Estos son los hallazgos e interpretaciones de Wiz. El informe dice que la solidez de la evidencia y el grado de autonomía varían entre los casos. Su análisis sobre la escala futura de los ataques y la atribución es una valoración, no una tasa de incidentes medida para toda la industria. La cobertura secundaria corrobora la publicación y el alcance del informe; no valida de forma independiente la telemetría de incidentes subyacente.

La recomendación de Maetra es usar estas pistas como hipótesis de investigación y contrastarlas con los propios registros del entorno. Responde al comportamiento dañino demostrado incluso cuando la etiqueta de IA siga siendo incierta.

Reconstruye la secuencia que cambió de dirección

Empieza por la acción pertinente más temprana que tus registros permitan sostener. Conecta la identidad que inició, el proceso, la solicitud de herramienta, el objetivo y el resultado. Luego busca un cambio significativo después de un error o una negativa. ¿El siguiente paso siguió una alternativa aprobada o buscó un recurso o una credencial distintos?

Supón que una tarea autorizada de inventario recibe un error de permisos al enumerar un servicio. Un intento posterior de leer credenciales o inspeccionar sistemas no relacionados merecería revisión por el límite de la tarea, independientemente de si lo seleccionó un modelo. Este es un ejemplo hipotético de detección, no una afirmación sobre una de las víctimas de Wiz.

Conserva suficiente parte del resultado devuelto para explicar la siguiente acción. Una cronología que contenga solo solicitudes puede hacer que reintentos normales parezcan adaptativos, mientras que una cronología que contenga solo alertas puede ocultar la relación entre un fallo inicial y una escalada posterior. Usa referencias de correlación cuando existan y registra las lagunas cuando los sistemas no puedan proporcionarlas.

Compara la actividad sospechosa con la automatización autorizada

La velocidad de máquina es habitual en el software legítimo. Construye la comparación en torno a lo que la carga de trabajo tenía permitido hacer: su definición de trabajo, propietario, ventana de ejecución, alcance de recursos y destinos esperados. Pregunta si una acción concreta encaja en ese contexto antes de tratar el volumen como la señal decisiva.

Para un agente interno de mantenimiento, la línea base pertinente podría incluir un pequeño conjunto aprobado de endpoints y una ruta de recuperación predecible. Para un escáner, puede esperarse una enumeración más amplia. Una regla de detección debería explicar por qué la combinación observada es inusual para esta identidad y esta tarea, en lugar de asumir que todo escaneo amplio es malicioso o impulsado por IA.

Los planes escritos dentro de los scripts pueden ayudar a un investigador a entender la intención, pero su presencia es una evidencia que debe interpretarse. Los comentarios pueden copiarse, ser engañosos o no guardar relación con la ejecución. Conserva el artefacto original, su procedencia y los eventos que muestran qué se ejecutó realmente. Separa las afirmaciones del artefacto de la conclusión del investigador.

Elige una respuesta según el riesgo observado

Define qué evidencia es suficiente para restringir una credencial, aislar una carga de trabajo o escalar a respuesta a incidentes según el proceso vigente de la organización. Una decisión de respuesta puede basarse en acceso no autorizado a secretos o escrituras inesperadas sin exigir certeza sobre el modelo o el marco de agentes que hay detrás.

Evita convertir una conjetura de atribución en un bloqueo automático amplio. Primero correlaciona el recurso, la identidad y la acción, y después aplica la autoridad de respuesta adecuada al riesgo demostrado. Si se permite una respuesta automatizada, el equipo sigue necesitando conocer su objetivo, alcance y efecto esperado. El informe de Wiz no valida la configuración de respuesta de ninguna organización en particular.

La guía de evidencia de auditoría ofrece contexto sobre la conservación de registros de decisiones y de tiempo de ejecución. Limita la recopilación de contenido sensible a lo que requiera la investigación, con controles adecuados de acceso y retención. Un repositorio de evidencias de seguridad no debería convertirse en otra copia no controlada de credenciales o datos privados.

Pon a prueba una solicitud sospechosa de herramienta en contexto

Toma un ejemplo depurado de un ejercicio autorizado y anota la tarea, la acción de herramienta propuesta y el destino esperado. Revisa el comportamiento inseguro por separado de la pregunta sobre quién lo generó. Eso hace que el ejercicio sea útil incluso si la misma acción podría haberla escrito una persona o un script convencional.

Maetra Secure analiza prompts, llamadas a herramientas y salidas en busca de amenazas en tiempo de ejecución. No identifica a un atacante ni sustituye la telemetría de la nube. Usa el sandbox de Secure para examinar una solicitud de herramienta acotada y después conecta el hallazgo con el proceso de evidencia y respuesta que tu equipo de seguridad ya opera.

Fuentes

Seguridad de agentesDetección conductualEvidencia en tiempo de ejecución
Informe de Wiz sobre ataques con agentes: correlaciona el comportamiento antes de asignar una etiqueta de IA | Maetra Insights