AI red teaming w praktyce — testy LLM i agentów AI

AI red teaming to kontrolowane testowanie systemu sztucznej inteligencji z perspektywy przeciwnika. Celem nie jest jedynie skłonienie modelu do wygenerowania zakazanej treści. Dojrzały test obejmuje model, aplikację, dane RAG, narzędzia agenta, tożsamość, infrastrukturę i procesy człowieka. Sprawdza, czy atakujący może uzyskać realny skutek: dostęp do cudzych informacji, nieautoryzowaną operację, manipulację decyzją, trwałe zatrucie wiedzy albo niekontrolowany koszt.

W odróżnieniu od jednorazowego zestawu jailbreaków AI red teaming wymaga jasno określonego zakresu, hipotez, bezpiecznych reguł działania, powtarzalnych testów i regresji. Poniżej przedstawiamy metodykę, którą można zastosować do czatbota, aplikacji RAG i autonomicznego agenta.

AI red teaming a klasyczny pentest

Klasyczny pentest koncentruje się na deterministycznych elementach: API, autoryzacji, sesjach, konfiguracji, logice biznesowej i infrastrukturze. Ta sama operacja przy tych samych warunkach zwykle daje ten sam wynik. System AI może reagować inaczej zależnie od modelu, temperatury, historii, kolejności wiadomości i treści pobranych z zewnętrznych źródeł.

AI red teaming rozszerza pentest o obszary takie jak:

prompt injection i jailbreak;
ujawnienie danych z kontekstu lub indeksu;
manipulacja retrieval i poisoning;
nadużycie narzędzi oraz nadmierna autonomia;
halucynacje i szkodliwe decyzje biznesowe;
koszty, pętle oraz wyczerpanie zasobów;
wpływ aktualizacji modelu na wcześniej działające zabezpieczenia.

Nie zastępuje to klasycznego pentestu aplikacji ani pentestu API. Agent odporny na prosty prompt injection nadal może mieć IDOR w endpointzie, z którego korzysta. Z kolei poprawnie zabezpieczone API może zostać nadużyte, jeżeli model ma zbyt szeroki scope i sam podejmuje decyzję o wywołaniu.

Pięć warstw testu bezpieczeństwa AI

Praktyczny zakres warto podzielić na pięć warstw.

1. Model i polityki odpowiedzi

Tutaj ocenia się jailbreaki, omijanie zasad, manipulację rolami, kodowania, rozmowy wieloetapowe i zachowanie w językach innych niż dominujący język testów. Wynik nie powinien ograniczać się do oceny „model odmówił”. Liczy się, czy odpowiedź pozwala wykonać szkodliwy cel, ujawnia poufne instrukcje albo dostarcza fragmenty, które można połączyć.

2. Aplikacja i orkiestracja

Orkiestrator buduje prompt, przechowuje historię, wybiera model, przetwarza wynik i obsługuje narzędzia. Test obejmuje mieszanie sesji, zaufanie do pól klienta, walidację structured output, obsługę błędów, fallback między modelami i konfigurację guardraili. Szczególnie ważne jest śledzenie odpowiedzi modelu do końcowego konsumenta, aby znaleźć XSS, command injection lub SSRF.

3. RAG, pamięć i dane

Sprawdzamy autoryzację na poziomie dokumentu i fragmentu, separację tenantów, poisoning, usuwanie danych, ranking retrieval oraz możliwość wprowadzenia instrukcji przez zewnętrzny dokument. Pamięć długoterminowa może utrwalić złośliwą treść i wpływać na kolejne sesje, dlatego wymaga osobnych testów zapisu, odczytu i czyszczenia.

4. Narzędzia i agenci

Agent potrafi wykonywać akcje. Testujemy minimalne uprawnienia, ekrany potwierdzeń, walidację parametrów, chaining narzędzi, możliwość rozszerzenia celu i bezpieczne przerwanie pętli. Dla integracji Model Context Protocol stosujemy dodatkowo scenariusze opisane w przewodniku bezpieczeństwa MCP.

5. Infrastruktura, tożsamość i operacje

Obejmuje sekrety, role chmurowe, endpointy modeli, rejestry artefaktów, logi, retencję, monitoring i reakcję na incydent. Model uruchomiony w kontenerze z uprzywilejowanym dostępem albo agent z tokenem administratora tworzą ryzyko niezależne od jakości promptu systemowego.

Krok 1: określ cel, aktywa i bezpieczne granice

Zanim powstanie pierwszy prompt testowy, właściciel systemu i zespół testujący muszą uzgodnić, co chronią. Aktywem może być baza klientów, kod źródłowy, reputacja marki, dostępność usługi, budżet API lub integralność decyzji. Dla każdego aktywa należy opisać nieakceptowalny skutek.

Rules of Engagement powinny określać środowisko, konta, dozwolone dane, godziny testów, limity kosztu, zakazane działania, kanał eskalacji i procedurę awaryjnego zatrzymania. Gdy agent może wysłać wiadomość, kupić produkt albo zmienić produkcyjne dane, test należy prowadzić w sandboxie albo na zasobach przygotowanych specjalnie do ćwiczenia.

Zakres powinien wymieniać konkretne modele i wersje, prompty, kolekcje RAG, narzędzia, role, źródła danych, funkcje oraz interfejsy. Ogólny zapis „test chatbota” nie wystarcza, ponieważ pomija komponenty decydujące o skutku.

Krok 2: zbuduj model zagrożeń

Diagram pokaże, gdzie niezaufana treść staje się instrukcją i gdzie decyzja modelu wywołuje efekt. Oznacz:

użytkowników anonimowych, zwykłych, uprzywilejowanych i administratorów;
zewnętrzne strony, pliki, e-maile i webhooki;
magazyn dokumentów, indeks wektorowy i pamięć rozmów;
modele własne i dostawców zewnętrznych;
narzędzia, tokeny oraz systemy docelowe;
logi, tracing, analitykę i systemy feedbacku;
mechanizmy zatwierdzania przez człowieka.

Następnie utwórz hipotezy w formie „atakujący kontrolujący X może osiągnąć Y przez Z”. Na przykład: autor zgłoszenia może ukryć instrukcję, która skłoni agenta obsługi do pobrania prywatnego załącznika i wysłania go do zewnętrznego URL. Takie hipotezy są bardziej wartościowe niż losowa lista jailbreaków.

NIST AI Risk Management Framework: Generative AI Profile podkreśla zarządzanie ryzykiem generatywnej AI w całym cyklu życia. W praktyce red teaming dostarcza dowodów dla scenariuszy, których nie da się ocenić samą dokumentacją.

Krok 3: zaprojektuj bibliotekę scenariuszy

Biblioteka powinna łączyć kategorie techniczne z procesem biznesowym. Dobry zestaw obejmuje co najmniej poniższe grupy.

Prompt injection i konflikt instrukcji

Testuj instrukcje bezpośrednie i pośrednie, różne języki, kodowanie, role-play, fragmenty rozłożone na kilka wiadomości, obrazy z tekstem oraz dane pobierane przez narzędzie. Sprawdź, czy model traktuje treść dokumentu jako dane i czy operacja o skutku ubocznym wymaga potwierdzenia.

Ujawnienie danych

Próbuj wydobyć system prompt, historię innej sesji, dokument innego tenanta, sekrety z logu oraz dane znajdujące się poza uprawnionym zakresem. Pytania powinny obejmować cytowanie, streszczenie, transformację i zgadywanie fragmentów. Zabezpieczenia prywatności opisujemy szerzej w artykule jak chronić PII w aplikacjach AI.

RAG i poisoning

Dodaj dokument z fałszywą informacją, instrukcją oraz metadanymi podszywającymi się pod zaufane źródło. Mierz pozycję w retrieval, wpływ na odpowiedź, trwałość po usunięciu i widoczność między użytkownikami. Sprawdź, czy autor treści może wpływać na decyzje agentów, którzy przeczytają ją później.

Narzędzia, autonomia i eskalacja skutku

Próbuj zmienić parametr po ekranie zgody, użyć zasobu innego właściciela, wywołać narzędzie administracyjne, ominąć limit przez serię mniejszych akcji i przekonać agenta do samodzielnego rozszerzenia celu. Łącz narzędzia odczytu i wysyłania, bo ich kompozycja często tworzy kanał eksfiltracji.

Improper output handling

Skłaniaj model do zwracania HTML, JavaScriptu, poleceń powłoki, ścieżek plików i adresów wewnętrznych. Obserwuj, czy wynik trafia do przeglądarki, interpretera, bazy albo kolejnego API. Model nie powinien być traktowany jako zaufany generator kodu.

Odporność i koszt

Testuj bardzo długie wejścia, rekurencyjne zadania, równoległość, retry, pliki o dużej dekompresji i niekończące się wywołania narzędzi. Zweryfikuj limity na użytkownika, organizację, zadanie i cały system. Kategorie te odpowiadają między innymi ryzykom opisanym w OWASP Top 10 LLM 2025.

Krok 4: automatyzuj, ale zachowaj testy ręczne

Automatyczny harness pozwala wysyłać warianty, zapisywać konfigurację, powtarzać test po aktualizacji i porównywać modele. Każdy przypadek powinien posiadać identyfikator, warunek wstępny, wejście, oczekiwane zachowanie, dowód i regułę oceny.

Automatyczna ocena przez drugi model przyspiesza analizę, ale nie może być jedynym sędzią. LLM-as-a-judge również jest podatny na prompt injection, uprzedzenia i niestabilność. Dla krytycznych scenariuszy potrzebna jest deterministyczna kontrola lub przegląd człowieka. Przykładowo wywołanie niedozwolonego endpointu można ocenić z logu, niezależnie od treści odpowiedzi.

Testy ręczne pozostają ważne w wieloetapowych rozmowach, szukaniu nieoczywistych kombinacji i ocenie kontekstu biznesowego. Doświadczony tester obserwuje, w jaki sposób model interpretuje cel, i adaptuje następny krok, zamiast tylko podmieniać synonimy.

Jak mierzyć wynik AI red teamingu

Jedna liczba „odporność 87%” bywa myląca. Wynik zależy od zestawu promptów, modelu, losowości i reguły oceny. Lepszy raport pokazuje kilka metryk:

attack success rate dla określonej rodziny i wersji testu;
severity-weighted success, czyli wynik ważony skutkiem;
powtarzalność w kilku uruchomieniach;
czas i liczba prób do sukcesu;
zasięg danych lub uprawnień dostępnych po ataku;
odsetek poprawnych blokad i false positive;
koszt oraz opóźnienie kontroli;
regresję wobec poprzedniej wersji.

Najważniejszy jest dowód skutku. Wygenerowanie fragmentu niepożądanej treści ma inną wagę niż odczyt dokumentu innego klienta lub wykonanie przelewu. Ocena powinna uwzględniać prawdopodobieństwo, wymagany dostęp, wykrywalność, skalę i możliwość automatyzacji.

Jak powinien wyglądać raport

Raport techniczny powinien zawierać wersje komponentów, konfigurację testu, scenariusz, pełny łańcuch danych i operacji, dowód, skutek, ograniczenia oraz rekomendację. Dla zachowań probabilistycznych podaj liczbę prób i częstość sukcesu. Dla naruszenia autoryzacji pokaż niezależny dowód z logu lub systemu docelowego.

Przydatnym dodatkiem jest mapa kontroli do OWASP Top 10 LLM i wewnętrznego rejestru ryzyka. Osobna sekcja powinna wskazywać luki w obserwowalności — przypadki, w których atak zadziałał, ale monitoring go nie wykrył.

Remediacja musi trafiać do właściwej warstwy. Zmiana promptu może ograniczyć prosty jailbreak, ale błąd autoryzacji naprawia się w API. Nadmierną autonomię usuwa się przez scope, podział narzędzi i zatwierdzenie transakcji. Poisoning ogranicza się kontrolą źródeł i procesu indeksowania.

Retest i ciągła ewaluacja

System AI zmienia się nawet bez modyfikacji kodu aplikacji. Dostawca aktualizuje model, zespół zmienia prompt, baza RAG rośnie, a nowe narzędzie rozszerza możliwości agenta. Dlatego wynik testu ma jasno określony kontekst wersji.

Najważniejsze przypadki powinny wejść do zestawu regresyjnego uruchamianego po zmianie modelu, promptu, danych, polityki lub narzędzia. Produkcja potrzebuje monitoringu nadużyć, kosztu, nietypowych sekwencji akcji i jakości odpowiedzi. Więcej o tym procesie znajdziesz w przewodniku guardraili i ciągłego monitoringu AI.

Checklista przed rozpoczęciem testu

Czy zakres wymienia wszystkie modele, prompty, kolekcje i narzędzia?
Czy uzgodniono nieakceptowalne skutki biznesowe?
Czy istnieje sandbox dla operacji zapisu i płatności?
Czy określono limit kosztu oraz procedurę awaryjnego zatrzymania?
Czy tester ma konta dla różnych ról i tenantów?
Czy logi pozwalają potwierdzić rzeczywiste wywołanie narzędzia?
Czy scenariusze obejmują model, aplikację, RAG, agentów i infrastrukturę?
Czy wyniki probabilistyczne są powtarzane i raportowane z częstością?
Czy krytyczne przypadki zostaną zachowane jako regresja?
Czy właściciel każdej poprawki jest wskazany przed retestem?

AI red teaming daje największą wartość, gdy łączy kreatywność testera z inżynierską powtarzalnością. Nie chodzi o kolekcjonowanie efektownych jailbreaków, lecz o wykazanie, jakie aktywo może ucierpieć i która kontrola zatrzyma atak. Jeśli przygotowujesz chatbota, RAG lub agenta do produkcji, skontaktuj się z nami — zaprojektujemy test obejmujący zarówno warstwę AI, jak i klasyczne bezpieczeństwo aplikacji.