La prompt injection est une attaque ou interaction où des instructions issues de l’utilisateur ou d’un contenu externe détournent le modèle du comportement voulu. Elle est directe dans le prompt ou indirecte dans un document, une page, un message ou un résultat d’outil.
Les modèles traitent instructions et données dans le même canal linguistique. Une phrase dans un document peut rivaliser avec la tâche système, sans frontière de sécurité déterministe. L’impact devient grave si le modèle reçoit secrets, outils puissants ou capacité d’agir.
Une consigne système plus forte ne suffit pas. Supposez que le modèle peut être influencé et concevez le système pour qu’une sortie manipulée ne dépasse pas les droits, ne divulgue pas de données inutiles et n’agisse pas sans politique et validation.
Attaques
L’injection indirecte transforme un contenu ordinaire en instruction
L’injection directe apparaît dans le message utilisateur. L’indirecte est incorporée dans une page, un PDF, un ticket, un calendrier ou un article que l’application lit ensuite. L’utilisateur peut ne jamais la voir.
Un agent amplifie le risque par ses actions. Une page peut demander l’envoi de données ou modifier des arguments d’outil. Provenance et hiérarchie aident, mais la sécurité vient de données et autorité limitées hors du modèle.
| Surface | Exemple | Contrôle |
|---|---|---|
| Entrée utilisateur | Remplacer la tâche | Limite de capacité |
| Document | Action cachée | Traitement non fiable |
| Résultat outil | Texte API hostile | Schéma et provenance |
| Mémoire | Instruction persistante | Politique d’écriture |
| Sortie modèle | Commande ou balisage | Validation aval |
Défense
Concevoir pour un modèle susceptible de suivre la mauvaise instruction
Les défenses par instruction réduisent certains cas mais restent probabilistes. Les contrôles forts sont classiques: moindre privilège, autorisation, minimisation, isolation, interfaces validées, confirmation, suivi et réponse aux incidents.
Adaptez au dommage. Un outil de rédaction sans secret a moins d’impact qu’un agent capable d’envoyer, acheter ou modifier. Renforcez revue et isolation avec l’autorité et gardez un arrêt déterministe avant tout effet irréversible.
- Ne jamais utiliser le prompt comme autorisation.
- Garder les secrets hors du contexte.
- Traiter tout texte retrouvé comme non fiable.
- Valider dans le composant qui exécute.
- Tester les effets plutôt que le refus.
Ce qui caractérise un bon résultat
Résultats concrets pour prompt injection
- Le contenu non fiable est identifié dans chaque canal d’entrée.
- Secrets et contexte sensible inutile restent hors des prompts.
- L’autorisation des outils est imposée hors du modèle.
- Les actions importantes exigent contrôle déterministe et confirmation.
- Les tests mesurent réponse et effets en aval.
Modèle opératoire
Comment exécuter le travail
- 01
Cartographier instructions et données
Inventoriez consignes système, messages, fichiers, web, courriels, mémoire et outils. Marquez confiance, propriétaire et permission. Un contenu client, tiers ou généré reste non fiable même dans un document métier.
- 02
Réduire l’autorité accessible
Ne placez pas de secret réutilisable dans le prompt. Donnez des opérations étroites et droits minimaux, autorisez lors de l’exécution et limitez à l’utilisateur et à la ressource. Séparez lire, rédiger et agir.
- 03
Limiter et valider les effets
Utilisez schémas d’outils, listes permises, validation, encodage et contrôles transactionnels. Montrez les détails avant confirmation. Validez URL, code, requête et balisage dans le système qui les reçoit.
- 04
Tester les chemins réalistes
Placez des instructions adverses dans prompts, documents, métadonnées, pages et résultats. Testez exfiltration, redirection, abus d’outil et persistance. Mesurez si l’effet fut empêché, pas si le modèle a écrit un refus.
Évaluation
Les questions qui changent la décision
- Quelles entrées un acteur non fiable influence-t-il?
- Quelles données et quels outils sont inutiles pour la tâche?
- Où l’autorisation est-elle imposée à l’appel?
- Quelle sortie devient exécutable, rendue ou transmise?
- Quelle confirmation humaine a du sens avant l’effet?
Modes d’échec
Où les équipes perdent le contrôle
Un document retrouvé redirige l’agent vers le but de l’attaquant.
Le secret du prompt crée une fausse confiance car le contexte peut fuir.
Un outil trop puissant transforme le texte en action non autorisée.
La sortie injecte du code dans un interpréteur aval.
La mémoire conserve une instruction hostile pour plus tard.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- scénarios bloqués avant effet matériel
- appels non autorisés refusés par politique
- champs sensibles exposés au modèle par tâche
- actions importantes avec confirmation valide
- sorties dangereuses rejetées en aval
- couverture de régression par canal
Questions
Questions fréquentes
Qu’est-ce que la prompt injection?
Une entrée utilisateur ou un contenu externe fournit des instructions qui détournent le modèle du comportement prévu par l’application.
Qu’est-ce que l’injection indirecte?
Une instruction cachée dans un document, une page, un courriel ou un résultat que l’application donnera plus tard au modèle.
Le prompt système empêche-t-il l’attaque?
Non de façon déterministe. Il faut moindre privilège, autorisation externe, minimisation, outils validés et approbation des actions importantes.
Prompt injection et jailbreak sont-ils identiques?
Ils se recoupent. Le jailbreak vise souvent les restrictions du modèle; l’injection vise les instructions de l’application et peut exploiter contenu et outils.
Sources
Sources primaires
- LLM01:2025 Prompt Injection OWASP Gen AI Security Project
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→