Les quatre chemins de fuite

  1. Ce que vous donnez au modèle. Prompts, fichiers joints, captures d’écran, extraits de base de données : tout ce qui est envoyé à un service d’IA sort de votre périmètre et suit les conditions de ce service.
  2. Ce que le modèle restitue. Un modèle peut répéter des informations présentes dans son contexte — instructions cachées, documents d’autres utilisateurs, résultats d’outils. L’OWASP traite ce risque dans LLM02 (divulgation d’informations sensibles) et LLM08 (exposition du contexte caché).
  3. Ce que le code généré contient. Clés écrites en dur, fichier .env versionné, journaux trop bavards, clé utilisée côté navigateur : l’assistant reproduit des schémas courants, y compris les mauvais.
  4. Ce que les outils laissent sortir. Un agent qui dispose d’un accès réseau peut être amené, par injection, à envoyer des données vers l’extérieur ; une image Markdown suffit parfois.

Secrets : les règles de base

  • Jamais de secret dans un prompt, une conversation, une capture, un ticket ou un message.
  • Jamais de secret dans le code ni dans le dépôt, même privé : variables d’environnement côté serveur ou coffre à secrets, et un fichier .env.example qui liste les noms sans les valeurs.
  • Jamais de secret côté navigateur : une clé présente dans le JavaScript d’une page est publique.
  • Une clé par usage, avec les droits minimaux, et des clés de test pour le développement.
  • Une détection de secrets avant chaque commit. La protection « push protection » de GitHub, par exemple, bloque l’envoi d’un commit qui contient un secret reconnu.
  • En cas de doute, révoquer et remplacer : supprimer un secret de l’historique ne suffit pas, il a pu être copié.

Pour vérifier un dossier sans rien envoyer en ligne, l’outil gratuit Secret Scanner Local de la bibliothèque AXDIA analyse vos fichiers directement dans le navigateur.

Le piège des clés d’API côté navigateur

Demander à un assistant « une page qui appelle l’API d’un modèle d’IA » produit souvent un code qui place la clé dans le JavaScript de la page ou dans l’application mobile. Tout visiteur peut alors la lire et l’utiliser à vos frais. La bonne architecture passe par votre serveur : le navigateur appelle votre API, qui vérifie l’utilisateur, applique un quota et appelle le fournisseur avec la clé conservée côté serveur. Précisez-le dans la mission, et vérifiez dans le code livré qu’aucune clé n’apparaît dans les fichiers servis au navigateur.

Données personnelles et données métier

La CNIL publie des fiches pratiques sur la conformité des systèmes d’IA au RGPD : définir une finalité, choisir une base légale, réaliser une analyse d’impact si nécessaire, informer les personnes, faciliter l’exercice de leurs droits, garantir la sécurité. Appliquées au quotidien, elles conduisent à quelques règles simples : ne transmettre à un outil d’IA que les données nécessaires à la tâche ; préférer des données fictives ou pseudonymisées pour les tests et les démonstrations ; vérifier, avant d’adopter un outil, ce que le fournisseur fait des données — conservation, réutilisation pour l’entraînement, lieu d’hébergement, sous-traitants.

Pour les systèmes qui entraînent ou alimentent un modèle avec vos données, la CISA, la NSA et le FBI recommandent en 2025 de suivre la provenance des données, d’en contrôler l’intégrité et de les chiffrer, du stockage à l’utilisation.

Journaux et traces : la fuite oubliée

Pour déboguer un chatbot ou un agent, on enregistre volontiers les prompts et les réponses complètes. Ces journaux deviennent alors une copie de toutes les conversations — données clients, pièces jointes, parfois des secrets — souvent moins protégée que la base principale. Masquez les secrets et les données personnelles avant écriture, limitez l’accès et la durée de conservation, et gardez la trace des actions plutôt que le contenu intégral. L’OWASP Top 10:2025 consacre sa catégorie A09 à la journalisation et à l’alerte : il faut tracer les événements de sécurité sans exposer les données.

Que faire si un secret a fuité

  1. Révoquer ou faire tourner immédiatement la clé, avant toute autre action.
  2. Vérifier dans les journaux du fournisseur si la clé a été utilisée depuis la fuite.
  3. Remplacer la clé partout où elle sert, puis retirer le secret du code et de l’historique.
  4. Chercher la cause — fichier versionné, journal, conversation — et ajouter un contrôle qui l’empêche de se reproduire.
  5. Si des données personnelles ont pu être atteintes, évaluer la violation : le RGPD impose de la notifier à la CNIL dans les 72 heures lorsqu’elle présente un risque pour les personnes.

Ce que Prompt OS ajoute à la mission

« Protection des secrets » est le garde-fou que Prompt OS applique à toutes les missions. Il ajoute au prompt final : ne jamais afficher, journaliser, copier dans un prompt ni committer un secret ; utiliser des variables d’environnement ; fournir un .env.example sans valeur ; scanner le dépôt avant validation. Les garde-fous « Données personnelles », « Journaux sans données sensibles » et « Prévention de l’exfiltration » complètent la mission dès qu’elle touche des clients, des comptes ou un agent. Sans protection des secrets, l’indicateur de Prompt OS ne dépasse jamais le niveau « Faible ».

Conclusion

Avec l’IA, la plupart des fuites ne viennent pas d’une attaque sophistiquée, mais d’un copier-coller. Quelques règles strictes — secrets hors de portée du modèle, données minimisées, journaux maîtrisés, révocation immédiate — évitent l’essentiel des incidents.