Injection directe
L’instruction hostile est saisie directement dans le chatbot, le champ de saisie ou l’API conversationnelle par l’utilisateur.
PROMPT INJECTION · DIRECTE & INDIRECTE
Une simple entrée peut-elle détourner les instructions de votre IA ?
Une prompt injection cherche à faire traiter une donnée contrôlée par l’attaquant comme une instruction prioritaire. Elle peut modifier une réponse, révéler le prompt système ou le contexte RAG, contourner une règle métier et pousser un agent connecté à utiliser un outil hors du scénario prévu.
Définition de la prompt injection
Une prompt injection est une entrée conçue pour modifier le comportement attendu d’une application fondée sur un modèle de langage. Elle exploite le fait que les données et les instructions sont souvent présentées au modèle sous une même forme linguistique, sans séparation parfaitement fiable.
L’OWASP LLM01:2025 distingue notamment les injections directes et indirectes. Une attaque réussie peut changer une réponse, révéler une information, influencer une décision ou pousser un système connecté à utiliser une fonction de manière imprévue.
Injection indirecte
L’instruction est cachée dans un document, un email, une page web, un ticket, une image interprétée ou la sortie d’un outil consulté par le LLM.
Définition du jailbreak d’un LLM
Un jailbreak est une technique de contournement visant à faire ignorer au modèle ses règles de sûreté ou d’alignement afin d’obtenir un comportement ou un contenu normalement refusé. L’objectif est donc plus précis que celui d’une prompt injection au sens large.
Un jailbreak peut s’appuyer sur un changement de rôle, une mise en scène fictive, une transformation du contenu, une obfuscation, une conversation progressive ou d’autres formulations conçues pour faire céder les refus. Cependant, une injection qui détourne une remise commerciale, révèle le contexte RAG ou déclenche une API n’est pas nécessairement un jailbreak : elle peut réussir sans neutraliser les politiques de modération du modèle.
| Critère | Prompt injection | Jailbreak |
|---|---|---|
| Ce que le terme décrit | La manipulation des instructions ou du contexte d’une application LLM. | Le contournement des règles de sûreté du modèle. |
| Vecteur | Direct ou indirect, via utilisateur, document, email, page web ou outil. | Le plus souvent une interaction spécialement construite avec le modèle. |
| Objectif possible | Modifier une règle, extraire une donnée, influencer une décision ou déclencher une fonction. | Obtenir un comportement ou un contenu que le modèle devrait refuser. |
| Relation | Catégorie plus large dans la taxonomie OWASP. | Forme de prompt injection orientée vers le contournement de la sûreté. |
Quels impacts une prompt injection peut-elle provoquer ?
Fuite d’informations
Exposition de données personnelles, de contexte interne, de secrets métier ou de fragments appartenant à un autre utilisateur.
Fuite du prompt système
Révélation ou inférence d’instructions internes. Le risque réel vient des secrets, permissions ou contrôles fragiles révélés par ces instructions.
Détournement d’un processus
Modification d’un tarif, d’une condition, d’une politique de réponse ou d’une décision utilisée par l’application.
Abus d’outil ou d’API
Utilisation d’une capacité légitime de l’agent dans un but non prévu : envoi, extraction, modification ou action externe.
Pourquoi les filtres et le prompt système ne suffisent-ils pas ?
Une règle écrite dans le prompt système reste interprétée par un modèle probabiliste. Elle peut réduire certains comportements, mais elle ne fournit pas la garantie déterministe d’un contrôle d’accès ou d’une validation logicielle. De même, un filtre de mots-clés peut être contourné par des variations de langue, de format ou de contexte.
La protection doit donc être construite en profondeur : séparation des instructions et des données, limitation du contexte, contrôle d’accès appliqué avant le retrieval, permissions minimales, allowlist des outils, validation stricte des paramètres, filtrage des sorties et confirmation externe pour les actions sensibles.
Il n’existe pas de défense unique garantissant l’absence de prompt injection. L’objectif réaliste consiste à réduire la probabilité de manipulation et surtout à empêcher qu’une mauvaise sortie du modèle puisse atteindre une donnée ou une action critique.
Comment Heldguard teste ces attaques
Le test commence par les entrées réellement accessibles : interface publique, API, fichiers importés, sources RAG, webhooks et sorties d’outils. Les scénarios sont ensuite adaptés aux réactions du système. Une tentative isolée n’est pas considérée comme suffisante pour conclure qu’un contrôle est robuste.
Chaque résultat est classé selon son effet : changement de comportement, divulgation, franchissement d’une frontière de confiance, appel de fonction ou impact métier. Le rapport conserve la séquence de reproduction et distingue clairement un simple contournement conversationnel d’une vulnérabilité permettant une action ou une fuite.
Sources officielles
Testons les défenses réelles de votre application.
Le périmètre couvre les vecteurs accessibles, les données exposées et les effets possibles au-delà de la simple réponse du modèle.