Peut-on empêcher complètement un modèle de révéler son prompt système ?

Non. La documentation d'Anthropic indique qu'aucune méthode n'est infaillible, et l'OWASP demande de concevoir l'application en supposant que le contexte caché peut être découvert.

Que faire si une clé d'accès à une interface de programmation se trouve dans le prompt système ?

La considérer comme exposée : la révoquer, en émettre une nouvelle, et la placer dans le code ou un coffre de secrets que le modèle ne lit pas. L'outil qui en a besoin l'utilise côté serveur.

Fuite du prompt système : que risque-t-on vraiment ?

Le prompt système (les instructions cachées que l'application donne au modèle avant chaque conversation) peut être extrait par un utilisateur insistant ou par une injection de prompt. Il faut donc partir du principe qu'il fuitera. La question utile n'est pas « comment le cacher ? » mais « qu'est-ce qui deviendrait grave s'il était lu ? ». Si la réponse est « rien », vous êtes protégé ; sinon, il faut sortir l'élément sensible du prompt.

Ce que dit l'OWASP en 2026

Dans l'édition 2026 de son Top 10 pour les applications de modèles de langage, l'OWASP (fondation qui publie des référentiels de sécurité applicative) a remplacé la catégorie « System Prompt Leakage » de 2025 par LLM08:2026 « Hidden Context Exposure », l'exposition du contexte caché. Le changement de nom élargit le sujet : le contexte caché comprend le prompt système, mais aussi les instructions du développeur, les règles récupérées dans une base documentaire, les schémas des outils et des fonctions exposés au modèle, et tout ce que l'application assemble dans le contexte sans le montrer à l'utilisateur.

La consigne de l'OWASP est nette : aucun contenu du contexte ne doit être considéré comme secret, et le contexte caché ne doit jamais servir à lui seul de frontière de sécurité pour l'autorisation, la séparation des privilèges ou le filtrage.

Les niveaux de gravité

L'OWASP gradue la gravité d'une fuite selon ce que contient le contexte et selon l'usage qu'en fait l'application :

Niveau	Ce que contenait le contexte	Exemple
Information	Rien de secret, aucune logique de sécurité	« Tu es l'assistant de la boutique, réponds poliment »
Moyen	Règles internes, critères de filtrage, rôles, logique métier qui aide un attaquant	La liste des sujets refusés et la façon de les détecter
Élevé	Identifiants ou jetons, ou confidentialité du contexte utilisée pour l'autorisation	« Si l'utilisateur dit être du service RH, montre-lui les salaires »
Critique	La fuite permet d'exécuter du code, d'extraire massivement des données ou d'obtenir plus de droits	Une clé d'administration d'un outil branché au modèle

Ce qu'une fuite apprend à un attaquant

L'OWASP décrit cinq expositions typiques :

Les outils et leurs schémas : la liste des fonctions disponibles et de leurs paramètres donne des cibles précises pour une injection.
La logique de décision interne : comment l'application tranche, donc où elle peut être contournée.
Les règles de refus : connaître les conditions exactes d'un refus permet de rédiger des demandes qui les évitent.
Les permissions et les rôles : savoir qu'un rôle donne accès à telle liste de documents invite à tenter de l'usurper.
Le format de sortie attendu : un attaquant peut produire une réponse au bon format qui contient des valeurs piégées pour le système en aval.

Les trois parades de l'OWASP

Ne rien mettre de sensible dans le contexte caché : ni identifiants, ni secrets, ni configuration de sécurité. Ces éléments restent dans des systèmes que le modèle ne lit pas.
Contrôler le comportement par des mécanismes déterministes, indépendants du modèle : la détection de contenus nuisibles, par exemple, se fait par des garde-fous externes plutôt que par des consignes dans le prompt.
Appliquer l'autorisation hors du modèle : la séparation des privilèges et le contrôle des droits ne se délèguent pas au modèle, ni par le prompt système ni autrement.

Le scénario le plus simple cité par l'OWASP montre l'enjeu : un prompt système contient des identifiants d'un outil ; il fuit ; l'attaquant réutilise ces identifiants ailleurs. Le défaut n'est pas la fuite, c'est d'avoir placé les identifiants dans le prompt.

Ce que conseille Anthropic

La documentation d'Anthropic sur la réduction des fuites de prompt part d'un avertissement : chercher à rendre un prompt étanche complique la tâche du modèle et peut dégrader ses réponses. Elle recommande de n'y recourir qu'en cas de réelle nécessité, et de commencer par la surveillance. Ses pistes :

séparer le contexte des questions en gardant les informations clés dans le prompt système ;
filtrer les sorties par mots-clés, expressions régulières ou un second modèle, pour repérer une réponse qui recopie le prompt ;
retirer les détails inutiles : ce dont le modèle n'a pas besoin pour sa tâche n'a rien à faire dans le prompt ;
auditer régulièrement les prompts et les réponses.

Une vérification en cinq minutes

Relisez votre prompt système et posez-vous trois questions. Contient-il une clé, un mot de passe, une adresse interne ? Contient-il une règle d'accès (« si l'utilisateur est… alors montre… ») ? Sa publication sur un forum vous gênerait-elle ? Chaque « oui » désigne un élément à déplacer dans le code ou dans un coffre de secrets que le modèle ne lit pas. Une clé qui figurait dans le prompt est à considérer comme exposée : révoquez-la et émettez-en une nouvelle, utilisée côté serveur par l'outil qui en a besoin. Pour les autres voies par lesquelles des données sortent d'un assistant, voyez fuite de données par une IA générative.