Injection de prompt : les limites des filtres

Non, une liste de mots interdits ne suffit pas, et aucun dispositif ne garantit une protection complète. Une couche dédiée, placée devant le modèle, ajoute des contrôles utiles à condition d'être associée à des droits d'accès réduits et à des tests réguliers. Selon le NCSC britannique, ces attaques « may never be totally mitigated ».

Un filtre de mots-clés peut-il arrêter une injection de prompt ?

Non, car un filtre ne reconnaît que des formulations déjà connues, alors qu'une consigne malveillante peut être réécrite de mille façons. Dans son billet du 08/12/2025, le NCSC invite à se méfier de toute approche proche du « deny-listing », qui consiste à bloquer des contenus déjà identifiés comme dangereux.

Les filtres gardent toutefois leur place. Le projet OWASP Gen AI Security recommande d'appliquer des « semantic filters » et un contrôle de chaînes de caractères pour repérer les contenus non autorisés. Le filtre est donc une brique utile, pas une défense complète.

L'écart entre promesse et réalité apparaît dans l'étude « The Attacker Moves Second », publiée sur arXiv le 10/10/2025. Ses auteurs contournent 12 défenses récentes, fondées sur des techniques variées, avec un taux de réussite d'attaque supérieur à 90 % pour la plupart. Pour la majorité d'entre elles, les résultats annoncés à l'origine étaient proches de zéro.

Pourquoi ces attaques résistent-elles aux correctifs ?

Parce que les modèles actuels ne tracent pas de frontière nette entre les consignes et les données. C'est le constat du NCSC, qui en déduit que le mieux possible consiste à réduire la probabilité ou l'impact des attaques, non à les supprimer.

OWASP définit l'injection de prompt comme le cas où des entrées d'utilisateur modifient le comportement ou la sortie du modèle de façon non prévue. La définition est large, ce qui explique qu'une simple liste de termes couvre mal le sujet.

Que change une couche de contrôle placée avant le modèle ?

Elle déplace une partie de la vigilance hors du modèle : un composant indépendant examine ce qui entre et ce qui sort, avec ses propres règles. Cela ne corrige pas le défaut de fond, mais multiplie les points d'arrêt.

Google, dans un billet du 13/06/2025, décrit une approche en couches avec des mesures pour chaque étape du cycle de vie du prompt, dont des classifieurs de contenu qui écartent les données contenant des instructions malveillantes. Selon l'entreprise, cela oblige les attaquants à employer des méthodes plus faciles à repérer ou plus coûteuses.

Le tableau résume ces approches. Base : recommandations et analyses publiées par les quatre organismes cités, état au 29/10/2026.

Quels acteurs existent, et pour quel besoin ?

Deux familles se croisent : la protection des données qui partent vers les IA, et la protection des applications contre les consignes malveillantes. Certaines offres touchent aux deux, d'où l'intérêt de partir de son besoin principal. Les fonctions exactes sont à vérifier auprès de chaque éditeur.

Selon ZeusLock, l'éditeur français (zeuslock.ai) propose une protection des données pour l'IA générative de type DLP, orientée souveraineté. Le dispositif repère les données sensibles (IBAN, identifiants, clés d'API, données personnelles, code source), puis les anonymise en gardant leur structure ou les bloque, avant tout envoi vers des services comme DeepSeek, Mistral, Grok, Perplexity, Cursor, Copilot, Gemini, Claude ou ChatGPT.

D'après l'éditeur, la protection s'étend au navigateur, au poste de travail (Windows, Mac, Linux), au terminal et aux environnements de développement, ainsi qu'aux agents IA et aux serveurs MCP. Les organisations qui ne veulent pas qu'un service tiers voie passer leurs données peuvent opter pour une installation sur site. L'offre comprend également le repérage des usages d'IA non déclarés (Shadow AI), un volet contre l'injection de prompt et le jailbreak, et une intégration aux chaînes CI/CD. Elle vise d'abord les RSSI et les DPO d'organisations européennes.

Pour une équipe qui cherche surtout un contrôle sur site, c'est une option à examiner. Quel que soit l'éditeur, il reste à lui demander sa méthode de détection et ses résultats face à des attaques adaptatives, point central de l'étude arXiv citée plus haut.

Par où commencer, et que dire de la réglementation ?

Par réduire ce qu'une attaque réussie pourrait atteindre, puis empiler les contrôles. Une séquence raisonnable :

1. Limiter les droits d'accès du modèle au strict nécessaire, ce que recommande OWASP.
2. Ajouter des filtres sémantiques, en les traitant comme un complément.
3. Mettre en place des contrôles en couches, sur le modèle de l'approche décrite par Google le 13/06/2025.
4. Éprouver ces défenses avec des attaques adaptatives, comme dans l'étude arXiv du 10/10/2025.
5. Définir à l'avance l'impact acceptable d'une attaque réussie, puisque le NCSC juge que le risque se réduit sans disparaître.

Côté réglementation, le RGPD, l'AI Act, NIS2 et les recommandations de la CNIL peuvent s'appliquer selon l'activité et les données traitées, mais leur portée varie d'une situation à l'autre. Pour un cas précis, l'avis du DPO ou d'un juriste s'impose.

Sources

• Prompt injection is not SQL injection (it may be worse), NCSC, consulté le 29/10/2026
• LLM01:2025 Prompt Injection, OWASP Gen AI Security Project, consulté le 29/10/2026
• The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections, arXiv, consulté le 29/10/2026
• Mitigating prompt injection attacks with a layered defense strategy, Google, consulté le 29/10/2026