Pourquoi ce sujet est important
Une prompt injection survient lorsqu’un contenu amène le modèle à suivre des instructions contraires au but de l’application. Elle peut venir de l’utilisateur ou d’un document, email ou page récupéré. Aucun prompt système ne constitue à lui seul une barrière de sécurité.
Distinguer injection directe et indirecte
L’injection directe est saisie par l’utilisateur. L’indirecte est cachée dans une source que l’application fournit au modèle. Un RAG, un navigateur ou un agent de messagerie traite donc des contenus potentiellement hostiles, même si l’utilisateur est légitime.
Séparer données et instructions
Délimitez clairement les contenus externes et indiquez qu’ils ne sont pas des instructions. Cette mesure aide, mais ne garantit pas la sécurité. Les décisions sensibles doivent être contrôlées par du code et des politiques indépendantes du modèle.
Appliquer le moindre privilège
Donnez seulement les outils nécessaires à la tâche. Séparez lecture et écriture, limitez domaines, destinataires, chemins et volumes. L’outil applique identité, autorisation et validation des arguments. Le modèle ne reçoit jamais un secret qu’il n’a pas besoin d’utiliser.
Protéger contre l’exfiltration
Minimisez le contexte et isolez les données par tenant. Empêchez les outils réseau d’envoyer arbitrairement du contenu. Filtrez les destinations autorisées, détectez les volumes anormaux et exigez confirmation avant une communication externe. Les logs doivent aussi être protégés.
Valider les actions
Affichez récapitulatif, destinataire et effet avant email, publication, paiement ou suppression. Rendez les opérations idempotentes et bornées. Une sortie du modèle est une proposition non fiable jusqu’à sa validation déterministe.
Traiter les documents comme non fiables
Analysez provenance, type et contenu lors de l’ingestion. Ne laissez pas un document modifier la politique ou activer un outil. Pour les pages web, séparez navigation, extraction et décision. Conservez citations pour permettre la revue.
Tester en continu
Créez un corpus d’attaques : fausses instructions, encodage, contenu multilingue, demande de secret, outil détourné et injection dans une source. Mesurez si une donnée est exposée ou une action déclenchée. Rejouez après chaque changement de modèle ou prompt.
Exemple concret
Un agent lit des CV reçus par email. Un PDF contient une instruction demandant d’envoyer les autres candidatures à une URL. Le modèle peut voir le texte, mais ne possède aucun outil réseau générique. L’outil email limite les destinataires et toute communication externe exige validation.
Les erreurs fréquentes
- croire qu’un prompt “ignore les attaques” suffit
- donner un outil HTTP générique
- mettre tous les documents du tenant dans le contexte
- laisser le modèle décider des droits
- journaliser secrets et prompts complets
- tester seulement des attaques en anglais
Checklist
- [ ] Contenus externes identifiés
- [ ] Outils au moindre privilège
- [ ] Autorisation dans le backend
- [ ] Destinations et volumes bornés
- [ ] Actions sensibles confirmées
- [ ] Secrets hors contexte
- [ ] Corpus d’attaques automatisé
- [ ] Alertes d’usage anormal
FAQ
Peut-on éliminer toute prompt injection ?
Pas uniquement par prompting. Réduisez l’impact avec architecture, permissions et validations.
Le RAG est-il vulnérable ?
Oui, car les documents récupérés peuvent contenir des instructions malveillantes.
Un classifieur suffit-il ?
Non. Les détecteurs aident mais peuvent être contournés ; les contrôles d’autorisation restent essentiels.
Que faire si le modèle doit envoyer un email ?
Limitez destinataires et contenu, affichez un aperçu et exigez une confirmation selon le risque.