Red teaming AI wyjaśniony: co testuje red team i co po sobie pozostawia

Większość przedsięwzięć z zakresu red teamingu AI ocenia się na podstawie niewłaściwego artefaktu. Tydzień pracy kończy się prezentacją, prezentacja głosi, że asystenta można nakłonić do napisania e-maila phishingowego, a potem nikt nie potrafi powiedzieć, czy to zachowanie było powtarzalne, jak poważne było ani która kontrola by je powstrzymała. Ta dyscyplina ma realny produkt i nie jest nim prezentacja: to zestaw ustaleń, które przetrwają ponowne uruchomienie, każde powiązane z przekroczoną granicą i z dowodami, które ją przekroczyły. Taki jest też kształt rejestru, który archiwum incydentów AI prowadzi — 400 wpisów obejmujących okres od grudnia 2024 r. do października 2026 r., pochodzących z 743 różnych źródeł, oraz werdykt dla każdego z nich mówiący, czy komukolwiek faktycznie stała się krzywda.

To zamieszanie jest zrozumiałe, ponieważ „red teaming” odnosi się do dwóch zadań, które łączy słownictwo i niewiele więcej. Ten przewodnik dotyczy obu z nich, dowodów, jakie każde powinno dostarczyć, oraz czterech obszarów, w których red teaming AI naprawdę odbiega od wersji sieciowej, którą większość zespołów bezpieczeństwa potrafi już prowadzić.

Pytanie o framework: kto jest właścicielem testu

Zanim przejdziemy do zakresu, pojawia się pytanie, kto prowadzi ćwiczenie i przeciwko czemu. Microsoft publikuje jedno z bardziej kompletnych publicznych stanowisk w tej sprawie i warto je czytać jako mapę, a nie jako stronę produktową. Jego centrum AI Red Team oddziela koncepcję red teamingu AI od instrukcji praktycznych, a następnie porządkuje tę praktykę w kolejności, która sama w sobie jest argumentem: przegląd, potem przewodnik po budowaniu zespołu red team do LLM, a następnie materiały referencyjne — próg istotności błędów do triażu ataków na systemy uczenia maszynowego, taksonomia awarii uczenia maszynowego, model wspólnej odpowiedzialności oraz wytyczne dotyczące modelowania zagrożeń dla deweloperów.

Przeczytaj sekwencję, a metodologia sama z niej wynika. Pewna taksonomia decyduje, co liczy się jako porażka. Pewien próg błędu decyduje, która z tych porażek jest warta naprawy. Pewien model wspólnej odpowiedzialności decyduje, kto ponosi za nią odpowiedzialność, gdy zostanie znaleziona. Modelowanie zagrożeń decyduje, gdzie szukać dalej. Bez tych czterech elementów zespół red team generuje anegdoty z doklejoną kolumną istotności, a kolumna istotności jest tym, co tester czuł tego popołudnia.

Otwarty framework automatyzacji Microsoftu, PyRIT, trafia na tę samą półkę i to właśnie to umiejscowienie jest przydatne. Zestaw do orkiestracji nie jest metodologią; to narzędzie, w które celuje się po ustaleniu taksonomii i progu błędów. Zespoły, które zaczynają od frameworka, zwykle kończą z dużym korpusem promptów i bez sposobu na uszeregowanie wyników.

Dwa czerwone zespoły, dwa różne pytania

Najbardziej użytecznym rozróżnieniem w tej dziedzinie jest to, o którym prawie nikt nie pisze: zespół red team testujący model i zespół red team testujący system odpowiadają na różne pytania, mając do czynienia z różnymi jednostkami podlegającymi testowaniu, różnymi wynikami i różnymi właścicielami. Mieszanie ich prowadzi do tego, że jailbreak zostaje zgłoszony jako ustalenie z zakresu bezpieczeństwa, a prawdziwy błąd eskalacji uprawnień trafia do rejestru jako skarga dotycząca jakości modelu.

Ocena bezpieczeństwa na poziomie modelu to problem pomiarowy. Pytasz, czy model wygeneruje daną kategorię treści, a uczciwa odpowiedź wymaga próby wystarczająco dużej, by móc coś powiedzieć o wskaźniku. Jednostką badaną jest model stojący za cienkim API, metodą jest promptowanie adwersarialne — jailbreak'i, ataki z użyciem persony, presja w wielu turach — a wynikiem jest transkrypt wraz z oceną szkodliwości. Gdy zmienią się wagi lub przesunie się warstwa bezpieczeństwa dostawcy, cały wynik staje się nieaktualny. Dlatego tego rodzaju test zwykle przeprowadza twórca modelu lub niezależny ewaluator i dlatego jego ustalenia rzadko przekładają się na konkretną poprawkę w Twojej aplikacji.

Emulacja przeciwnika na poziomie systemu to problem inżynierski. Pytasz, czy atakujący może skłonić wdrożony element do działania — odczytania pliku, którego nie powinien, wywołania narzędzia, którego nie powinien, wydania pieniędzy, których nie powinien. Jednostką badaną jest agent wraz z przypisanymi do niego narzędziami, mechanizmami wyszukiwania i poświadczeniami. Metody są znane, ale przekierowane: wstrzykiwanie przez pobraną treść, a nie przez turę użytkownika, nadużywanie narzędzi, łańcuchy uprawnień złożone z pojedynczo rozsądnych uprawnień, ścieżki danych, które wyciekają poza granicę dzierżawcy. Wynikiem jest znalezisko z reprodukcją, przekroczoną granicą i właścicielem, który może zmienić konfigurację jutro.

Te dwa dają niekompatybilne artefakty, a ta niekompatybilność jest diagnostyczna, a nie irytująca. Wyniku na poziomie modelu twój zespół nie może „naprawić” inaczej niż przez zmianę modelu. Wyniku na poziomie systemu dostawca nie może naprawić w ogóle. Jeśli raport nie mówi, którym z tych dwóch jest, nie możesz przypisać żadnego z jego elementów.

Jak zmienia się powierzchnia ataku, gdy model ma narzędzia

Powierzchnia, którą większość zespołów wciąż testuje, to prompt. Jest też najmniej interesująca, ponieważ to właśnie na jej zabezpieczenie dostawca modelu poświęcił najwięcej pracy, a atakujący ma nad nią najmniejszą kontrolę. Powierzchnie, które faktycznie się opłacają, to te dodane przez aplikację: narzędzia, które agent może wywoływać, indeks wyszukiwania, z którego czyta, pamięć, którą przenosi między turami, oraz sam kanał wyjściowy.

Narzędzia to miejsce, w którym model językowy staje się aktorem, a ciekawe pytanie nigdy nie brzmi „czy potrafi wywołać narzędzie”, lecz „jakie najmniejsze uprawnienia mogło mieć to narzędzie”. Narzędzie do wyszukiwania zgłoszeń, które przyjmuje zapytanie w dowolnym tekście, zazwyczaj da się nakłonić do przyjęcia identyfikatora innego klienta. Odzyskiwanie to kanał treści do kontekstu modelu, co oznacza, że każdy, kto może pisać do korpusu — dysk współdzielony, makro obsługi klienta, strona internetowa, do której dociera mechanizm pobierający — pisze do promptu. Pamięć zamienia pojedynczą turę w trwałość: instrukcja zaszyta w drugiej turze nadal tam jest w czterdziestej turze. Dane wyjściowe to miejsce, w którym tekst modelu trafia gdzieś, co go interpretuje, a renderowanie, markdown, podglądy linków i potoki powiązane z powłoką — wszystkie interpretują tekst.

Zlecenie, które testuje wyłącznie prompt, przyniesie czysty wynik i będzie miało rację w niewłaściwej sprawie.

Dlaczego transkrypt nie jest ustaleniem

Znalezisko musi mieć trzy właściwości, których zrzut ekranu okna czatu nie ma. Pierwszą jest powtarzalność: uruchom to ponownie z czystego stanu, a problem wystąpi znowu. Modele są niedeterministyczne, więc powtarzalność jest wskaźnikiem, a nie wartością logiczną — „dziewięć na dziesięć prób” to znalezisko, „zdarzyło się raz” to plotka. Drugą jest przekroczona granica: nazwij rzecz, która nie powinna była się zdarzyć, językiem samej aplikacji, a nie modelu. Nie „model był nieuprzejmy”, ale „agent odczytał dokument należący do dzierżawcy B”. Trzecią jest waga, którą można powiązać z wpływem, a nie z intuicją testera, i właśnie do tego służy próg błędów.

Wszystko inne — transkrypt, prompt, rozumowanie modelu — jest dowodem wspierającym te trzy. To nie jest samo ustalenie, i dlatego korpus dwóch tysięcy promptów jailbreakowych jest wart mniej niż pięć odtwarzalnych ustaleń systemowych z dołączonymi nazwanymi kontrolami.

Cztery obszary, w których red teaming AI różni się od red teamingu sieciowego

Zespoły przechodzące z obszaru bezpieczeństwa sieciowego lub bezpieczeństwa aplikacji wnoszą dobre instynkty i cztery błędne założenia.

• Nie ma obwodu, którego można by strzec. Zlecenie sieciowe ma listę celów; zlecenie dla agenta ma okno kontekstu budowane w momencie żądania ze źródeł, których być może nie zinwentaryzowano. Zakres trzeba wyrazić jako źródła danych i uprawnienia narzędzi, a nie nazwy hostów.

• Cel jest niedeterministyczny. Ten sam sygnał wejściowy może zakończyć się sukcesem we wtorek, a w środę porażką. Łamie to standard dowodowy „jednej czystej reprodukcji” i zmusza do raportowania wskaźników.

• Wektorem ataku jest język, a języka nie da się załatać. Można naprawić brakującą kontrolę autoryzacji. Nie da się załatać tego, że „model można przekonać”. Mitygacją słabości na poziomie języka jest kontrola ulokowana gdzie indziej — filtr, ograniczenie zakresu, granica uprawnień — dlatego w ustaleniach trzeba wskazać kontrolę, a nie tylko samo zachowanie.

• Dostawca jest w pętli. Twój cel zmienia się, gdy ktoś inny wydaje wersję. Wynik na poziomie modelu jest ważny tylko dla kompilacji, którą testowałeś, a jeśli nie zapisałeś wersji i daty, nie masz wyniku.

Jak określić zakres pierwszej współpracy

Zadania, które idą źle, są prawie zawsze zakresowane jako „przetestować AI”. Zakres, który przetrwa zderzenie z harmonogramem, wygląda bardziej tak: jeden agent, w środowisku stagingowym, z danymi i uprawnieniami w kształcie produkcyjnym; lista pięciu granic, które mają znaczenie (izolacja najemców, dostęp do poświadczeń, wydatki, eksfiltracja danych, zakres narzędzi); zasady prowadzenia działań, które wskazują, co jest poza dopuszczalnymi granicami; warunki zatrzymania, które określają, kto może wstrzymać przebieg; oraz zdefiniowany format dowodów uzgodniony przed pierwszą próbą, tak aby raport był składany z artefaktów, a nie rekonstruowany z pamięci.

Autoryzacja zasługuje na osobne zdanie, ponieważ to właśnie ten element zespoły pomijają, gdy celem jest ich własny produkt, a narzędzia należą do kogoś innego. Testowanie modelu, którym się nie zarządza, na infrastrukturze, której się nie posiada, za pomocą promptów zaprojektowanych tak, aby ominąć warstwę zabezpieczeń, to inna czynność niż testowanie własnego wdrożenia — i to właśnie pisemny zakres oddziela jedno od drugiego. Brama weryfikacyjna, z której korzysta nasza własna warstwa cyber, istnieje z tego samego powodu: autoryzowana praca w zakresie bezpieczeństwa na poziomie modelu wymaga imiennie wskazanej, odpowiedzialnej strony po obu stronach.

Co dodaje zapis incydentu

Przeprowadzenie testu red team mówi ci, co robi twój cel. Nie powie ci, co dzieje się w rzeczywistych warunkach, a to tam faktycznie powstaje uzasadnienie dla mechanizmu kontroli. Tę lukę wypełnia rejestr incydentów — a dyscyplina, którą narzuca, jest jego użyteczną częścią: rekord bez co najmniej jednego źródła nie istnieje, a rekord bez rozstrzygnięcia w sprawie szkody nie jest incydentem.

Przeczytaj oba artefakty razem, a pętla się zamyka. Zespół red teamu tworzy powtarzalne ustalenie i wskazuje mechanizm kontrolny, który by je zablokował. Rejestr mówi ci, czy ktokolwiek w terenie już natrafił na tę granicę, jaka była szkoda i czy mechanizm kontrolny sprawdził się gdziekolwiek indziej. Ustalenie bez precedensu terenowego to hipoteza warta naprawy; incydent terenowy bez powtarzalnego ustalenia to błąd, którego nie możesz jeszcze zamknąć. Zespoły, które robią to dobrze, przestają traktować „przeprowadziliśmy red team modelu” jako produkt dostarczany, a zaczynają traktować to jako jedno wejście do własnego rejestru.

Co pozostawia uczciwą uwagę końcową. Red teaming AI nie daje gwarancji bezpieczeństwa, a każde zlecenie sprzedawane jako taka gwarancja sprzedaje nie to, co trzeba. Daje natomiast zestaw granic, o których wiadomo już, że zostały przekroczone, wraz z dowodami, które można odtworzyć, uporządkowanych według tego, co się dzieje, gdy do przekroczenia dochodzi. To wystarczy do podejmowania decyzji — i znacznie więcej niż prezentacja.