Comment les applications LLM divulguent-elles des informations sensibles, et comment l'empêcher ?
Réponse courte
Les applis LLM divulguent des données de plusieurs façons : le modèle mémorise et restitue des données d'entraînement ou de fine-tuning sensibles, le system prompt (qui peut contenir des secrets ou de la logique) est extrait, des documents RAG récupérés exposent des données que l'utilisateur ne devrait pas voir, et le contexte d'un utilisateur ou d'une session déborde sur un autre. La prévention passe par la minimisation des données avant l'entraînement, ne jamais mettre de secrets dans les prompts, appliquer l'autorisation par utilisateur à la récupération, le filtrage des sorties et la rédaction de PII, et l'isolement par locataire.
La divulgation d'informations sensibles est régulièrement l'un des principaux risques LLM parce que les modèles touchent beaucoup de données et présentent plusieurs voies de fuite distinctes.
Comment les fuites se produisent
- Mémorisation des données d'entraînement. Les modèles peuvent mémoriser et restituer mot pour mot des fragments de leurs données d'entraînement ou de fine-tuning — PII, identifiants, documents internes — lorsqu'on les sollicite de la bonne manière. C'est un risque au niveau du modèle, difficile à défaire après l'entraînement.
- Fuite de system prompt. Les applications insèrent souvent des instructions, de la logique métier et parfois des secrets dans le system prompt. Les attaquants l'extraient via l'injection. Considérez le system prompt comme lisible par les utilisateurs.
- Récupération sur-permissionnée. En RAG, si le magasin de vecteurs renvoie des documents sans vérifier l'autorisation de l'utilisateur demandeur, le modèle résumera volontiers des données qu'il n'était jamais autorisé à voir.
- Débordement entre sessions / entre locataires. Une mauvaise isolation, des caches partagés ou un contexte réutilisé peuvent faire fuir les données d'un utilisateur dans la réponse d'un autre.
Prévention
- Minimisation des données avant l'entraînement et le fine-tuning ; expurgez les PII et secrets des corpus.
- Ne jamais mettre de secrets dans les prompts. Gardez clés et identifiants dans un gestionnaire de secrets, récupérés côté serveur avec le moindre privilège.
- Autorisation au moment de la récupération. Filtrez le magasin de vecteurs selon les permissions de l'utilisateur demandeur, pas après coup.
- Filtrage des sorties et rédaction de PII sur les réponses.
- Isolement par locataire du contexte, de la mémoire et des caches.
Ce que recherchent les recruteurs
Un candidat qui énumère plusieurs voies de fuite — pas seulement « le modèle dit des choses secrètes » — et associe chacune à un contrôle concret, en particulier l'autorisation par utilisateur sur le RAG et le maintien des secrets hors des prompts.
Questions de suivi probables
- Pourquoi mettre une clé API dans le system prompt est-il une mauvaise idée ?
- Comment la mémorisation des données d'entraînement permet-elle à un attaquant d'extraire des PII ?
- Comment appliquer l'autorisation dans un pipeline RAG pour que les utilisateurs ne récupèrent que les documents autorisés ?