Zabezpieczanie RAG i enterprise search

Dlaczego AI enterprise search ujawnia dane, które zawsze tam były

Retrieval-augmented generation działa tak: bierze pytanie użytkownika, pobiera pasujące dokumenty z magazynu treści i podaje je modelowi, żeby oprzeć na nich odpowiedź. Krok retrieval to miejsce, w którym mieszka pytanie o bezpieczeństwo. Jeśli system może pobrać dokument, model może go streścić i podać użytkownikowi.

Kluczowy punkt, najczęściej mylnie odczytywany jako awaria modelu, jest taki, że dobrze zbudowany asystent firmowy honoruje istniejące uprawnienia. Microsoft wprost mówi, że Copilot może streszczać albo przywoływać wyłącznie treść, do której użytkownik ma uprawnienia, i że to kontrole dostępu SharePoint i OneDrive decydują, co może odkryć, bez zmiany czyichkolwiek uprawnień (Microsoft Learn, 2026). Asystent więc nie przyznaje nowego dostępu. Działa dokładnie z takim dostępem, jaki użytkownik już miał.

To właśnie dlatego ujawnia tak dużo. Przez lata „użytkownik technicznie ma uprawnienia do tego pliku" i „użytkownik faktycznie może ten plik znaleźć" były dwoma różnymi faktami. Dokument udostępniony zbyt szeroko, leżący na stronie, której nikt nie posprzątał od 2019 roku, miał uprawnienia dla połowy firmy, a znaleźć go potrafił prawie nikt. Retrieval zamyka tę lukę. Pytanie w stylu „jaki jest plan premiowy dla zarządu" przeszukuje dziś wszystko, do czego pytający ma prawo, i zwraca najbardziej trafny wynik, nawet jeśli ten plik został przypadkowo nadmiarowo udostępniony lata temu. Uśpione uprawnienie zamienia się w żywe ujawnienie.

Szczera rama jest więc taka: AI enterprise search to test z zarządzania dostępem, do którego się nie przygotowałeś. Pokazuje prawdziwy stan Twoich uprawnień, który w większości dużych tenantów jest bardziej zagmatwany, niż ktokolwiek sądził.

Problem nadmiarowego udostępniania w Copilocie, w wersji ogólnej

Historia Microsoft 365 Copilot to najbardziej widoczna wersja tego zjawiska, ale mechanizm jest ogólny i dotyczy Glean, własnoręcznie zbudowanego RAG nad data lake i każdego asystenta indeksowanego na całym korpusie. Wspólne składniki:

• Rozrost uprawnień w magazynie źródłowym. Strony ustawione na „wszyscy oprócz użytkowników zewnętrznych", zepsute dziedziczenie uprawnień, gdzie folder już nie pasuje do rodzica, linki udostępniające ustawione na „każdy w organizacji", choć powinny być na „konkretne osoby", i członkostwa w grupach, których nikt nie przejrzał.
• Warstwa retrieval, która wiernie respektuje te uprawnienia. Właśnie dlatego, że je respektuje, dziedziczy każde nadmiarowe uprawnienie jako wynik możliwy do znalezienia.
• Interfejs w języku naturalnym, który usuwa tarcie związane ze znajdowaniem rzeczy. Użytkownik nie musi już wiedzieć, gdzie plik się znajduje ani jak się nazywa.

Raportowanie dostawców i społeczności podaje liczby na ten rozrost: jedna analiza wskazała około 16% danych krytycznych dla biznesu nadmiarowo udostępnionych w przeciętnym tenancie i około 802 000 zagrożonych plików, przy czym wiele organizacji odkrywa tę ekspozycję dopiero po uruchomieniu Copilota (raportowanie społeczności Microsoft i partnerów, 2025-2026). To szacunki dostawców i warto czytać je jako kierunkowe, nie precyzyjne. Wzorzec, który opisują, ekspozycja odkrywana po wdrożeniu, nie przed nim, to spójny wynik.

OWASP umieszcza to w dwóch swoich kategoriach LLM. Sensitive Information Disclosure (LLM02:2025) to skutek: prywatne, regulowane albo zastrzeżone dane pokazane komuś, kto nie powinien ich widzieć. Vector and Embedding Weaknesses (LLM08:2025) to mechanizm po stronie magazynu: jeśli embeddingi napędzające retrieval żyją w bazie wektorowej bez właściwej kontroli dostępu, zwłaszcza we współdzielonej bazie multi-tenant, retriever może pokazać treść ponad granicami, których powinien przestrzegać.

Dlaczego naprawa modelu tego nie naprawia

Kusi, żeby szukać odpowiedzi po stronie modelu: lepszego system prompta, filtra na wyjściu, instrukcji, żeby nie ujawniać wrażliwych materiałów. Żadne z tych rozwiązań nie dotyka przyczyny, bo model nigdy nie decydował, co może zobaczyć. Zdecydowała o tym warstwa retrieval, na podstawie uprawnień użytkownika i kontroli dostępu magazynu.

Jeśli dokument dało się pobrać, ujawnienie nastąpiło już na etapie retrieval, zanim model napisał choć jedno słowo. Filtrowanie wyjścia potrafi wyłapać część oczywistych przypadków, ale to zabezpieczenie stosowane już po tym, jak wrażliwa treść weszła do kontekstu, i zawodzi otwarcie wobec wszystkiego, do rozpoznawania czego nie zostało dostrojone. Trwałe kontrole leżą wszystkie przed modelem: w uprawnieniach, w logice retrieval i w magazynie.

Kontrole, które to ograniczają

Pomyśl o tym w trzech warstwach: napraw stan dostępu, spraw, żeby retrieval był świadomy tożsamości, i zabezpiecz magazyn. Wzmacniają się nawzajem.

Najpierw napraw stan dostępu

Praca fundamentalna to higiena uprawnień, i jest najcenniejsza, gdy zrobisz ją, zanim włączysz asystenta.

• Znajdź i napraw wzorce zbyt szerokiego udostępniania: „wszyscy oprócz użytkowników zewnętrznych" na stronach, które powinny być zawężone, zepsute dziedziczenie, gdzie uprawnienia potomne odbiegają od rodzica, i linki udostępniające na poziomie całej organizacji, które powinny być na konkretne osoby.
• Przejrzyj i zaostrz członkostwa w grupach, bo nieaktualna grupa to ciche nadmiarowe uprawnienie, które retrieval wzmocni.
• Użyj raportowania platformy, żeby zlokalizować nadmiarowe udostępnianie przed wdrożeniem. Microsoft, na przykład, udostępnia ustawienia wyszukiwania i odkrywania, które ograniczają, jakie strony pojawiają się w Copilocie i wyszukiwaniu ogólnoorganizacyjnym, polityki governance i cyklu życia, które zmniejszają długoterminowe nadmiarowe udostępnianie, oraz funkcję ograniczonego dostępu, która blokuje wrażliwą stronę do jawnej listy dozwolonych, niezależnie od istniejących uprawnień (Microsoft Learn, 2026).

Spraw, żeby retrieval był świadomy tożsamości i przycinany do uprawnień

Kontrola, na której nie ma kompromisu, to żeby retrieval działał z uprawnieniami pytającego użytkownika, tak żeby asystent nigdy nie zwrócił dokumentu, którego użytkownik nie mógłby otworzyć bezpośrednio.

• Wymuś przycinanie uprawnień per użytkownik w momencie zapytania, tak żeby retrieval filtrował do tego, co ta tożsamość ma prawo zobaczyć. To właśnie sprawia, że asystent jest wierny Twojemu modelowi dostępu, a nie indeksowi.
• Filtruj pobraną treść, zanim wejdzie do kontekstu modelu, stosując sprawdzenia dostępu oparte na atrybutach albo politykach na granicy retrieval (praktyka bezpiecznego RAG; OWASP LLM02:2025).
• Dla systemów budowanych samodzielnie ogranicz, jakie kolekcje może odpytywać pipeline retrieval, i uruchamiaj konto serwisowe pipeline'u na zasadzie least privilege, tak żeby pipeline nie sięgał dalej, niż wymaga tego przypadek użycia.

Zastosuj etykiety wrażliwości i DLP na poziomie danych

• Użyj etykiet wrażliwości i szyfrowania, tak żeby ochrona podróżowała razem z treścią. W Microsoft 365 Copilot honoruje etykiety wrażliwości i szyfrowanie Purview: tam, gdzie stosuje się szyfrowanie, użytkownik potrzebuje odpowiednich uprawnień użycia, żeby asystent mógł skorzystać z treści, a uprawnienia etykiet zdefiniowane przez użytkownika mogą całkowicie zablokować agentowi odczyt pliku (Microsoft Learn, 2026).
• Zastosuj warunki data loss prevention, które ograniczają, co asystent może pokazać na podstawie klasyfikacji, jako warstwę polityki nałożoną na uprawnienia.

Zabezpiecz bazę wektorową i indeks

• Kontroluj dostęp do samej bazy wektorowej, a w projektach multi-tenant albo multi-team używaj osobnych, kontrolowanych pod kątem dostępu namespace'ów, tak żeby retriever nie mógł przekraczać granic. Współdzielone, niesegmentowane bazy wektorowe to droga wycieku po stronie magazynu, którą OWASP opisuje jako LLM08:2025.
• Utrzymuj model dostępu indeksu zgodny z modelem źródła. Jeśli uprawnienia zmieniają się u źródła, widok warstwy retrieval na te uprawnienia też musi się zmienić, inaczej ponownie wprowadzasz lukę, od której zaczął się problem.

Loguj, audytuj i dopasuj się do frameworku

• Zbieraj zapisy audytowe promptów, odpowiedzi i treści, do których się odwoływano, tak żeby ujawnienie było wykrywalne i możliwe do przeanalizowania. Microsoft 365 właśnie dlatego udostępnia interakcje Copilota do audytu Purview, eDiscovery i retencji (Microsoft Learn, 2026).
• Dopasuj program do NIST AI Risk Management Framework i odpowiednich kategorii OWASP LLM, które dają wspólne słownictwo i listę kontrolną obejmującą ingestion, indeksowanie, retrieval i generację, a nie tylko sam model.

Krótkie odniesienie: gdzie leży kontrola

• Nadmiarowo udostępnione strony i zepsute dziedziczenie · Gdzie się to naprawia: Uprawnienia u źródła, naprawione przed wdrożeniem
• Asystent zwraca plik, którego użytkownik nie powinien widzieć · Gdzie się to naprawia: Przycinanie uprawnień per użytkownik w momencie retrieval
• Wrażliwa treść pokazana niezależnie od uprawnień · Gdzie się to naprawia: Etykiety wrażliwości, uprawnienia użycia szyfrowania, DLP
• Wyciek między tenantami albo zespołami · Gdzie się to naprawia: Baza wektorowa z kontrolą dostępu i podziałem na namespace'y
• Niewykryte ujawnienie · Gdzie się to naprawia: Logowanie audytowe promptów, odpowiedzi i odwołań

Źródła

• Microsoft Learn, "How data is protected and audited in Microsoft 365 and Microsoft 365 Copilot" · https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-architecture-data-protection-auditing (Copilot honoruje istniejące uprawnienia; kontrole SharePoint i OneDrive; etykiety wrażliwości i szyfrowanie; audyt)
• Microsoft Community Hub, "Mitigate Oversharing to Govern Microsoft 365 Copilot and Agents" · https://techcommunity.microsoft.com/blog/microsoft365copilotblog/mitigate-oversharing-to-govern-microsoft-365-copilot-and-agents/4448744 (wzorce nadmiarowego udostępniania; raporty stanu uprawnień; ograniczona kontrola dostępu)
• Microsoft Learn, "Get ready for Microsoft 365 Copilot with SharePoint Advanced Management" · https://learn.microsoft.com/en-us/sharepoint/get-ready-copilot-sharepoint-advanced-management (limity wyszukiwania i odkrywania, governance, ograniczony dostęp ograniczający nadmiarowe udostępnianie)
• OWASP Top 10 for LLM Applications 2025, LLM02 Sensitive Information Disclosure · https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/ (ujawnianie wrażliwych danych przez aplikacje LLM)
• OWASP Top 10 for LLM Applications 2025, LLM08 Vector and Embedding Weaknesses · https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/ (ryzyka kontroli dostępu do bazy wektorowej i embeddingów, w tym wyciek między tenantami)
• we45, "RAG Systems are Leaking Sensitive Data" · https://www.we45.com/post/rag-systems-are-leaking-sensitive-data (wyciek przez odsłonięte bazy wektorowe, słabą logikę retrievera i niefiltrowane embeddingi)
• Daxa, "Secure Retrieval-Augmented Generation (RAG) in Enterprise Environments" · https://www.daxa.ai/blogs/secure-retrieval-augmented-generation-rag-in-enterprise-environments (filtrowanie świadome tożsamości, izolacja namespace'ów, kontrole na granicy retrieval)
• NIST AI Risk Management Framework (AI RMF 1.0) · https://www.nist.gov/itl/ai-risk-management-framework (kontrole governance i ryzyka obejmujące dane, retrieval i generację)