Red teaming LLM: testuj asystenta atakiem przed produkcją

Trzy tygodnie przed uruchomieniem klienta B2B jeden z naszych asystentów odpowiedział na sprytnie sfrmułowane zapytanie, cytując fragment promptu systemowego. Nie był to błąd modelu, była to luka w architekturze guardrails, którą odkryliśmy sami, bo zanim uruchomiliśmy system produkcyjnie, przeprowadziliśmy sesję red teamingu. Naprawa zajęła dwa dni. Gdybyśmy ją znaleźli po uruchomieniu, kosztowałaby znacznie więcej.

Tradycyjny pentest infrastruktury szuka podatności w oprogramowaniu: otwarte porty, niezałatane CVE, błędy autoryzacji. Red teaming LLM szuka innego rodzaju słabości: jak model reaguje na dane wejściowe, których nie przewidziałeś przy projektowaniu systemu.

Kluczowa różnica: pentest jest zazwyczaj jednorazowy, odbywa się przed uruchomieniem i kończy się raportem z listą znalezisk. Red teaming LLM w dobrze zaprojektowanym systemie jest ciągły: każde nowe znalezisko trafia do katalogu ataków, katalog zamienia się w suite regresyjną, a suite uruchamia się automatycznie przy każdej zmianie konfiguracji lub bazy wiedzy.

Dlaczego ciągłość ma znaczenie? Model bazowy może się zmienić. Baza wiedzy RAG rośnie i może przejąć nowe dokumenty. Prompt systemowy jest modyfikowany. Każda z tych zmian może otworzyć nową powierzchnię ataku, która nie istniała przy poprzednim przeglądzie.

Red teaming LLM nie jest wolną improwizacją. Pracujemy z katalogiem klas ataków, z których każda ma zdefiniowane metody testowe i kryterium oceny.

Szczegółową taxonomię 10 klas podatności opisuje standard OWASP LLM Top 10. My w Cashcrown używamy tej taxonomii jako listy kontrolnej przy każdej sesji red teamingu.

Nie każde znalezisko jest jednakowo pilne. Scoring pozwala priorytetyzować naprawy i komunikować ryzyko do zespołu.

Używamy trzech wymiarów: możliwość wykorzystania (jak trudny jest atak), wpływ (co atakujący może osiągnąć) i kontekst wdrożenia (czy system obsługuje dane wrażliwe, ma dostęp do narzędzi, działa publicznie).

Wynik praktyczny to trzy priorytety:

• Krytyczny: atak wykonywalny przez nieprzeszkolonego użytkownika, prowadzi do wycieku danych lub wykonania nieodwracalnej akcji. Blokuje uruchomienie.
• Wysoki: atak wymaga przygotowania, ale jest powtarzalny. Naprawa przed uruchomieniem, nie po.
• Niski/obserwowany: atak trudny lub o małym wpływie. Trafia do rejestru, jest monitorowany, nie blokuje uruchomienia.

Jednorazowy przegląd przed wdrożeniem jest konieczny, ale niewystarczający. Pętla ciągłego red teamingu wygląda tak:

1. Każde nowe znalezisko (niezależnie od źródła: wewnętrzny test, zgłoszenie użytkownika, literatura) trafia do katalogu jako przypadek testowy.
2. Przypadek testowy ma format: atak wejściowy + oczekiwana odpowiedź obronna (odmowa, maskowanie, eskalacja do człowieka).
3. Katalog jest uruchamiany automatycznie przy każdej zmianie promptu systemowego, aktualizacji bazy wiedzy RAG lub zmianie modelu bazowego.
4. Każdy nowy wynik porównuje się z poprzednim: brak regresji to warunek merge'a.
5. Co miesiąc dodajemy nowe przypadki testowe z aktualnej literatury i zgłoszeń.

Ten wzorzec działa na tych samych zasadach co testy regresyjne w inżynierii oprogramowania: bug zgłoszony raz zamienia się w test, który pilnuje, że bug nie wróci. Różnica polega na tym, że zestaw ataków stale rośnie.

To jest ważne zastrzeżenie, które robimy wprost: żaden program red teamingu nie udowodni, że system jest „w pełni bezpieczny". LLM to systemy probabilistyczne: to samo wejście przy innej temperaturze lub innej wersji modelu może dać inny wynik.

Cel red teamingu jest skromniejszy i przez to realistyczny: znane klasy ataków zostały przetestowane, odkryte podatności są udokumentowane z severity i statusem mitigacji, a suite regresyjna pilnuje, że naprawione problemy nie wracają po zmianach.

Wyniki sesji red teamingu są częścią technicznej dokumentacji systemu AI, tego samego dokumentu, który przy systemach wysokiego ryzyka wspiera wymogi AI Act dotyczące zarządzania ryzykiem.

My w Cashcrown każdy system asystenta przechodzi przez audyt przed wdrożeniem (lista kontrolna 6 obszarów, opisana w artykule o audycie bezpieczeństwa asystenta AI) plus sesję red teamingu z katalogiem klas ataków.

Katalog startowy obejmuje co najmniej: 5 wariantów prompt injection bezpośredniego, 3 warianty injection przez RAG, 4 warianty jailbreaku persony, 2 warianty wycieku konfiguracji i testy we wszystkich obsługiwanych językach (wzorce injection po polsku, angielsku, ukraińsku, niemiecku). Łącznie 15-25 przypadków testowych na typowy asystent RAG z narzędziami.

Po uruchomieniu katalog rośnie: każde zgłoszenie lub nowy wzorzec z literatury trafia jako nowy przypadek. Po 6 miesiącach działania system ma zazwyczaj 40-80 przypadków testowych. Monitoring bieżący (opisany w artykule o monitoringu [hallucination] i zachowań asystenta) uzupełnia red teaming między sesjami.

Architektura warstwy obronnej, którą testuje red teaming, jest szczegółowo omówiona w artykule o ochronie przed prompt injection i o OWASP LLM Top 10.

Klasyczny pentest szuka podatności w infrastrukturze: otwarte porty, niezałatane CVE, błędy autoryzacji. Red teaming LLM testuje zachowanie modelu przy złośliwych danych wejściowych: injection, jailbreaki, wymuszanie wycieku konfiguracji. Oba są potrzebne w pełnym programie bezpieczeństwa, ale testują różne powierzchnie ataku i wymagają innych metod i narzędzi.

Dla typowego asystenta RAG z 3-5 narzędziami pierwsza sesja obejmuje przygotowanie katalogu startowego (0,5 dnia), przeprowadzenie testów (1 dzień), scoringowanie i dokumentację znalezisk (0,5 dnia). Łącznie 2 dni robocze. Wyniki na starcie zwykle mieszczą się w zakresie 2-6 znalezisk, z czego 0-2 krytycznych. Kolejne sesje są szybsze, bo katalog jest już gotowy.

AI Act nie wymienia red teamingu z nazwy, ale dla systemów wysokiego ryzyka wymaga udokumentowanego zarządzania ryzykiem i testowania przed wdrożeniem. Wyniki sesji red teamingu z katalogiem ataków, severity scoringiem i listą mitigacji naturalnie wypełniają tę lukę dokumentacyjną. Dla systemów ogólnego przeznaczenia (typowy chatbot informacyjny) obowiązek jest słabszy, ale brak dokumentacji utrudnia obronę w razie incydentu.

Podatność krytyczna blokuje uruchomienie. Naprawa idzie przed harmonogramem: zatrzymanie jest tańsze niż incydent po uruchomieniu. Praktycznie: krytyczne znalezisko trafia jako ticket z najwyższym priorytetem, mitigacja jest testowana na tym samym przypadku testowym, który ją odkrył, i dopiero po weryfikacji wraca na listę PASS. Presja terminów jest zrozumiała, ale kompromis bezpieczeństwa przy systemach obsługujących klientów ma wymierne konsekwencje reputacyjne i prawne.

Observability w ciągłym monitoringu pełni rolę uzupełniającą: logowanie anomalii (próby injection rozpoznane przez guardrails), alert na skoki blokowanych zapytań, przegląd próbek odpowiedzi przy każdej aktualizacji bazy wiedzy. Nie zastępuje sesji red teamingu, ale sygnalizuje, gdy pojawiają się nowe wzorce wymagające rozszerzenia katalogu.