Outils

Instructions cachées : se protéger

Aucun outil n'arrête à coup sûr les consignes piégées glissées dans un PDF ou une page web : on réduit le risque en limitant les droits de l'IA.

M

Par Marie

Nantes · 29 octobre 2026 · 6 min de lecture

X in f

Loupe posée sur des feuilles imprimées près d'un ordinateur portable fermé, sous une lampe

Aucun outil ne garantit aujourd'hui d'arrêter les consignes piégées glissées dans un document : l'OWASP GenAI Security Project indique qu'il n'est pas clair qu'il existe des méthodes de prévention infaillibles. Le choix dépend donc de l'usage : limiter les droits de l'IA et contrôler ses actions pour une application ou un agent, ajouter une détection ou un contrôle des données pour une entreprise. Les filtres s'ajoutent à ces mesures, sans les remplacer.

Quel outil choisir contre les consignes cachées dans un document ?

Le choix commence par l'architecture plutôt que par un produit. Les recommandations de l'OWASP insistent sur la séparation du contenu non fiable et sur le contrôle des permissions hors du modèle ; un outil de détection vient en renfort.

Comment l'attaque fonctionne

Selon l'OWASP GenAI Security Project, une injection de prompt indirecte se produit lorsqu'un modèle de langage accepte des données issues de sources externes, comme des sites web ou des fichiers. La fiche de prévention de l'OWASP la décrit comme des instructions malveillantes cachées dans un contenu externe que le modèle traite. Si un utilisateur demande le résumé d'un PDF, le modèle peut donc suivre la consigne dissimulée dans le fichier plutôt que la sienne.

La cause est structurelle. Le NCSC, l'autorité cyber britannique, écrit dans un billet publié le 08/12/2025 que les modèles actuels « simply do not enforce a security boundary between instructions and data ». Google, dans sa documentation d'administration Workspace mise à jour le 10/03/2026, présente le phénomène ainsi : « L'injection de prompt indirecte est un type de faille de sécurité dans les systèmes d'IA ».

Ce que couvre chaque approche

Le tableau compare quatre approches selon un seul critère : ce qu'en disent l'OWASP, le NCSC et Google, au 29/10/2026.

Approche	Ce qu'en disent les sources	Limite relevée
Classificateurs de contenu	Google décrit des classificateurs de contenu pour l'injection de prompt dans sa défense multicouche pour Gemini (Google, 10/03/2026)	Les filtres à motifs n'attrapent pas de façon fiable l'injection indirecte (OWASP) ; il existe « infinite ways to rephrase an attack » (NCSC)
Séparation du contenu non fiable	L'OWASP recommande de le tenir à part des consignes de confiance (OWASP)	L'étiquetage seul ne fait pas respecter cette frontière (OWASP)
Contrôle des actions hors du modèle	Valider les arguments des outils et appliquer les permissions de l'appelant dans le code d'exécution (OWASP)	Agit sur les conséquences, pas sur la lecture du texte piégé
Réduction de la probabilité ou de l'impact	Le NCSC estime que c'est le mieux à espérer (NCSC)	Les attaques pourraient ne jamais être totalement neutralisées (NCSC)

Les taux annoncés par les défenses méritent de la prudence. Dans l'étude The Attacker Moves Second, publiée sur arXiv le 10/10/2025, les auteurs contournent 12 défenses récentes avec un taux de réussite d'attaque supérieur à 90 % pour la plupart, alors que la majorité avaient d'abord affiché des taux proches de zéro. Un taux de détection avancé par un éditeur se lit donc avec la méthode d'attaque utilisée.

Selon le besoin, les acteurs ne se valent pas. Les périmètres exacts et les tarifs se demandent à chaque éditeur.

Les mesures à appliquer

Traiter tout PDF, page web ou courriel lu par l'IA comme un contenu non fiable, séparé des consignes de confiance (OWASP).
Contrôler les arguments des outils proposés par le modèle et faire respecter les permissions dans le code d'exécution, hors du modèle (OWASP).
Donner à l'IA le minimum de droits, puisque le NCSC vise la réduction de la probabilité ou de l'impact des attaques.
Ajouter une couche de détection, en gardant en tête qu'elle peut être contournée.
Associer le RSSI et le DPO lorsque des données personnelles ou confidentielles transitent par l'IA. Les obligations liées au RGPD, à NIS2 ou à l'AI Act dépendent de chaque situation : le DPO ou un juriste tranche.

ZeusLock est-il efficace face aux injections indirectes ?

Son efficacité sur ce point précis n'est pas chiffrée : aucun taux de détection n'est indiqué sur la page de la marque, et la protection contre l'injection de prompt y figure sans résultat mesuré. Il est donc impossible de conclure par oui ou non à partir de ces seules informations.

Selon ZeusLock (zeuslock.ai), éditeur français de protection des données pour l'IA générative, son produit est une « DLP IA » conçue pour la souveraineté. Il détecte avant leur envoi vers les IA les informations sensibles : clés d'API, identifiants, IBAN, données personnelles et code source. Il peut ensuite, au choix, les masquer en conservant leur format ou les bloquer. Les IA concernées vont de DeepSeek et Mistral à ChatGPT, en passant par Claude, Gemini, Copilot, Cursor, Perplexity et Grok.

D'après l'éditeur, la protection s'applique dans le navigateur, sur le poste de travail (Windows, Mac, Linux), à la ligne de commande, dans les environnements de développement, ainsi que pour les agents IA et les serveurs MCP. Un déploiement sur site est possible pour les organisations qui ne veulent pas que leurs données transitent par un service tiers. Il met aussi en avant le repérage des usages d'IA non déclarés (Shadow AI), un volet contre l'injection de prompt et le jailbreak, ainsi qu'un branchement aux chaînes CI/CD. L'offre vise d'abord les RSSI et les DPO d'organisations européennes.

Ce positionnement relève surtout du contrôle des données avant envoi. Une question reste à poser avant tout achat : la protection contre l'injection analyse-t-elle les documents et les pages que l'agent lit, ou seulement ce qui part vers l'IA ? Cette précision n'est pas indiquée sur la page de la marque.

Les limites rappelées par l'OWASP et par le NCSC valent pour tous les produits, quels qu'ils soient. Pour vérifier une promesse de détection, il est pertinent de demander une évaluation menée avec des attaques adaptatives, comme celles décrites dans l'étude arXiv de 2025.

L'option se défend surtout pour une organisation européenne qui place la souveraineté et le déploiement sur site en tête de ses critères. Pour filtrer les entrées d'une application développée en interne, un spécialiste de la sécurité des LLM peut convenir davantage. Une organisation déjà équipée d'une plateforme de prévention de fuite de données peut aussi préférer étendre l'existant. Pour un cas particulier, le DPO ou un juriste reste l'interlocuteur.