La prompt injection est souvent présentée comme un problème de formulation : il suffirait de trouver les bons mots pour contourner un modèle. Cette vision est incomplète. Dans une application réelle, le risque apparaît surtout lorsque le modèle est placé au centre d’un système qui mélange des instructions fiables, du contenu non fiable et des outils capables d’agir.
Une confusion entre données et instructions
Un modèle de langage reçoit du texte sans disposer d’une séparation matérielle entre « ce qu’il doit faire » et « ce qu’il doit seulement lire ». Une page Web, un document récupéré par RAG ou la description d’un outil MCP peut donc contenir du texte ressemblant à une instruction prioritaire.
La question utile n’est pas « le modèle peut-il être trompé ? », mais « que peut-il faire lorsqu’il se trompe ? »
Le chemin d’impact
Une analyse sérieuse suit la chaîne complète :
- Entrée contrôlée : quel contenu un acteur externe peut-il influencer ?
- Interprétation : ce contenu est-il présenté au modèle avec son origine et son niveau de confiance ?
- Décision : le modèle peut-il transformer ce contenu en action ?
- Capacité : quels outils, secrets et destinations réseau sont disponibles ?
- Validation : une personne doit-elle confirmer l’action sensible ?
Tester sans chercher un « prompt magique »
Le test doit varier la provenance et l’encodage des instructions, mais surtout mesurer les conséquences. On commence par une action inoffensive et observable dans un laboratoire : produire un marqueur, sélectionner un faux outil ou tenter d’accéder à une ressource synthétique. Aucun secret réel ni système tiers n’est nécessaire.
Principe de laboratoire
Utiliser des identifiants factices, limiter les sorties réseau et journaliser chaque appel d’outil. La réussite du test doit être mesurable sans créer de risque extérieur.
Réduire le blast radius
Les défenses robustes ne reposent pas uniquement sur un filtre de texte. Elles combinent séparation des rôles, provenance des données, permissions minimales, validation de schéma, listes de destinations autorisées et confirmation humaine pour les opérations irréversibles.
- Traiter les résultats Web, e-mails et documents comme non fiables.
- Ne jamais placer un secret dans le contexte si la tâche n’en a pas besoin.
- Attribuer une identité et des permissions distinctes à chaque outil.
- Bloquer par défaut les sorties réseau inattendues.
- Conserver une trace exploitable de la décision et de l’action.
Conclusion
La prompt injection ne disparaîtra probablement pas avec une meilleure phrase système. Elle devient toutefois contrôlable lorsque l’architecture suppose que le modèle peut être influencé et limite rigoureusement les conséquences d’une mauvaise décision.
Note suivanteCartographier une surface d’attaque Web →