Aller au contenu

ExpertLeçon 4 sur 511 min de lecture

Le RAG qui en dit trop

Un cours de l'Académie : Sécuriser une application IA, au-delà de l'injection

Aller au quiz ↓

Brancher un assistant sur les documents d'une organisation est l'usage le plus répandu en entreprise. C'est aussi là que se produisent les fuites les plus banales et les plus graves : un salarié qui obtient, par une question anodine, un document qu'il n'aurait jamais pu ouvrir lui-même.

L'index commun, ou la fuite par construction

Le schéma naïf : tous les documents dans une même base vectorielle, et une consigne au modèle (« ne révèle pas les documents RH aux non-managers »). La recherche ramène les passages les plus proches de la question, quels que soient les droits de celui qui la pose, et le modèle les a sous les yeux. La consigne n'y peut rien : l'information est déjà dans le contexte.

La règle : filtrer avant de chercher

  • Chaque morceau indexé porte ses droits d'accès en métadonnées : qui peut le lire, d'après le système d'origine.
  • La recherche est filtrée selon l'identité de l'utilisateur avant le calcul de proximité. Ce qu'il ne peut pas lire n'est jamais remonté, donc jamais vu par le modèle.
  • Les droits se synchronisent : un document retiré à quelqu'un dans l'outil d'origine doit disparaître de ses résultats, et un document supprimé doit sortir de l'index. L'oubli de cette synchronisation est une cause fréquente de fuite durable.
  • Un client, un espace : pour un service utilisé par plusieurs organisations, des index séparés ou un filtrage strict par client, jamais une base commune filtrée par le modèle.

Les embeddings ne sont pas de l'anonymisation

On entend parfois que les vecteurs stockés sont « illisibles ». Des travaux de recherche ont montré dès 2023 qu'on peut reconstruire une grande partie du texte d'origine à partir de ses embeddings. Une base vectorielle qui contient des données personnelles se protège donc comme la base de documents elle-même.

Le prompt système n'est pas un coffre

Partez du principe que votre prompt système finira par être lu : des utilisateurs patients parviennent presque toujours à le faire réciter. N'y mettez ni clé d'accès, ni règle de sécurité dont la connaissance permettrait de la contourner, ni information confidentielle. Ce qui doit rester secret reste côté serveur.

Analogie. Une bibliothèque d'entreprise où tous les dossiers, y compris ceux de la direction, sont rangés sur les mêmes étagères, avec un panneau « dossiers confidentiels : merci de ne pas lire ». Le bibliothécaire (le modèle) est poli et respecte le panneau la plupart du temps. La bonne bibliothèque, elle, range les dossiers confidentiels dans une salle que seuls certains badges ouvrent.

À retenir

  • Un index commun assorti d'une consigne de discrétion fuit par construction.
  • Filtrer la recherche selon les droits de l'utilisateur, avant le calcul de proximité, et synchroniser ces droits.
  • Les embeddings se protègent comme les documents : ils ne sont pas anonymes.
  • Le prompt système finira lu : rien de secret dedans.

Les notions clés

Validez la leçon

Un quiz de 4 questions : 3 bonnes réponses suffisent, et un exercice pour pratiquer. Il s'ouvre dans l'Académie, sur cette même leçon.

Faire le quiz et valider la leçon Gratuit. Avec un compte, votre progression est enregistrée et mène à l'attestation du cours.

Le cours : Sécuriser une application IA, au-delà de l'injection

  1. Cartographier les menaces : la liste de l'OWASP11 min
  2. La sortie du modèle est une entrée non fiable11 min
  3. Les pièces que vous n'avez pas écrites12 min
  4. Le RAG qui en dit trop11 min
  5. Bornes, abus et tests d'attaque11 min

Toute l'Académie →Le glossaire de l'IA