Ujawnianie danych wrażliwych przez model AI (OWASP LLM02) - co model pamięta i co zdradzi

W skrócie: LLM02 Sensitive Information Disclosure to kategoria OWASP dla sytuacji, w której model ujawnia dane, które powinny zostać poufne - dane osobowe, finansowe, zdrowotne, poświadczenia albo wewnętrzne informacje firmy. W odróżnieniu od wycieków przez RAG, gdzie problem leży w kontroli dostępu do bazy wiedzy, tutaj źródłem bywa sam model: dane, na których był trenowany albo dostrajany, czasem da się z niego odtworzyć wprost.

Sanityzacja danych wejściowych i filtr odpowiedzi na wyjściu to dwie osobne warstwy - żadna z nich nie zastąpi drugiej.

To siódmy wpis z serii o liście OWASP dla aplikacji LLM, po wstrzykiwaniu promptu, wycieku promptu systemowego, bezpieczeństwie RAG, nadmiernej sprawczości agentów, niezaufanych odpowiedziach modelu i zatruwaniu danych.

Trzy różne źródła wycieku

Łatwo wrzucić wszystkie wycieki danych do jednego worka, ale OWASP rozróżnia je nieprzypadkowo - każde źródło wymaga innej obrony.

Źródło	Co się dzieje
Dane treningowe lub dostrajające	Model "zapamiętuje" fragmenty danych, na których był uczony, i potrafi je odtworzyć na żądanie - to zjawisko nazywane regurgitacją
Prompt systemowy i kontekst rozmowy	Dane wklejone do promptu albo wprowadzone wcześniej w tej samej rozmowie wyciekają przez ekstrakcję promptu albo zwykłą nieuwagę modelu
Zewnętrzna baza wiedzy (RAG)	Model ma dostęp do dokumentów, do których konkretny użytkownik nie powinien mieć wglądu - to temat, który szerzej opisaliśmy przy bezpieczeństwie RAG

Ten wpis skupia się na pierwszych dwóch źródłach - na tym, co model "wie" sam z siebie, nie na kontroli dostępu do zewnętrznej bazy wiedzy.

Regurgitacja - gdy model odtwarza dane treningowe

Duże modele językowe trenuje się na ogromnych zbiorach tekstu. Część z tego tekstu bywa zapamiętana niemal dosłownie - szczególnie fragmenty, które w danych treningowych pojawiły się wielokrotnie albo były wystarczająco charakterystyczne. Odpowiednio sformułowane zapytanie potrafi wydobyć taki fragment z powrotem, łącznie z danymi, które nigdy nie powinny trafić do użytkownika końcowego.

OWASP przywołuje tu udokumentowany przypadek ataku "Proof Pudding" (CVE-2019-20634), w którym ujawnione dane treningowe pozwoliły na odtworzenie modelu i obejście jego mechanizmów bezpieczeństwa. To pokazuje, że regurgitacja to nie tylko ryzyko prywatności pojedynczych danych - to także furtka do ataków na sam model.

Ryzyko rośnie przy dostrajaniu (fine-tuningu) modelu na danych firmowych. Jeśli do dostrajania trafiają dane klientów bez odpowiedniej anonimizacji, model może je później zwrócić komuś zupełnie innemu - niekoniecznie w wyniku ataku, czasem po prostu w trakcie zwykłej rozmowy.

Wyciek przez kontekst rozmowy

Drugi scenariusz nie wymaga ataku na model - wystarczy niedopracowana aplikacja. Asystent, który w ramach jednej sesji przetwarza dane wielu użytkowników (na przykład w systemie obsługi zgłoszeń albo czacie wsparcia), może przy niedostatecznej izolacji kontekstu "pomylić" rozmowy i ujawnić fragment danych jednego klienta drugiemu. To nie jest wina samego modelu - to błąd w sposobie, w jaki aplikacja zarządza kontekstem i pamięcią konwersacji.

Membership inference - da się ustalić, czy dane były w treningu

Oprócz bezpośredniej regurgitacji istnieje subtelniejsze ryzyko: ataki typu membership inference, w których nie trzeba wydobyć treści danych, wystarczy ustalić, czy konkretny rekord w ogóle znalazł się w zbiorze treningowym. Sam fakt, że dane konkretnej osoby były użyte do trenowania modelu (na przykład dokumentacja medyczna albo wewnętrzna korespondencja firmy), bywa informacją równie wrażliwą jak treść tych danych - zdradza, że dana osoba lub organizacja była klientem, pacjentem albo stroną konkretnego zbioru danych. To ryzyko, o którym łatwo zapomnieć, bo nie wygląda jak klasyczny "wyciek" - nic nie zostaje dosłownie ujawnione, a mimo to atakujący dowiaduje się czegoś, czego nie powinien.

Dwie osobne warstwy, nie jedna

Sanityzacja danych wejściowych i filtr na wyjściu bywają traktowane jak zamienniki - wystarczy jedno albo drugie. To błąd. Sanityzacja działa zanim dane w ogóle trafią do modelu: usuwa albo anonimizuje dane wrażliwe w zbiorze treningowym, dostrajającym i w promptach. Filtr wyjścia działa na samym końcu: sprawdza, czy to, co model właśnie wygenerował, nie zawiera czegoś, co nie powinno trafić do użytkownika. Obie warstwy łapią różne przypadki. Sanityzacja nie pomoże, jeśli model wywnioskuje dane wrażliwe z kontekstu rozmowy, zamiast odtworzyć je z treningu. Filtr wyjścia nie pomoże, jeśli dane wrażliwe trafiły do zbioru treningowego i model nauczył się ich używać w sposób, którego żaden prosty wzorzec nie wyłapie. Potrzeba obu, nie jednej z nich.

Dlaczego to nie to samo co LLM08

W wpisie o bezpieczeństwie RAG opisywaliśmy, jak gubią się uprawnienia przy indeksowaniu dokumentów - konto konektora czyta wszystko, filtr widoczności istnieje tylko na poziomie interfejsu, nie bazy. To wciąż aktualne ryzyko, ale dotyczy architektury wokół modelu. LLM02 jest węższe i głębsze: dotyczy tego, co sam model "wie" z treningu i dostrajania, niezależnie od tego, jak dobrze zabezpieczona jest otaczająca go infrastruktura. Można mieć bezbłędną kontrolę dostępu do bazy RAG i wciąż mieć model, który regurguluje dane treningowe.

Co robić

Sanityzuj dane przed treningiem i dostrajaniem. Dane osobowe, poświadczenia i informacje poufne nie powinny trafiać do zbioru uczącego bez anonimizacji albo pseudonimizacji.
Waliduj dane wejściowe. Filtruj dane wrażliwe już na etapie przyjmowania ich do systemu, zanim trafią gdziekolwiek dalej.
Stosuj zasadę najmniejszych uprawnień. Model i aplikacja wokół niego powinny mieć dostęp tylko do tych danych, które są niezbędne do konkretnego zadania.
Rozważ techniki chroniące prywatność przy treningu. Differential privacy (dodawanie szumu do danych) i federated learning (trening rozproszony, bez centralizowania surowych danych) zmniejszają ryzyko regurgitacji konkretnych rekordów.
Dodaj niezależny filtr wyjścia. Mechanizm wykrywający wzorce danych wrażliwych (numery dokumentów, dane kontaktowe, dane kart) w odpowiedzi modelu, zanim trafi do użytkownika - osobny od samego modelu.
Informuj użytkowników, co dzieje się z ich danymi. Przejrzysta polityka dotycząca tego, czy rozmowy trafiają do dalszego treningu, z możliwością rezygnacji.

Co sprawdzamy w teście

Przy testach penetracyjnych aplikacji LLM w kontekście LLM02 weryfikujemy między innymi:

Czy model da się nakłonić do odtworzenia fragmentów danych treningowych lub dostrajających (próby ekstrakcji przez różne sformułowania zapytań).
Czy w odpowiedziach modelu pojawiają się dane wrażliwe bez związku z aktualnym zapytaniem użytkownika.
Czy izolacja kontekstu między sesjami i użytkownikami faktycznie działa, nie tylko na poziomie interfejsu.
Czy istnieje niezależny filtr wyjścia wykrywający wzorce danych wrażliwych, zanim odpowiedź trafi do użytkownika.
Czy dokumentacja i polityka prywatności opisują, jakie dane trafiają do treningu lub dostrajania modelu.

Czego to nie załatwi

Filtr wyjścia złapie wzorce, których szuka - numer dokumentu, adres e-mail, numer karty. Nie złapie danych, które nie pasują do żadnego znanego wzorca, na przykład unikalnego opisu sytuacji, który sam w sobie identyfikuje konkretną osobę. Najskuteczniejsza ochrona dzieje się zanim dane trafią do modelu - przy sanityzacji zbioru treningowego i kontroli tego, co w ogóle wchodzi do kontekstu rozmowy. Filtr na wyjściu to siatka bezpieczeństwa, nie główny mechanizm obrony.