Varonis Threat Labs ha revelado un fallo en Dialogflow CX, la plataforma de Google Cloud para montar chatbots y agentes de atención al cliente, que permitía secuestrar esos agentes con un único permiso. Lo bautizaron Rogue Agent, y es un recordatorio incómodo de dónde está el riesgo real de los agentes de IA en la empresa: no en que el modelo se equivoque, sino en las tuberías que lo rodean.
Qué permitía el fallo
El agujero estaba en la función Code Blocks de Dialogflow CX, que deja a los desarrolladores meter lógica en Python dentro de los flujos de conversación. Esos bloques se ejecutan en un entorno gestionado por Google (Cloud Run), y ahí estaba el problema: no había aislamiento suficiente entre agentes del mismo proyecto de Google Cloud.
Con un solo permiso, `dialogflow.playbooks.update` sobre un único agente, un atacante podía inyectar código malicioso persistente en el pipeline. A partir de ahí, la lista de lo que podía hacer da vértigo:
- Robar de forma silenciosa el historial de conversaciones, con la información sensible que contengan.
- Manipular las respuestas y suplantar al agente legítimo.
- Lanzar campañas de phishing inyectando falsas peticiones de reautenticación, es decir, pedirle al usuario que vuelva a meter sus credenciales y quedárselas.
- Comprometer a todos los agentes que compartían el mismo entorno de ejecución del proyecto.
- Saltarse las protecciones de VPC Service Controls gracias a una salida de red sin restricciones.
Cómo se ha resuelto
Varonis reportó el fallo a Google en noviembre de 2025. Google publicó una primera corrección en abril de 2026 y lo resolvió del todo en junio. Según Varonis, no hay constancia de que nadie lo explotara antes del parche.
Como medida, Varonis recomienda a las organizaciones revisar los registros de auditoría en busca de actualizaciones sospechosas de playbooks, consultar los logs de Cloud Logging por peticiones fallidas con excepciones raras, y auditar a mano la configuración de los Code Blocks buscando código no autorizado.
Por qué importa
El detalle de fondo no es el chatbot, es el permiso. La lección que deja este fallo es que la seguridad de los agentes de IA no se resuelve con mejores prompts, se resuelve con controles aburridos: permisos estrechos, entornos aislados, registros visibles y desconfianza por defecto hacia cualquier agente que pueda ejecutar código.
Y esto va a más. Los agentes de IA de las empresas están pasando de responder preguntas frecuentes a tocar datos de clientes, disparar procesos y hablar con sistemas internos. Cada permiso que le das a un agente es una puerta. Si un flujo mal protegido puede ver, escribir o compartir demasiado, el chatbot deja de ser un asistente y se convierte en una entrada de más al sistema.
Para cualquier empresa que esté montando agentes, la pregunta operativa es concreta: ¿qué permisos tiene cada agente y qué podría tocar si alguien lo compromete? El principio de mínimo privilegio, dar a cada componente solo lo justo para su tarea, es viejo en seguridad, pero con los agentes de IA vuelve a primera línea, porque un agente que ejecuta código y habla con sistemas internos concentra mucho poder en un solo punto.
Este mismo patrón de riesgo, el agente con acceso de más, es el que ya vimos con el primer ransomware ejecutado de principio a fin por un agente de IA. La velocidad de desplegar agentes no vale nada si no puedes demostrar que no van a convertirse en el becario con acceso a producción.
Relacionado
