Un rapport de Google qui m’a interpelé sur ce type de menace.
En tant que professionnel de la cybersécurité, je suis confronté quotidiennement à l’évolution des menaces liées à l’intelligence artificielle générative.
L’une des attaques émergentes les plus préoccupantes est celle que l’on appelle les injections de prompt, et plus spécifiquement leur forme indirecte.
Contrairement aux attaques directes où une commande est saisie intentionnellement dans un champ de prompt, l’injection indirecte consiste à cacher des instructions malicieuses dans des documents, emails ou pages web. Lorsqu’un LLM ingère ces données pour les résumer ou répondre à une requête, il peut exécuter à son insu les commandes enfouies, provoquant des fuites de données ou des actions non sollicitées.
Des cas concrets récents comme la faille EchoLeak sur Microsoft Copilot ou les expérimentations décrites par The Guardian sur ChatGPT l’ont bien démontré : il ne s’agit pas de science-fiction. En tant que professionnel de la sécurité, j’ai compris que cette attaque repose moins sur une faille technique traditionnelle que sur une faille de gouvernance des flux manipulés par les modèles. Il devient donc impératif de penser la sécurité non seulement en amont du modèle (entraînement, supervision), mais tout au long du cycle de vie du prompt.
Le 13 juin 2025, Google a publié une réponse détaillée à cette menace : une stratégie de défense multicouche intégrée à son assistant IA Gemini. Dans cet article, je vais vous partager ma lecture critique de cette stratégie, les enseignements que j’en tire, et les recommandations que je propose pour les CERT, CSIRT et RSSI qui veulent anticiper ces attaques dans leur propre environnement.
Ce que j’ai observé dans la stratégie Gemini
Google applique une approche en cinq couches :
- Des classifieurs pour détecter le contenu malveillant
- Des consignes de sécurité injectées dynamiquement dans les prompts
- Un filtrage Markdown et une neutralisation des URL externes
- Une validation explicite des actions sensibles (HITL)
- Des notifications aux utilisateurs lorsqu’un contenu est bloqué
Chacune de ces mesures est pertinente, mais ce qui m’a marqué, c’est leur complémentarité. Il ne s’agit pas d’un simple filtre en amont, mais d’un véritable pipeline de durcissement dynamique, depuis l’ingestion des données jusqu’à la réponse finale.
Mon analyse technique point par point
- Les classifieurs ML sont efficaces pour les patterns connus, mais sensibles aux évasions. Leur qualité dépendra des corpus utilisés et de leur mise à jour continue.
- Le renforcement par consigne de sécurité me paraît très pertinent : rappeler au LLM de se limiter à sa tâche réduit fortement les risques. Cela doit devenir un standard.
- La neutralisation des images Markdown et des URL est à mon sens la réponse la plus concrète aux scénarios d’exfiltration silencieuse comme EchoLeak. J’ai souvent noté que l’absence de contrôle sur les liens générés était une faille critique.
- La confirmation humaine (HITL) est une bonne idée, mais j’ai des doutes sur sa robustesse si l’utilisateur est peu sensibilisé. Il faut que cette mesure soit accompagnée de formation.
- Les notifications de mitigation sont sous-estimées : elles permettent à l’utilisateur de comprendre qu’il a frôlé une attaque, et donc d’être plus vigilant la prochaine fois.
Ce que je recommande aux CERT, CSIRT et RSSI
Voici mes recommandations basées sur cette approche :
- Filtrer tous les flux vers les LLMs via un proxy dédié (avec détection des patterns d’injection).
- Encadrer les prompts par des consignes de sécurité explicites dans le prompt engineering.
- Empêcher tout rendu Markdown actif ou URL non vérifiée dans les réponses.
- Mettre en place des mécanismes HITL ciblés, uniquement sur les actions critiques, pour ne pas saturer l’utilisateur.
- Logger systématiquement les prompts, leurs sources et les réponses pour analyse post-incident.
- Faire du red teaming IA régulier, notamment avec des scénarios document piégé + résumés.
- Former les utilisateurs aux messages de mitigation et à leur rôle dans la détection.
Conclusion
Ce que je retiens, en tant que professionnel de terrain, c’est que la sécurité des LLMs est désormais un enjeu système.
L’approche de Google Gemini me semble juste : penser en couches, intégrer des défenses à tous les niveaux, responsabiliser l’utilisateur.
Mais il ne suffit pas de copier : il faut adapter. Dans nos CERT et SOC, dans nos applications internes, dans nos outils de veille ou d’aide à la décision, nous devons penser les LLMs comme des composants sensibles, capables d’être manipulés.
Et nous devons leur appliquer les mêmes principes que pour tout SI critique : cloisonnement, surveillance, contrôle humain, et retour d’expérience.
Enjoy
