Assistants IA et droits d’accès aux documents : qui peut recevoir la réponse ?

Un assistant fondé sur la recherche documentaire travaille en deux temps. Un indexeur lit les documents de l’entreprise, les découpe en passages et les stocke dans un index de recherche. Quand quelqu’un pose une question, l’assistant cherche dans cet index, transmet les meilleurs passages à un modèle de langage et renvoie la réponse du modèle.

L’indexeur tourne en général sous un compte de service qui a accès en lecture à tout, parce que c’est le moyen le plus simple d’obtenir un index complet. Si rien d’autre n’est fait, l’assistant répond alors à chaque salarié avec les droits de ce compte de service. Une fenêtre de discussion contourne les droits des dossiers : la liste des salaires ou le contrat d’un client ne sont plus qu’à une question bien tournée.

C’est le cas classique de l’« adjoint désorienté » (confused deputy) : un composant aux droits étendus agit pour un utilisateur aux droits restreints et ne vérifie pas la différence. Un accès étendu en lecture pour l’indexeur est acceptable. Répondre avec cet accès ne l’est pas.

La règle qui rend un assistant sûr est courte : un passage que l’utilisateur qui pose la question n’a pas le droit de lire ne doit jamais entrer dans le contexte du modèle.

• Stockez les droits avec chaque passage. Chaque passage indexé porte l’identifiant de son document source, les utilisateurs et les groupes autorisés à le lire, les éventuels refus explicites, et un identifiant de locataire (tenant) quand plusieurs clients partagent le système.
• Prenez l’identité dans la session authentifiée. Le service de recherche reçoit l’identité vérifiée de l’utilisateur à partir du jeton de connexion. Il n’accepte jamais un identifiant d’utilisateur venu d’un champ de formulaire, du prompt ou d’arguments produits par le modèle lui-même.
• Filtrez à l’intérieur de la recherche. La condition de droits fait partie de la requête de recherche, de sorte que l’index ne renvoie que les passages que l’utilisateur peut lire. Filtrer après coup une liste des dix premiers résultats donne de moins bonnes réponses, car les passages autorisés classés onzièmes et au-delà ne sont jamais pris en compte.
• Ne filtrez jamais après le modèle. Demander au modèle d’« omettre les contenus confidentiels », ou analyser sa réponse, ce n’est pas du contrôle d’accès. Une fois le texte dans le contexte, une paraphrase, un résumé ou un simple chiffre peut le faire sortir.

Les métadonnées fuient aussi. Un titre de document dans une liste de sources, un décompte (« J’ai trouvé 3 documents que je ne peux pas vous montrer ») ou un chemin de fichier révèle que quelque chose existe. Appliquez le même filtre aux citations, aux suggestions et à la saisie semi-automatique.

L’index contient une copie des droits, et les copies vieillissent. Trois détails décident si elles restent justes.

Premièrement, un changement de droits ne modifie pas le document. Un indexeur qui ne relit que les fichiers dont le contenu ou la date de modification a changé passera à côté. Les droits ont besoin de leur propre synchronisation : des événements de changement émis par le système source quand ils existent, et une comparaison complète régulière comme filet de sécurité.

Deuxièmement, stockez des groupes, pas des listes de membres développées. Si un passage est marqué « lisible par le groupe Finance » et que les appartenances de l’utilisateur aux groupes sont lues auprès du fournisseur d’identité au moment où la question est posée, retirer une personne de Finance prend effet immédiatement, sans réindexation. Si l’index stocke les noms de tous les membres de Finance, chaque mouvement de personnel oblige à réécrire des milliers d’entrées.

Troisièmement, les droits sont souvent hérités. Déplacer un document dans un autre dossier, ou modifier les droits d’un dossier, change les droits effectifs de tout ce qui se trouve en dessous. La synchronisation doit calculer les droits effectifs, pas seulement ceux qui sont posés sur le fichier lui-même. Les documents supprimés doivent quitter l’index, et l’équipe a besoin d’une règle pour le partage « toute personne disposant du lien » : le choix sûr par défaut est de considérer ces documents comme lisibles uniquement par les personnes nommées explicitement.

Pour les sources les plus sensibles, ajoutez une seconde vérification : avant que les meilleurs passages partent vers le modèle, demandez au système source si cet utilisateur peut lire ces documents maintenant. Cela coûte un peu de latence et supprime la dépendance à la copie.

Une réponse est tirée de documents, elle hérite donc de leurs restrictions. La règle simple : une réponse ne peut être réutilisée que pour un utilisateur dont les droits couvrent toutes les sources à partir desquelles elle a été construite.

L’historique des conversations est plus subtil. Un utilisateur qui a lu une réponse la semaine dernière l’a vue, tout comme il aurait pu télécharger le fichier. Ce qui ne doit pas arriver, c’est que d’anciens échanges continuent d’alimenter de nouvelles réponses en texte à accès restreint, ou qu’une fonction de mémoire l’emporte dans des sessions ultérieures. Stockez avec chaque réponse les identifiants des documents sources, pour pouvoir les revérifier.

En combien de temps une révocation doit-elle prendre effet ? Fixez un chiffre et écrivez-le. Les chiffres ci-dessous sont une comparaison de conceptions à titre d’illustration, pas des mesures : la durée la plus longue, en minutes, pendant laquelle un droit retiré pourrait encore produire une réponse, selon quatre approches.

Un passage nocturne, c’est jusqu’à 24 heures (24 x 60 = 1 440 minutes), ce qui est rarement acceptable pour une personne qui quitte l’entreprise. Un objectif raisonnable combine les deux dernières approches : appartenance aux groupes et état du compte vérifiés à chaque question, changements au niveau des documents appliqués en quelques minutes.

La gestion des droits dans un assistant IA est un contrôle de sécurité, et elle a besoin de tests qui tournent automatiquement, après chaque déploiement et à intervalles planifiés.

1. Créez deux utilisateurs de test aux droits différents, par exemple l’un dans le groupe Finance et l’autre en dehors.
2. Placez des documents canaris dans des emplacements à accès restreint. Chacun contient un fait inventé et une chaîne unique qui n’apparaît nulle part ailleurs, par exemple un code de projet imaginaire.
3. Posez aux deux utilisateurs les mêmes questions sur les faits canaris, en formulation directe et indirecte. L’utilisateur autorisé doit obtenir la réponse avec sa source. L’autre ne doit rien obtenir : ni fait, ni titre, ni indice qu’un document existe.
4. Cherchez les chaînes canaris dans les réponses, les citations et les suggestions du second utilisateur. Une seule occurrence fait échouer le build.
5. Testez la révocation : accordez l’accès, posez la question, retirez l’accès, puis posez la question à plusieurs reprises et mesurez pendant combien de temps la réponse revient encore. Comparez le résultat avec votre objectif.
6. Répétez la question dans la même conversation après la révocation, puis depuis un second compte juste après le premier, pour éprouver l’historique et les caches.
7. Quand plusieurs clients partagent le système, lancez les mêmes tests entre locataires, avec un canari par client.

Entre clients, un filtre sur un identifiant de locataire est le minimum, et il doit être appliqué par le service de recherche lui-même, pas choisi par le code appelant. Un index séparé par client est la conception la plus solide, car un filtre oublié ne renvoie alors rien au lieu de tout renvoyer. Le même raisonnement vaut pour un portail client qui propose une recherche ou un assistant, et il a sa place dans la revue régulière de la sécurité et des sauvegardes.