Chaque prompt envoyé à un modèle hébergé quitte votre environnement. S’il contient une clé d’API, un mot de passe ou les données personnelles d’un client, cette information se trouve désormais dans les systèmes de quelqu’un d’autre et possiblement dans les journaux des deux côtés. La détection d’informations sensibles consiste à repérer ce contenu avant l’envoi du prompt.
Comment les données sensibles entrent dans les prompts
Rarement à dessein. Les voies habituelles :
- Journaux et traces de pile collés qui comprennent des tokens, des chaînes de connexion ou des cookies de session.
- Fichiers de configuration partagés pour déboguer :
.env, YAML, Terraform. - Du code avec un identifiant codé en dur.
- Des fiches clients dans des tickets de support, des e-mails et des transcriptions de chat.
- Des documents récupérés qui contiennent plus que ce dont la question a besoin.
- Des fichiers de prompts dans un dépôt où quelqu’un a testé avec une vraie clé.
- Des résultats d’outils dans une boucle d’agent, transmis au modèle sans filtrage.
Deux catégories, deux types de risque
Les secrets donnent un accès : clés d’API, tokens, mots de passe, clés privées, chaînes de connexion. Un secret divulgué peut être utilisé immédiatement. La réponse est de le révoquer et de le renouveler.
Les données personnelles (PII) identifient des personnes : noms, adresses e-mail, numéros de téléphone, adresses postales, numéros de carte de paiement, numéros d’identité nationaux. Les envoyer peut enfreindre vos engagements de confidentialité ou la loi, et elles ne peuvent pas être renouvelées.
Comment fonctionne la détection
Les détecteurs combinent plusieurs méthodes, car chacune a des angles morts.
Formats connus. De nombreux fournisseurs émettent des clés avec un préfixe et une longueur reconnaissables. On peut les repérer avec une grande confiance.
Motifs de contexte. Une affectation comme password = "..." ou api_key: ... désigne la valeur comme un identifiant, quel que soit son format.
Entropie. Les chaînes aléatoires ont une forte entropie de Shannon. Une valeur longue et à forte entropie à côté d’un mot comme « token » ou « secret » est probablement un identifiant, même dans un format inconnu.
Identifiants structurés. Les adresses e-mail, les numéros de téléphone et de carte suivent des motifs. Les numéros de carte peuvent être confirmés par une somme de contrôle.
Reconnaissance d’entités nommées. Des modèles statistiques trouvent des noms, des organisations et des lieux qui n’ont pas de motif fixe. Plus de couverture, plus de faux positifs, et il faut un modèle.
L’analyseur de sécurité de prompts PromptFlowEngine utilise les quatre premières. Il est déterministe et s’exécute localement ; le texte examiné à la recherche de secrets n’est donc envoyé nulle part pour être vérifié.
Signalez des emplacements, jamais des valeurs
Un détecteur qui affiche le secret qu’il a trouvé a créé une seconde copie du secret, dans un journal ou un terminal. Un analyseur bien conçu ne renvoie que la catégorie et la position :
{
"hasSensitiveData": true,
"countsByCategory": { "api_key": 1, "email": 1 },
"matches": [
{ "category": "api_key", "start": 118, "end": 164 },
{ "category": "email", "start": 176, "end": 196 }
]
}
C’est la forme que PromptFlowEngine renvoie dans toutes ses interfaces. Voir la règle des données sensibles pour un exemple concret.
Masquage
Le masquage remplace chaque valeur détectée par un marqueur qui conserve le sens du texte environnant.
Before: Connect with postgres://admin:hunter2@db.internal:5432/app
After: Connect with [REDACTED_CONNECTION_STRING]
Les marqueurs typés comme [REDACTED_API_KEY] valent mieux qu’une rangée d’astérisques, car le modèle sait encore de quel genre de chose il s’agissait et peut raisonner dessus (« la chaîne de connexion semble mal formée ») sans la voir.
Pour les données personnelles auxquelles la tâche doit faire référence, utilisez des pseudonymes cohérents au sein d’une requête : chaque occurrence d’un e-mail devient [EMAIL_1], l’adresse suivante [EMAIL_2]. Le modèle peut alors distinguer les personnes, et votre application peut réassocier les marqueurs après la réponse.
Où placer le contrôle
Détectez le plus tôt possible, et à plusieurs endroits.
| Où | Ce qu’il intercepte |
|---|---|
| Dans l’éditeur ou la zone de chat | Un collage, avant l’envoi |
| Dans le code de l’application, avant l’appel d’API | Données d’utilisateurs, fiches et récupération |
| Entre les étapes de l’agent | Résultats d’outils sur le point d’entrer dans le contexte |
| En CI, sur les fichiers de prompts | Identifiants validés dans un dépôt |
| Avant la journalisation | Contenu sur le point d’être stocké |
L’extension Chrome avertit quand un brouillon dans ChatGPT, Claude ou Gemini contient un secret, et peut le masquer sur votre appareil. L’extension VS Code exécute une protection de la vie privée avant l’envoi d’un prompt au chat, avec des modes strict, masquage et avertissement. En CI, la barrière de contrôle échoue par défaut sur tout constat critique ; une clé validée arrête donc le build.
Choix de politique : bloquer, masquer ou avertir
- Bloquer quand un secret ne doit jamais être envoyé. Le plus sûr, le plus perturbant.
- Masquer par défaut. Le prompt part sans les valeurs sensibles.
- Avertir quand une personne doit décider, par exemple pour un possible faux positif dans du code.
Quel que soit votre choix, appliquez la détection des secrets en local. Un contrôle qui envoie le texte à un service distant pour savoir s’il est sûr de l’envoyer va à l’encontre de son but.
Limites à connaître
- Faux négatifs. Un secret dans un format inhabituel, ou une donnée personnelle sans motif comme la description d’une personne, peut passer. La détection réduit le risque ; elle ne certifie pas qu’un prompt est propre.
- Faux positifs. Les hachages, les UUID et les données de test peuvent ressembler à des secrets. Mettez en liste d’autorisation les valeurs sûres connues au lieu de désactiver le contrôle.
- Images et fichiers. Les analyseurs de texte ne lisent pas les captures d’écran ni les PDF s’ils n’ont pas été convertis d’abord.
- Contexte. Un nom est public dans un cadre et confidentiel dans un autre. Seule votre politique peut en décider.
Au-delà de la détection : envoyez moins
Le contrôle le plus fiable est de ne pas inclure les données du tout.
- Passez un identifiant et laissez un outil rechercher la fiche, de sorte que le modèle ne voie jamais des champs dont il n’a pas besoin.
- Retirez des champs avant de construire le prompt.
- Gardez les identifiants dans votre application et donnez-les directement aux outils. Un modèle n’a jamais besoin de votre clé d’API pour demander à un outil d’appeler une API.
- Utilisez des données de test dans les exemples et les fichiers de prompts.
Si un secret a déjà été envoyé
- Révoquez-le et renouvelez-le immédiatement. Considérez-le comme compromis.
- Vérifiez dans les journaux d’accès s’il a été utilisé.
- Retirez-le de l’historique du dépôt et des fichiers de prompts.
- Ajoutez un contrôle pour que la même voie soit interceptée la prochaine fois.
Pour le modèle de menaces environnant, voir la sécurité des prompts. Pour les attaques qui tentent d’extraire des données une fois qu’elles sont dans le contexte, voir l’injection de prompt.