Bezpieczeństwo RAG: jak chronić pipeline i wektory

Bezpieczeństwo RAG wymaga ochrony całego przepływu: źródła dokumentu, ingestu, chunkingu, embeddingu, bazy wektorowej, retrievalu, promptu i odpowiedzi. Retrieval-Augmented Generation poprawia dostęp modelu do wiedzy, ale dokument staje się niezaufanym wejściem zdolnym wpływać na zachowanie LLM.

OWASP wskazuje m.in. zatrucie danych, nieuprawniony dostęp, wycieki między kontekstami oraz słabości embeddingów i wektorów.

Zaufanie zaczyna się przed ingestem

Każde źródło powinno mieć ownera, klasyfikację i dozwolony zakres. Skanuj pliki, normalizuj format i zapisuj pochodzenie, wersję, czas pobrania oraz sumę kontrolną. Oddziel treść od instrukcji systemowych.

Dokument z internetu, ticket klienta lub przesłany PDF może zawierać prompt injection ukryty w tekście, metadanych albo obrazie OCR. Nie pozwalaj, by treść dokumentu nadpisywała politykę systemową lub uruchamiała narzędzia.

Autoryzacja przed retrievalu

Filtruj dokumenty według tożsamości użytkownika i uprawnień zanim ich fragmenty trafią do promptu. Filtrowanie dopiero po wygenerowaniu odpowiedzi jest za późne — model mógł już wykorzystać niedozwoloną treść.

Przenoś ACL razem z dokumentem i chunkiem. W środowisku multi-tenant stosuj twardą separację indeksów lub rygorystyczne filtry tenant ID. Testuj brak wyników między najemcami.

Chroń bazę wektorową

Szyfruj transmisję i dane, ogranicz konta serwisowe oraz loguj odczyty i zapisy. Zmiana embeddingu lub metadanych może wpłynąć na ranking bez edycji widocznego dokumentu, dlatego kontroluj integralność, wersję modelu embeddingowego i proces reindeksacji.

Nie traktuj podobieństwa wektorowego jako decyzji autoryzacyjnej. Semantycznie zbliżony fragment nadal może należeć do innego użytkownika.

Ogranicz wpływ prompt injection

Wyraźnie oznaczaj treść odzyskaną jako dane niezaufane. Minimalizuj liczbę fragmentów i ich długość. Narzędzia udostępniaj przez osobną warstwę polityk, z walidacją parametrów, minimalnymi uprawnieniami i potwierdzeniem operacji wysokiego ryzyka.

Model nie powinien sam decydować, że tekst „wyślij wszystkie dokumenty” jest autoryzowanym poleceniem. Szczegółowy model zagrożeń opisuje OWASP Top 10 dla LLM.

Wyjście, cytowania i prywatność

Wymagaj cytowań do wykorzystanych fragmentów i pokazuj użytkownikowi źródło. Cytowanie nie gwarantuje prawdy, ale ułatwia weryfikację. Filtruj sekrety, dane osobowe i instrukcje wewnętrzne przed odpowiedzią.

Nie loguj pełnych promptów bez klasyfikacji i retencji. Telemetria RAG sama może stać się repozytorium wrażliwych danych.

Testy bezpieczeństwa RAG

1. Wprowadź dokument z jawnym i ukrytym prompt injection.
2. Sprawdź dostęp między rolami i tenantami.
3. Testuj zatrucie indeksu oraz zmianę metadanych.
4. Próbuje wydobyć sekrety przez pytania pośrednie.
5. Zmieniaj pisownię, język i format ataku.
6. Weryfikuj, czy narzędzia odrzucają nadmierne działania.
7. Mierz trafność cytowań i skalę nieuprawnionego retrievalu.

RAG nie dziedziczy automatycznie praw dostępu z systemu źródłowego. Bez kontroli pochodzenia i autoryzacji może szybko zamienić rozproszone, dobrze chronione dane w jeden wygodny punkt wycieku.

---

Test autoryzacji retrieval

Uprawnienie sprawdzaj przed wyszukaniem i ponownie przed przekazaniem fragmentu do modelu. Filtr metadanych musi być wymuszony po stronie serwera, nie dopisany przez klienta. Zbuduj zestaw testowy z dokumentami dwóch tenantów, rekordami usuniętymi i treścią objętą embargiem; pytania powinny próbować uzyskać dane wprost, przez synonimy i przez podsumowanie wielu fragmentów.

Dokument jest niezaufanym wejściem. Oddziel instrukcje systemowe od pobranej treści, oznacz źródła i ogranicz narzędzia dostępne po retrieval. Loguj identyfikatory fragmentów, wersję indeksu i decyzje polityki bez utrwalania wrażliwych promptów ponad potrzebę. Po usunięciu danych sprawdź indeks, cache i kopie, nie tylko magazyn źródłowy.

Źródła: OWASP RAG Security Cheat Sheet, OWASP LLM08, NIST GenAI Profile.