Document retiré d’un assistant RAG : vérifier les accès et les copies restantes

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une procédure sensible a été retirée de la base documentaire d’un assistant. Son lien ne fonctionne plus et une nouvelle question ne la cite pas. Peut-on conclure qu’elle n’est plus accessible ? Pas sans examiner les fragments indexés, les droits appliqués à la recherche et les réponses déjà conservées.

Le RAG enrichit les réponses d’un modèle avec des sources externes retrouvées au moment de la demande. OWASP identifie les contrôles d’accès insuffisants et les fuites entre contextes parmi les risques des systèmes de recherche vectorielle utilisés pour cet enrichissement. Source : OWASP LLM08:2025

Ce guide propose une vérification opérationnelle du retrait, indépendante du modèle et du moteur de recherche. Les exemples documentés concernent notamment Azure AI Search ; ils ne signifient pas qu’une intégration Seculogik est disponible. Les tests proposés utilisent un corpus synthétique, sans contenu d’incident ni donnée de production.

1. Définir exactement ce que signifie « retiré »

Notre recommandation : commencer par la décision attendue. Faut-il empêcher une personne de consulter un document, arrêter son utilisation par l’assistant, remplacer une version obsolète ou supprimer des données dans un périmètre défini ? Ces objectifs ne correspondent pas nécessairement aux mêmes opérations.

Identifiez la source, sa version, le propriétaire, les profils concernés et l’heure de la décision. Énumérez les points à contrôler : dépôt documentaire, recherche, contexte fourni au modèle, affichage des citations et réponses conservées. Fixez un responsable et un résultat observable pour chaque point pertinent.

Séparez également retrait de la recherche et conservation autorisée pour une enquête. Une archive protégée peut relever d’un besoin distinct ; elle ne doit pas redevenir une source consultable par défaut. Les règles de conservation et les éventuelles obligations d’effacement doivent être décidées par les responsables habilités.

Évitez une conclusion comme « le modèle a oublié ». La vérification porte ici sur l’accès aux contenus et leur réutilisation dans le système examiné. Si des données ont aussi servi à un entraînement ou à un autre traitement, ouvrez une analyse séparée de ce périmètre.

2. Relier la source à ses fragments et à ses versions

Microsoft explique que, dans certains modes d’alimentation d’Azure AI Search, supprimer la source avant la détection prévue peut laisser des documents orphelins dans l’index. La documentation distingue la suppression du contenu source et celle des documents de recherche, y compris les fragments. Ce comportement dépend du mode d’indexation utilisé. Source : Microsoft, supprimer des documents d’un index

Nous recommandons de demander un relevé des éléments dérivés associés à la source : fragments, versions antérieures et éventuels index secondaires. Vérifiez leur relation avec le document d’origine par des identifiants stables. Une recherche par titre ne suffit pas si le titre a changé ou si les fragments ne le contiennent pas.

Conservez l’état observé et le résultat des opérations autorisées, avec leurs heures. Contrôlez ensuite le résultat par les interfaces réellement utilisées par l’assistant. La réussite d’une demande de suppression n’est pas, à elle seule, une preuve de disparition sur tous les chemins.

Vérifiez enfin le cycle d’alimentation suivant. Une ancienne copie ou une source toujours présente peut-elle réintroduire le document ? Le critère de retrait doit couvrir la réapparition, pas seulement un instant où une recherche ne renvoie rien.

3. Contrôler l’autorisation avant que le contenu atteigne le modèle

OWASP recommande de vérifier les permissions à chaque requête, plutôt que de faire confiance à un contrôle appliqué sur la majorité des chemins. Pour notre vérification, cela implique de tester la recherche et l’accès direct aux objets avec le profil concerné, pas seulement l’interface visible. Source : OWASP, contrôle d’autorisation

L’exemple Microsoft de filtrage de sécurité est instructif : une chaîne représentant un utilisateur ou un groupe sert à filtrer les résultats ; elle n’authentifie pas cette identité. La documentation précise aussi que masquer un champ dans la réponse n’est pas un mécanisme de sécurité du contenu. Source : Microsoft, filtres de sécurité dans Azure AI Search

Notre recommandation : vérifier quelle identité prend réellement part à la décision d’accès et d’où proviennent ses droits. Un filtre affichant le bon nom ne suffit pas. Faites confirmer le contrôle par une personne habilitée à examiner le comportement du service, sans copier de secrets dans le dossier.

Le refus doit intervenir avant l’introduction d’un fragment interdit dans le contexte du modèle. Une consigne demandant au modèle de ne pas révéler ce fragment ne remplace pas l’autorisation. Contrôlez aussi titres, extraits et citations : retirer le texte principal ne doit pas laisser une autre réponse exposer l’information protégée.

4. Examiner les caches et les conversations existantes

La fiche RAG d’OWASP recommande d’isoler les caches selon les droits et de les invalider lorsque les sources ou leurs permissions changent. Elle rappelle que la suppression d’une source doit être propagée aux données dérivées concernées. Source : OWASP, sécurité du RAG

Nous recommandons de comparer une question jamais posée et une question ayant déjà produit une réponse. Testez aussi une conversation ouverte avant le retrait et une nouvelle conversation. Enregistrez si la réponse vient d’une nouvelle recherche, d’un cache ou d’un historique, lorsque le système permet de l’établir.

Traitez les réponses déjà visibles comme des objets à examiner séparément. Le retrait d’une source n’efface pas, par raisonnement, une copie exportée ou un message antérieur. Définissez ce qui doit rester consultable, par qui et avec quel avertissement de version, puis faites appliquer cette décision dans le périmètre maîtrisé.

Si le chemin de production d’une réponse n’est pas observable, notez cette limite. Un texte qui ressemble au document ne permet pas, seul, de déterminer s’il provient d’une recherche récente, d’un historique ou d’une information indépendante.

5. Construire un essai qui peut réellement échouer

Notre recommandation : préparer un document fictif contenant un détail distinctif sans valeur sensible, ainsi qu’un document témoin qui doit rester disponible. Définissez les résultats attendus avant le test. Un essai où aucun profil ne retrouve rien pourrait simplement révéler une panne de recherche.

Avec des identités de test autorisées, couvrez les situations suivantes :

1. Avant le retrait, le profil prévu retrouve la source synthétique et son détail distinctif.
2. Après le retrait ou la révocation, ce profil ne reçoit plus les fragments interdits, même en demandant leur détail autrement.
3. Le document témoin reste accessible à un profil habilité : le contrôle ne s’appuie pas sur une panne générale.
4. Une question déjà utilisée et une conversation antérieure ne réexposent pas le contenu hors du périmètre décidé.
5. Le cycle d’alimentation suivant ne réintroduit pas la version retirée.

Restez dans le système et le corpus autorisés pour l’exercice. Ne cherchez pas à obtenir les véritables documents d’une autre équipe afin de tester l’isolation. Un marqueur synthétique permet de constater un résultat sans provoquer une nouvelle divulgation.

Plusieurs formulations peuvent aider à explorer un comportement variable, mais elles ne constituent pas une preuve universelle d’absence de fuite. Associez les essais aux observations de recherche, aux décisions d’autorisation et aux contrôles du cycle de vie disponibles.

6. Clore sur des preuves de retrait, pas sur une réponse rassurante

Exemple entièrement fictif : une nouvelle conversation ne cite plus la procédure retirée, mais une question déjà utilisée renvoie une ancienne réponse conservée. Le constat est un retrait incomplet sur le chemin de réutilisation ; il ne permet pas de déclarer que tous les utilisateurs ont reçu le contenu.

Nous recommandons de conserver dans le dossier le périmètre, les profils de test, la source et ses dérivés identifiés, les opérations réalisées et les résultats avant et après. Préférez les références et les traces nécessaires à la copie intégrale de contenus sensibles. Faites apparaître les chemins non observables et les exceptions restantes.

Si un résultat interdit est retrouvé, faites autoriser une mesure proportionnée : restriction du chemin affecté, correction de la propagation ou traitement des copies concernées. Préservez les preuves utiles avant les changements, sans maintenir une exposition urgente pour parfaire la collecte.

Le retrait est vérifié lorsque les contrôles convenus sont satisfaits dans le périmètre annoncé. Nos ressources gratuites d’investigation peuvent aider à structurer ce dossier, avec une distinction claire entre décision, opération réussie et effet effectivement observé.