Bezpieczeństwo RAG i baz wektorowych (OWASP LLM08) - jak asystent AI pokazuje cudze dokumenty

W skrócie: LLM08 Vector and Embedding Weaknesses to kategoria OWASP dla błędów w tym, jak aplikacje RAG tworzą, przechowują i wyszukują embeddingi. Najczęstszy skutek jest bardzo przyziemny: asystent odpowiada na podstawie dokumentu, którego pytający nie powinien zobaczyć.

Źródło problemu prawie zawsze jest to samo. Dokument w systemie źródłowym ma uprawnienia, a jego kawałek w bazie wektorowej już nie. Naprawa polega na tym, żeby uprawnienia przeszły razem z treścią i były sprawdzane przed wysłaniem fragmentów do modelu.

To czwarty wpis z serii o liście OWASP dla aplikacji LLM, po zatruwaniu danych, nadmiernej sprawczości agentów i niezaufanych odpowiedziach modelu. W ogólnym wpisie o testach LLM RAG dostał jeden akapit. Tutaj rozwijamy go do pełnego tematu.

Jak działa RAG i gdzie gubią się uprawnienia

Retrieval-Augmented Generation to sposób, żeby model odpowiadał na podstawie firmowych dokumentów, a nie tylko tego, czego nauczył się w treningu. Schemat jest prawie zawsze taki sam:

Indeksowanie. Konektor pobiera dokumenty z SharePointa, dysku, wiki czy systemu zgłoszeń, tnie je na fragmenty i zamienia każdy fragment na wektor liczb (embedding). Wektory razem z tekstem trafiają do bazy wektorowej.
Wyszukiwanie. Pytanie użytkownika też jest zamieniane na wektor, a baza zwraca kilka najbardziej podobnych fragmentów.
Generowanie. Fragmenty są doklejane do promptu, a model pisze odpowiedź.

W systemie źródłowym każdy dokument ma właściciela i listę osób z dostępem. W bazie wektorowej zostaje tylko to, co zespół świadomie przeniósł do metadanych fragmentu. Jeśli nie przeniósł nic, baza wie jedynie, że fragment jest podobny do pytania, a to nie jest kontrola dostępu.

Dochodzi do tego konto konektora. Żeby zaindeksować „całą wiedzę firmy", zwykle dostaje uprawnienia do odczytu wszystkiego. Asystent działa więc jak zastępca z kluczami do każdego pokoju, który otwiera drzwi każdemu, kto grzecznie zapyta.

Pięć ryzyk z listy OWASP

Ryzyko	Na czym polega	Jak wygląda w praktyce
Nieuprawniony dostęp i wyciek	Słaba kontrola dostępu do embeddingów i powiązanych z nimi treści.	Pracownik działu sprzedaży pyta o premie i dostaje fragment arkusza kadrowego.
Wycieki między kontekstami	Wspólna baza dla wielu grup użytkowników lub klientów, informacje przenikają między zapytaniami.	Aplikacja SaaS z jednym indeksem dla wszystkich klientów, w jednej ścieżce API brakuje filtra po identyfikatorze klienta.
Odwracanie embeddingów	Odtworzenie tekstu źródłowego z samego wektora.	Wyciekła kopia bazy wektorowej, „w której są przecież tylko liczby".
Zatruwanie danych	Celowe lub przypadkowe wprowadzenie złej treści do bazy wiedzy.	Opisane szerzej w osobnym wpisie.
Zmiana zachowania modelu	Dołożenie RAG zmienia charakter odpowiedzi, nie tylko ich treść.	Przykład OWASP: doradca finansowy po wdrożeniu RAG przestaje odpowiadać empatycznie i podaje same liczby.

Z punktu widzenia testu bezpieczeństwa najważniejsze są pierwsze trzy. Dwa ostatnie dotyczą raczej jakości i integralności odpowiedzi.

Typowe błędy kontroli dostępu

Na testach RAG te same wzorce wracają niezależnie od użytej bazy wektorowej i frameworka:

Brak metadanych o uprawnieniach. Fragmenty nie mają informacji, z jakiego dokumentu pochodzą ani kto może go czytać. Filtrować nie ma po czym.
Filtrowanie w złym miejscu. Aplikacja pobiera najbliższe fragmenty bez filtra, wysyła je do modelu, a uprawnienia sprawdza dopiero przy wyświetlaniu listy źródeł. Źródło znika z ekranu, ale jego treść jest już w odpowiedzi.
Identyfikator najemcy od klienta. Przestrzeń nazw albo kolekcja w bazie jest wybierana na podstawie parametru z żądania, który można podmienić.
Uprawnienia zamrożone w chwili indeksowania. Komuś odebrano dostęp do folderu, ale indeks aktualizuje się raz w tygodniu, więc asystent nadal cytuje dokumenty.
Usunięte dokumenty w indeksie. Plik skasowany w systemie źródłowym zostaje jako fragmenty w bazie wektorowej albo w pamięci podręcznej odpowiedzi.
Baza wektorowa dostępna bezpośrednio. Wystawiona do sieci bez uwierzytelnienia albo z kluczem API zaszytym we frontendzie. Wtedy żadna logika w aplikacji nie ma znaczenia.

Przykład z badań

Zespół SPARK Lab z Uniwersytetu Teksasu w Austin opisał w październiku 2024 atak ConfusedPilot na systemy RAG, w tym Microsoft 365 Copilot. Osoba z prawem zapisu do dowolnego indeksowanego dokumentu mogła wpłynąć na odpowiedzi udzielane innym pracownikom. Według autorów zmieniona treść mogła wpływać na odpowiedzi nawet po usunięciu złośliwego dokumentu. To dobry argument, żeby w teście sprawdzać nie tylko to, co jest w indeksie, ale też to, co z niego powinno zniknąć.

Embedding to nie anonimizacja

Częste założenie brzmi tak: baza wektorowa przechowuje liczby, więc nie jest tak wrażliwa jak dokumenty. Badania mówią co innego. Praca Text Embeddings Reveal (Almost) As Much As Text (Morris i in., EMNLP 2023) pokazała metodę, która z samych embeddingów odtwarzała dokładnie 92% tekstów o długości 32 tokenów. Z embeddingów notatek klinicznych udało się odzyskać pełne imiona i nazwiska pacjentów. Wcześniej podobny wniosek przedstawili autorzy ataku GEIA (Li i in., ACL 2023).

Wyniki dotyczą konkretnych modeli embeddingowych i krótkich tekstów, więc nie należy ich traktować jako gwarancji, że każdy wektor da się odwrócić. Wniosek praktyczny jest jednak prosty: baza wektorowa ma tę samą klasyfikację co dokumenty, z których powstała. Dotyczy to też kopii zapasowych, eksportów i środowisk testowych. Zresztą większość baz i tak przechowuje obok wektora oryginalny tekst fragmentu, więc atakujący często nie musi niczego odwracać.

Ukryta treść w indeksowanych dokumentach

Pierwszy scenariusz ataku w opisie OWASP dotyczy rekrutacji. Kandydat umieszcza w CV białym tekstem na białym tle polecenie, żeby model zignorował wcześniejsze instrukcje i polecił jego kandydaturę. Człowiek tego nie widzi, a narzędzie do wyciągania tekstu przekazuje to modelowi razem z resztą.

Ten sam mechanizm działa dla każdego źródła, do którego zapisują osoby spoza firmy: zgłoszeń od klientów, maili, faktur, formularzy. To styk LLM08 ze wstrzykiwaniem pośrednim: baza wiedzy staje się kanałem, którym polecenia trafiają do modelu.

Jak to sprawdzamy w teście

Mapa źródeł i konektorów. Skąd indeks pobiera dokumenty, na jakim koncie, jak często się odświeża i kto z zewnątrz może do tych źródeł pisać.
Dokumenty-kanarki. Umieszczamy w źródłach dokumenty z unikalnymi znacznikami, dostępne tylko dla wybranej roli, działu albo klienta. Potem pytamy o nie z kont bez dostępu, wprost i okrężnie.
Cykl życia uprawnień. Odbieramy dostęp do dokumentu, usuwamy go, zmieniamy jego treść i sprawdzamy, po jakim czasie asystent przestaje z niego korzystać.
Izolacja najemców. Podmiana identyfikatorów klienta, kolekcji i przestrzeni nazw w żądaniach do API, także w ścieżkach mniej oczywistych niż główny czat: eksportach, wyszukiwarce, podsumowaniach.
Bezpośredni dostęp do bazy. Czy baza wektorowa i jej panel są osiągalne z sieci, czy klucze nie są widoczne w kodzie frontendu, co zawierają kopie zapasowe.
Ukryta treść. Dokumenty z tekstem niewidocznym dla człowieka, w metadanych, komentarzach i polach formularzy, wprowadzane tymi kanałami, do których dostęp mają osoby z zewnątrz.

Co robić

Uprawnienia przy każdym fragmencie. Identyfikator dokumentu, najemcy i lista grup z dostępem zapisane w metadanych w chwili indeksowania.
Filtr przed modelem, po stronie serwera. Zapytanie do bazy wektorowej zawiera filtr wynikający z sesji użytkownika, a nie z parametrów żądania. Model nigdy nie widzi fragmentu, którego użytkownik nie mógłby otworzyć w systemie źródłowym.
Twarda izolacja klientów. W aplikacjach dla wielu firm osobne kolekcje lub bazy dla każdego klienta są bezpieczniejsze niż jeden indeks z filtrem, bo pominięty filtr nie zamienia się w wyciek.
Synchronizacja z systemem źródłowym. Odebranie dostępu i usunięcie dokumentu muszą docierać do indeksu i pamięci podręcznej, najlepiej zdarzeniowo, a nie w nocnym przebiegu.
Konektor z minimalnymi prawami. Indeksujcie to, czego asystent naprawdę potrzebuje, a nie „wszystko, co widzi konto serwisowe".
Walidacja przy wejściu do indeksu. Wyciąganie tekstu, które wykrywa ukrytą treść, oraz oznaczanie źródeł zewnętrznych jako mniej zaufanych.
Logi wyszukiwania. Kto zapytał, jakie fragmenty zostały zwrócone i z jakich dokumentów. Bez tego po incydencie nie da się ustalić, co wyciekło.

Czego to nie załatwi

Poprawna kontrola dostępu w RAG sprawia, że asystent nie pokaże więcej, niż użytkownik i tak może zobaczyć. Jeśli jednak uprawnienia w samym SharePoincie czy na dysku są za szerokie, asystent tylko to uwidoczni, bo odnajdzie w kilka sekund plik, którego nikt wcześniej nie szukał. Wdrożenie RAG to dobry moment na przegląd uprawnień w systemach źródłowych, a nie tylko w nowej bazie.

Nie rozwiązuje to też problemu fragmentów, które są dostępne i mają poprawne uprawnienia, ale zawierają polecenia. Na to działa ograniczenie tego, co model może zrobić z przeczytaną treścią, o czym więcej w wpisie o agentach. Zakres testów, w których to sprawdzamy, opisujemy na stronie testów penetracyjnych aplikacji LLM.