Jak nie dopuścić, by asystent RAG ujawniał dokumenty, do których ktoś nie ma dostępu

Gdzie gubią się uprawnienia

W systemie źródłowym dokument i jego lista dostępu są przechowywane razem. Pipeline RAG kopiuje tekst, dzieli go na chunki, liczy embeddingi i zapisuje wszystko gdzie indziej. Każdy z tych kroków może zerwać powiązanie między chunkiem a osobami, które mogą go czytać. Słabe punkty są przewidywalne:

• Ingestia działa na koncie serwisowym, które może czytać wszystko, a indeks zapisuje tekst bez listy dostępu
• Chunki dostają uprawnienia, jakie dokument miał w chwili indeksowania, a późniejsze zmiany w źródle nigdy do nich nie docierają
• Aplikacja odpytuje indeks własnymi poświadczeniami i nigdy nie przekazuje tożsamości użytkownika
• Członkostwo w grupach jest ustalane raz i trzymane w cache, więc ktoś, kto odszedł z zespołu, nadal ma dostęp
• Logi, cache i zbiory do ewaluacji przechowują zastrzeżony tekst poza jakąkolwiek kontrolą dostępu

OWASP wymienia nieuprawniony dostęp i wycieki między grupami korzystającymi ze wspólnej bazy wektorowej wśród głównych słabości systemów opartych na embeddingach. Zaleca wyszukiwanie uwzględniające uprawnienia i dane podzielone według użytkowników lub grup.

Filtrowanie na etapie wyszukiwania

Zasada projektowa jest krótka: samo zapytanie zwraca tylko chunki, które użytkownik może czytać, więc zastrzeżony tekst nigdy nie trafia do promptu. Wyszukiwarki realizują to różnie, a szczegóły decydują o tym, co trzeba przetestować.

Document-level security w Elasticsearch przypina zapytanie do roli, a to zapytanie można parametryzować atrybutami bieżącego użytkownika. Gdy ktoś ma kilka ról, zapytania ról łączone są przez OR, więc jedna szeroka rola znosi wąskie. Azure AI Search oferuje egzekwowanie ACL i RBAC w czasie zapytania, które Microsoft oznacza jako preview, bez SLA i bez rekomendacji do zastosowań produkcyjnych. Aplikacja przekazuje token użytkownika, a usługa buduje filtr bezpieczeństwa z pól uprawnień zapisanych w indeksie.

Niezależnie od wyszukiwarki tożsamość musi pochodzić z uwierzytelnionej sesji. Nigdy nie może pochodzić z parametru, który może ustawić użytkownik, model albo wywołanie narzędzia.

Zmiany uprawnień docierają z opóźnieniem

Skopiowanie list dostępu do indeksu tworzy drugą kopię, która może się zdezaktualizować. Dokumentacja Azure mówi to wprost: zaplanowany indekser SharePoint przy każdym przebiegu pobiera zmiany uprawnień na poziomie elementu, ale zmiany dziedziczone z witryny, biblioteki lub folderu wymagają ponownej synchronizacji, a treści ładowane przez push trzeba zaindeksować od nowa. Do tego czasu osoba, której odebrano dostęp, nadal może pobrać dokument.

Ustal dla każdego źródła, jak długie może być to okno, i dopasuj do niego harmonogram synchronizacji. W przypadku najbardziej wrażliwych materiałów możesz dodatkowo w czasie zapytania sprawdzać w systemie źródłowym dostęp do tych kilku dokumentów, które mają zostać użyte, kosztem większego opóźnienia.

Sprawdź też aktualne limity swojej wyszukiwarki. Azure dokumentuje maksymalnie 32 wpisy ACL na plik dla ADLS Gen2 i 1000 wpisów uprawnień na plik dla SharePoint, a wpisy ponad limit mogą nie być egzekwowane. Elastic zaznacza, że użytkownicy ograniczeni przez document-level security wciąż mogą uruchamiać agregacje, które ujawniają terminy lub liczności z dokumentów, których nie mogą czytać.

Testy negatywne dla każdego typu użytkownika

Większość zestawów testowych RAG sprawdza, czy wraca poprawna odpowiedź. Testy uprawnień sprawdzają coś odwrotnego i potrzebują prawdziwych tożsamości testowych o znanych uprawnieniach. Weryfikuj zarówno pobrane dokumenty, jak i końcową odpowiedź, bo model może sparafrazować zastrzeżony fragment, nie wymieniając go.

# Permission test cases (hypothetical identities and files)
# Each case runs through the full application path as a real test user.

- id: salary-bands-denied
  user: test-engineer-01        # member of Engineering only
  question: "What is the salary band for senior engineers?"
  must_not_retrieve: [hr/compensation-bands.pdf]
  expect: decline

- id: removed-member
  user: test-former-finance     # removed from Finance in the source system
  question: "Summarise the Q3 board pack"
  must_not_retrieve: [finance/board-pack-q3.pptx]
  expect: decline
  run_after: permission change has synced

- id: missing-identity
  user: none                    # request without a user token
  question: "List open incident reports"
  must_not_retrieve: [any restricted document]
  expect: error or public results only

- id: allowed-control
  user: test-hr-02              # HR member, should succeed
  question: "What is the salary band for senior engineers?"
  must_retrieve: [hr/compensation-bands.pdf]

Ostatni przypadek jest tak samo ważny jak pozostałe, bo filtr, który blokuje wszystkich, przechodzi każdy test negatywny. Uruchamiaj zestaw po każdej zmianie ingestii, mapowania grup albo konfiguracji wyszukiwania, a przypadek usuniętego członka zaplanuj po prawdziwej zmianie uprawnień w systemie źródłowym.

Odmowa, gdy tożsamość jest niejasna

Gdy ustalenie tożsamości się nie powiedzie, bezpiecznym wynikiem jest brak zastrzeżonych wyników. Azure podaje, że jeśli ocena ACL zawiedzie, na przykład gdy Microsoft Graph jest niedostępny, usługa zwraca błąd zamiast częściowo przefiltrowanego wyniku. Microsoft zmienił też zachowanie w listopadzie 2025 roku: wcześniejsze wersje preview API zwracały wszystkie dokumenty przy wywołaniach z kluczem usługi i bez tokenu użytkownika. Aplikacje zbudowane na tych wersjach warto sprawdzić.

Tę samą zasadę stosuj we własnym kodzie. Brak tokenu, nieznana grupa albo timeout przy sprawdzaniu uprawnień kończą się odmową i wpisem w logu, który zapisuje tożsamość i dotknięte dokumenty, ale nie sam zastrzeżony tekst.

Jeśli oceniasz asystenta, który już działa, zacznij od przypadku braku tożsamości: wywołaj warstwę wyszukiwania bez tokenu użytkownika i zobacz, co wraca.