Fuite de prompt (System Prompt Leakage) : risques et sécurité des chatbots IA

Un développeur pourrait être tenté d’intégrer temporairement une clé d’API dans le prompt système d’un chatbot de service client, avec l’intention de la retirer ultérieurement. Si le modèle divulgue ensuite ses instructions à la suite d’une requête utilisateur, cette clé peut être exposée. Ce scénario illustre le risque décrit par OWASP dans la catégorie LLM07:2025 – System Prompt Leakage : un prompt système ne doit jamais être considéré comme un secret ni utilisé comme un mécanisme de sécurité. Les clés API, identifiants et chaînes de connexion doivent être conservés en dehors du prompt et protégés par des contrôles d’accès indépendants du modèle

Fuite de prompt, Prompt Injection et Jailbreak : Quelles différences ?

La fuite de prompt (system prompt leakage) partage une parenté technique avec le prompt injection et le jailbreak, déjà traités dans les articles précédents, mais poursuit un objectif différent. Là où le prompt injection détourne le comportement d’un système et où le jailbreak contourne ses garde-fous de contenu, la fuite de prompt système vise spécifiquement à faire révéler au modèle les instructions qui définissent son propre fonctionnement : logique métier, règles d’autorisation, détails d’intégration, configuration des garde-fous. Une fois ces instructions extraites, un attaquant dispose du plan exact de fonctionnement du système, ce qui lui permet ensuite de calibrer des attaques bien plus ciblées pour contourner les défenses qu’il vient de découvrir.

Techniques d’extraction de prompt : Comment les attaquants piègent les LLM

Les méthodes d’extraction vont de la requête directe la plus triviale, par exemple demander au modèle de répéter les phrases ou les instructions précédentes, à des approches d’obfuscation destinées à contourner des filtres textuels, comme l’encodage en base64 ou en hexadécimal. OWASP classe l’encodage parmi les techniques d’obfuscation utilisées dans les attaques par injection de prompt et recommande de ne pas limiter les défenses à une simple recherche de mots-clés.

Des travaux académiques ont également montré qu’il était possible d’automatiser la génération des requêtes d’extraction. Le framework PLeak optimise progressivement une requête adverse afin de reconstruire le prompt système, tout en ciblant une application accessible uniquement par son interface de requête-réponse. L’attaquant n’a donc pas besoin d’un accès direct aux paramètres internes du système cible. Cette approche a été évaluée sur des applications LLM réelles hébergées sur Poe.

En janvier 2026, les chercheurs de Praetorian ont montré qu’un assistant LLM pouvait divulguer son prompt système à travers des champs modifiables de l’interface, alors même que ses réponses de chat étaient limitées à des messages prédéfinis. Dans leur scénario, le modèle inscrivait des fragments du prompt dans des champs de formulaire et les encodait en Base64 afin de les rendre exploitables et de contourner d’éventuels filtres. L’exemple montre qu’une restriction portant uniquement sur le texte affiché dans le chat ne suffit pas : chaque champ, action, journal ou sortie contrôlé par le modèle peut devenir un canal d’exfiltration.

Exemples et cas réels de fuite de prompt système (Bing Chat, ChatGPT)

L’un des premiers cas largement médiatisés reste la fuite du prompt système de Bing Chat en février 2023. Cet assistant conversationnel de Microsoft, intégré au moteur de recherche Bing et reposant sur un modèle de langage d’OpenAI, a rapidement fait l’objet de tentatives visant à révéler ses instructions internes. Par de simples requêtes d’injection, des utilisateurs ont obtenu des instructions initiales révélant notamment le nom de code interne « Sydney », des contraintes comportementales et des règles opérationnelles.

L’épisode a montré qu’un prompt dissimulé dans le contexte du modèle ne constitue pas, à lui seul, une frontière de confidentialité fiable.

Depuis 2025, plusieurs dépôts publics ont archivé des prompts système attribués à des assistants majeurs tels que ChatGPT, Claude, Gemini, Grok et Perplexity. Ces collections documentent l’existence de techniques d’extraction et donnent accès à de nombreux exemples obtenus par injection ou rétro-ingénierie.

OWASP illustre le risque par le scénario d’une application bancaire dont le prompt système révélerait une règle opérationnelle précise : une limite de transaction fixée à 5 000 dollars par jour et par utilisateur, ainsi qu’un plafond global de prêt. La divulgation de ces informations pourrait aider un attaquant à contourner les contrôles associés, par exemple en adaptant ses transactions ou ses demandes de crédit aux seuils connus. Un exemple direct de la façon dont une simple fuite d’instruction se traduit en fraude financière exploitable, sans qu’aucune faille technique n’ait été nécessaire ailleurs dans le système.

Bonnes pratiques de sécurité des prompts du système.

Concevoir en supposant que le prompt sera divulgué. Un prompt système peut orienter le comportement du modèle, mais il ne doit être considéré ni comme un secret ni comme une frontière de sécurité. Les clés API, jetons d’authentification et autres informations sensibles doivent être conservés en dehors du prompt, dans des composants dédiés.

Appliquer les règles par le backend. Le modèle peut interpréter une demande ou proposer une action, mais les autorisations, plafonds, séparations de privilèges et contrôles métier critiques doivent être vérifiés et appliqués de manière déterministe par le système qui l’entoure.

Tester l’extraction avant la mise en production. Les campagnes de sécurité doivent couvrir les demandes directes, les attaques multi-tours, l’obfuscation, les sorties structurées, les champs d’interface et les appels d’outils. Les résultats doivent être documentés et réévalués périodiquement.

Limiter l’impact d’une fuite. Le système doit être conçu selon le principe du moindre privilège afin que la divulgation complète du prompt ne permette aucune action dommageable supplémentaire. La sécurité doit reposer sur des contrôles indépendants du modèle : validation côté serveur, autorisation, quotas, journalisation, surveillance et intervention humaine pour les opérations sensibles.

→ Voir notre guide des architectures et vecteurs de risques IA pour resituer ce vecteur parmi les autres risques ciblant le LLM.

Questions fréquentes sur la fuite du prompt

Quel périmètre faut-il analyser pour un système d’IA ?

L’analyse doit couvrir le modèle, les données, les prompts, les composants RAG, les API, les outils connectés, l’infrastructure et les accès utilisateurs. Le périmètre doit être adapté aux usages et à la criticité du système.

Quels livrables attendre d’une analyse de risques IA ?

L’analyse doit permettre d’obtenir une cartographie du périmètre, une hiérarchisation des risques, les scénarios de menace prioritaires et un plan d’action précisant les mesures à mettre en œuvre, les responsables et les échéances.

Quand faut-il réévaluer les risques d’un système d’IA ?

Une nouvelle évaluation est recommandée en cas de changement de modèle, de données, de fournisseur, de connexion à un nouvel outil ou de transformation d’un assistant en agent autonome. Elle doit également être envisagée après un incident ou une évolution importante des usages.

Vérifier la résistance de vos systèmes à l’extraction de prompt

Nos experts en sécurité offensive testent la résistance de vos modèles face aux attaques par extraction, injection et contournement de garde-fous.

Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.