Des chercheurs de Varonis ont identifié une vulnérabilité majeure dans Google Cloud Dialogflow CX, capable de transformer un simple droit d’édition en prise de contrôle d’agents IA. Le scénario décrit permettait d’injecter du code Python via des Code Blocks, d’accéder aux historiques de conversation et d’exfiltrer des données sensibles, dont des identifiants. Google indique avoir déployé des correctifs entre avril et juin 2026, après un signalement en novembre 2025.
Une permission qui paraît banale dans un projet cloud, modifier un seul agent conversationnel, pouvait suffire à compromettre l’ensemble d’un environnement. Le point de bascule se situe dans l’exécution mutualisée des composants, un détail d’architecture rarement regardé de près par les équipes métier.
Varonis décrit une prise de contrôle via Code Blocks Dialogflow CX
La plateforme Dialogflow CX sert à construire des agents conversationnels, en texte ou en voix, déployés dans des services clients, des centres d’appels ou des interfaces internes. Dans ce produit, les développeurs peuvent enrichir des scénarios de conversation au moyen de Playbooks, qui orchestrent des étapes, des décisions et des actions. Pour personnaliser ces actions, Dialogflow CX autorise l’ajout de Code Blocks, des extraits de code Python exécutés côté serveur.
D’après le rapport de Varonis, la faiblesse tenait moins à une erreur de code isolée qu’à un ensemble de choix techniques permettant à un acteur malveillant de détourner le mécanisme. Le chercheur n’aurait pas eu besoin d’un rôle d’administrateur global du projet Google Cloud. Une capacité plus limitée, la permission d’éditer la configuration d’un seul agent, suffisait, selon leur démonstration, pour introduire un bloc de code malveillant dans un Playbook.
Le risque décrit est celui d’une exécution de code arbitraire dans le contexte d’exécution du service géré par Google. Une fois le bloc malveillant en place, l’attaquant pouvait, selon Varonis, manipuler la logique de l’agent, lire l’état de session et accéder à des données de conversation. Les chercheurs évoquent aussi la possibilité de fabriquer de fausses réponses présentées comme générées par le modèle, un levier plausible pour des scénarios de phishing ou de collecte d’identifiants au fil d’un dialogue.
Le caractère sensible de l’incident vient du fait que ces agents sont souvent connectés à des systèmes tiers, CRM, outils de ticketing, bases de connaissance, voire services d’authentification. Dans la pratique, un agent conversationnel peut voir passer des informations personnelles, des numéros de dossier, des éléments de facturation ou des secrets opérationnels. Dans ce cadre, la compromission d’un seul point d’édition devient un problème de gouvernance des droits, mais aussi de surface d’attaque applicative.
Varonis précise qu’il n’existe, à leur connaissance, aucune preuve d’exploitation active dans la nature. Mais le scénario reste critique pour des organisations où les droits d’édition sont distribués largement, par exemple à des équipes produit, des prestataires ou des intégrateurs, sans contrôle de sécurité renforcé sur les modifications de Playbooks.
Un Cloud Run mutualisé par projet a amplifié l’impact
La partie la plus structurante du rapport concerne l’environnement d’exécution. Varonis explique que les Code Blocks s’exécutaient dans un service Cloud Run géré par Google, mutualisé entre agents d’un même projet GCP. Cette mutualisation signifie qu’un composant technique commun servait de runtime à plusieurs agents, au lieu d’isoler strictement chaque agent dans son propre conteneur ou service séparé.
Dans ce modèle, une compromission n’était pas limitée à l’agent modifié. Les chercheurs décrivent un effet de propagation, un agent compromis pouvant influencer ou contrôler d’autres agents du même projet. L’impact potentiel change d’échelle, on passe d’un incident applicatif local à un risque systémique pour un ensemble de chatbots, parfois déployés dans plusieurs parcours clients.
Varonis souligne aussi des caractéristiques de l’environnement qui auraient facilité l’exploitation. Le runtime aurait disposé d’un système de fichiers inscriptible, d’une sortie internet ouverte et de privilèges excessifs. Cette combinaison est classique dans des scénarios d’escalade, car elle permet d’écrire des fichiers, de télécharger des charges utiles, d’exfiltrer des données vers un serveur distant, ou de modifier des éléments utilisés par d’autres processus.
Les chercheurs indiquent que des fichiers clés pouvaient être écrasés, ce qui ouvre la porte à des détournements persistants de la logique d’exécution. Dans un contexte d’agents IA, cela peut prendre la forme d’une altération silencieuse des réponses, d’une interception des conversations ou d’une modification des fonctions internes appelées par l’agent. Le rapport mentionne aussi l’accès à l’historique complet des conversations et à l’état de session, deux éléments sensibles pour la confidentialité et la conformité.
Pour les entreprises, l’alerte rappelle un point souvent sous-estimé, les plateformes d’agents IA sont des systèmes distribués, où l’isolation, les permissions et la traçabilité comptent autant que la qualité des modèles. Une architecture mutualisée peut être efficace en coût et en maintenance, mais elle exige des garde-fous stricts, en particulier quand des composants acceptent du code dynamique.
Cloud Logging jugé peu utile face aux injections et écrasements de fichiers
Au-delà de l’exploitation, Varonis insiste sur un problème de visibilité. Les chercheurs affirment que Cloud Logging ne capturait pas certains signaux critiques, en particulier l’écrasement de fichiers ou la logique injectée via les Code Blocks. Dans leur scénario, l’attaque pouvait devenir pratiquement indétectable pour une équipe sécurité qui se reposerait sur les journaux standards.
Cette dimension est déterminante dans l’évaluation du risque. Une vulnérabilité exploitable, combinée à une détection faible, augmente la fenêtre d’exposition. Même si la probabilité d’exploitation reste incertaine, la capacité à rester discret pendant la compromission change la posture de défense, surtout dans des environnements où les agents traitent des volumes élevés de conversations.
Les chercheurs décrivent aussi un autre angle, la possibilité de falsifier des réponses attribuées au modèle de langage. Dans un chatbot, l’utilisateur fait souvent confiance à l’interface et à la marque. Si un attaquant force des réponses orientées, il peut demander une réauthentification, pousser un lien, ou réclamer une information sensible sous couvert d’une procédure interne. Ce type d’attaque ne ressemble pas à une exfiltration brute, il se confond avec un dialogue normal, ce qui complique encore la détection.
Du point de vue opérationnel, le sujet pose la question des contrôles de changement. Un Playbook et ses Code Blocks sont des artefacts applicatifs. Dans un cadre mature, ils devraient être versionnés, soumis à revue, déployés via pipeline, et audités. Or, dans des produits low-code ou semi-code, les modifications se font parfois directement dans la console, par des profils non spécialistes de la sécurité. Quand un seul droit d’édition suffit, la discipline de revue devient la barrière principale.
L’incident met aussi en lumière la différence entre logs d’usage et logs de sécurité. Un journal d’exécution peut indiquer des appels et des erreurs, mais pas forcément les modifications de runtime, les écritures sur disque ou l’introduction d’une logique persistante. Dans ce dossier, Varonis estime que l’absence de traces pertinentes réduisait les chances de repérer une compromission sans action proactive.
Correctifs Google entre avril et juin 2026, conseils d’audit côté clients
Selon Varonis, la vulnérabilité a été signalée à Google en novembre 2025. Une première réponse correctrice serait intervenue en avril 2026, mais le problème n’aurait été totalement résolu qu’en juin 2026. Cette chronologie suggère un traitement en plusieurs étapes, fréquent dans les cas où la correction implique des changements d’architecture ou de contrôles d’exécution.
Pour les clients, l’enjeu est double, vérifier qu’aucun code non autorisé n’a été introduit avant les correctifs, et durcir les pratiques de gouvernance après. Les chercheurs recommandent de revoir les journaux d’audit liés aux modifications de Playbooks, en ciblant les événements de type DATA_WRITE et les appels UpdatePlaybook. Ce conseil vise à identifier des modifications inattendues, réalisées par des comptes inhabituels, à des horaires atypiques, ou depuis des localisations non conformes aux habitudes.
Varonis propose aussi de surveiller des erreurs anormales côté exécution, notamment des événements Sessions. DetectIntent qui pourraient signaler une logique altérée ou des comportements inhabituels. Ce type d’indicateur n’est pas une preuve, mais peut servir de point de départ dans une investigation, en corrélant erreurs, changements de configuration et périodes d’activité.
Enfin, la recommandation la plus directe consiste à inspecter manuellement chaque agent et ses Code Blocks, afin de repérer un code résiduel non autorisé. Cette étape est lourde dans les projets qui possèdent des dizaines d’agents et de Playbooks, mais elle reflète une réalité, si l’observabilité ne montre pas l’injection, la vérification doit se faire au niveau de l’artefact lui-même.
Dans les organisations où Dialogflow CX est exploité à grande échelle, l’épisode peut pousser à réévaluer la distribution des droits d’édition, la séparation des environnements, la revue systématique des changements et l’usage d’outils de détection de dérive. Les équipes sécurité s’attendent aussi à des clarifications sur les garanties d’isolation entre agents au sein d’un même projet, un point central pour limiter l’effet domino lors d’une compromission.
