Prompt injection : quelles parades protègent vraiment votre assistant IA ?

Quelles parades tiennent vraiment

Vous avez un assistant qui lit des documents de tiers, et un éditeur vous propose un classifieur anti-injection. Il repérera les consignes grossières du type « ignore tes instructions ». Sur environ 200 000 CV réels, pourtant, plus de 90 % des injections trouvées ne contiennent aucun ordre [1]. En 2025, l'attaque contre Microsoft 365 Copilot a justement contourné un classifieur d'injection [2]. Aucune parade ne suffit seule. Les plus solides se décident à la conception, et elles ne comptent pas sur le modèle pour bien se tenir.

Sommaire

• Aucune parade n'est complète
• Huit parades contre la prompt injection
• Douze contrôles avant de brancher l'assistant
• Sources

Aucune parade n'est complète

Les référentiels de sécurité l'écrivent eux-mêmes. Pour l'OWASP, rien ne garantit qu'une prévention infaillible existe, parce que les modèles sont stochastiques [3]. Le NIST constate que les mitigations actuelles laissent passer des attaques. Selon lui, un concepteur peut tenir l'injection pour possible dès que son modèle lit des entrées non fiables [4].

Il faut donc empiler des protections qui réduisent le risque sans le supprimer. Pour les classer, je me pose une seule question : la parade compte-t-elle sur le modèle pour ignorer la consigne cachée ? Moins elle dépend de lui, mieux elle tient. Séparer les privilèges et valider à la main ne demandent rien au modèle. Ce sont les deux que je mettrais en place avant toutes les autres.

Huit parades contre la prompt injection

1. Séparer les privilèges

Trois propriétés entrent en jeu : lire des contenus non fiables, accéder à des données sensibles, agir ou communiquer vers l'extérieur. Un assistant qui lit des documents de tiers ne devrait pas cumuler les deux autres [5]. L'ANSSI demande aussi de limiter les actions automatiques déclenchées par des mails ou des données venues d'internet [6]. Pour trancher usage par usage, la grille est détaillée dans les trois droits qu'un assistant IA ne doit pas cumuler.

2. Aucune action sans validation humaine

Envoyer un e-mail, modifier une fiche fournisseur, rejeter une candidature : l'assistant propose, et un humain valide en voyant ce qui va partir. C'est l'une des sept mesures de l'OWASP [3]. Encore faut-il qu'elle serve. Un utilisateur peut confirmer un avertissement sans le lire [5], et je crois qu'il le fait d'autant plus que la confirmation revient souvent. Réservez-la donc aux actions qui comptent. Montrez le contenu exact, et non un résumé écrit par le même modèle.

3. Séparer contrôle et données

Avec l'architecture CaMeL, les actions de l'assistant découlent de la seule demande de l'utilisateur. Les documents lus ne changent pas le programme exécuté, et les données ne sortent pas sans autorisation. En test, l'assistant protégé réussit un peu moins de tâches que sans défense [7]. Sur le papier, c'est la piste la plus prometteuse. Elle oblige pourtant à reconstruire l'architecture. Et elle protège les actions, sans rien garantir sur le contenu d'un résumé.

4. Filtrer les sorties

Dans les réponses, on neutralise les images Markdown, les liens vers des domaines hors liste blanche et les URL à longs paramètres. Appliquez en plus une politique de sécurité de contenu stricte. L'attaque contre Copilot l'a montré : le filtre doit couvrir toutes les syntaxes, liens par référence compris, et un proxy autorisé reste une sortie [2]. Le filtrage vaut aussi pour les entrées [6].

5. Nettoyer à l'ingestion

Le texte invisible se repère avant l'indexation, d'après la taille, la couleur, l'opacité et la position de chaque segment. C'est ce que montre la démonstration sur un devis PDF piégé. Il reste à choisir quoi en faire : rejet, quarantaine ou suppression des segments suspects. À mon avis, le plus sûr est de n'indexer que ce qu'un humain verrait. On passe la page rendue par un OCR et on la compare à la couche texte. Un gros écart signale une anomalie. Métadonnées et pièces jointes ne sont pas indexées par défaut. Aucun de ces filtres n'arrête une consigne écrite en clair dans le corps du document.

6. Marquer la provenance des contenus

Le spotlighting signale au modèle ce qui vient d'un tiers, par des délimiteurs, un marquage de chaque mot ou un encodage. En expérience, le taux de succès des attaques tombe de plus de 50 % à moins de 2 %, avec un impact minimal sur la tâche [8]. Le résultat vaut pour les modèles et les attaques testés. Un attaquant qui connaît le marquage peut s'y adapter.

7. Un classifieur, sans illusions

Un classifieur placé devant le modèle repère les tentatives de détournement avant qu'elles ne l'atteignent. Celui de Meta est petit et ouvert, et il ne voit que les ordres explicites [9]. Le service d'Azure vise aussi les instructions cachées dans des documents, des e-mails ou des pages web de tiers [10]. Contre « ignore tes instructions », c'est une couche de plus.

Sa limite tient à ce qu'il cherche. Il traque des ordres, alors que la plupart des injections réelles n'en donnent pas [1]. En sécurité web, un filtre qui arrête 95 % des attaques vaudrait une note éliminatoire [11].

8. Journaliser et tester en continu

Gardez le document source, le texte extrait, le prompt et la réponse. Vous comprendrez après coup d'où vient une recommandation étrange. L'ANSSI demande de journaliser tous les traitements du système d'IA [6]. Ajoutez au jeu de tests de l'assistant des documents piégés avec une consigne anodine, le « canari » de la démonstration. Rejouez-les à chaque changement de modèle, de prompt ou d'extracteur.

Douze contrôles avant de brancher l'assistant

1. Inventorier les assistants et agents qui lisent des contenus de tiers : e-mails, devis, CV, pages web. Un bot de prise de notes en fait partie, puisqu'il transcrit tout ce qui se dit. Un assistant de chiffrage de devis aussi, puisqu'il lit les demandes de prix des clients.
2. Pour chacun, remplir la grille des trois propriétés ; trois « oui » imposent une supervision humaine.
3. Donner à l'assistant les droits de son utilisateur, pas ceux d'un compte de service qui voit tout.
4. Faire valider par un humain, sur le contenu exact, tout envoi, modification, rejet ou commande.
5. Désactiver le rendu automatique des images Markdown et des liens hors liste blanche ; appliquer une politique de sécurité de contenu stricte.
6. Détecter le texte invisible à l'ingestion, prévoir une quarantaine et ne pas indexer par défaut les métadonnées ni les pièces jointes embarquées.
7. Tester avec des PDF piégés la bibliothèque d'extraction réellement utilisée.
8. Marquer la provenance des contenus tiers dans le prompt (délimiteurs, spotlighting).
9. Mesurer les faux négatifs de tout classifieur d'injection sur vos documents, sans en faire la seule barrière.
10. Journaliser document source, texte extrait, prompt et réponse, et fixer leur durée de conservation.
11. Rejouer les documents piégés à chaque changement de modèle, de prompt ou d'extracteur, et mener un exercice de red team avant chaque mise en production d'un nouvel agent.
12. Rappeler aux métiers que la réponse d'un assistant nourri de documents de tiers reste à vérifier.

Le diagnostic Data IA passe ces douze contrôles en revue pour chacun de vos cas d'usage, avant le branchement, et chiffre ce qu'il faut mettre en place. Il dure 8 jours et coûte 6 000 € HT de reste à charge, une fois l'aide de Bpifrance (40 %) déduite. La démarche complète, Diag Stratégie PI compris, revient à 7 500 à 11 000 € HT.

Sources

1. Zhang M., Jia Y., Tan Z., Jiang S., Gong N. Z., Chen T., Song D., « Measuring Real-World Prompt Injection Attacks in LLM-based Resume Screening », arXiv:2605.28999, 27 mai 2026, USENIX Security 2026. https://arxiv.org/abs/2605.28999
2. Reddy P., Gujral A. S., « EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System », arXiv:2509.10540, 6 septembre 2025. https://arxiv.org/abs/2509.10540
3. OWASP GenAI Security Project, « LLM01:2025 Prompt Injection », OWASP Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
4. NIST, « Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations », NIST AI 100-2 E2025, mars 2025, section 3.4. https://csrc.nist.gov/pubs/ai/100/2/e2025/final
5. Meta AI, « Agents Rule of Two: A Practical Approach to AI Agent Security », 31 octobre 2025. https://ai.meta.com/blog/practical-ai-agent-security/
6. ANSSI, « Recommandations de sécurité pour un système d'IA générative », ANSSI-PA-102, 29 avril 2024, recommandations R25, R27 et R29. https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative (PDF : https://messervices.cyber.gouv.fr/documents-guides/Recommandations_de_s%C3%A9curit%C3%A9_pour_un_syst%C3%A8me_d_IA_g%C3%A9n%C3%A9rative.pdf)
7. Debenedetti E., Shumailov I., Fan T., Hayes J., Carlini N., Fabian D., Kern C., Shi C., Terzis A., Tramèr F., « Defeating Prompt Injections by Design » (CaMeL), arXiv:2503.18813, mars 2025. https://arxiv.org/abs/2503.18813
8. Hines K., Lopez G., Hall M., Zarfati F., Zunger Y., Kiciman E., « Defending Against Indirect Prompt Injection Attacks With Spotlighting », arXiv:2403.14720, 20 mars 2024. https://arxiv.org/abs/2403.14720
9. Meta, fiche du modèle Llama Prompt Guard 2 86M, Hugging Face, consultée le 05/10/2026. https://huggingface.co/meta-llama/Llama-Prompt-Guard-2-86M
10. Microsoft Learn, « Prompt Shields in Azure AI Content Safety », consultée le 05/10/2026. https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection
11. Simon Willison, « The lethal trifecta for AI agents: private data, untrusted content, and external communication », 16 juin 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/