Przejdź do głównej zawartości

Red Teaming AI (Dursey): recenzja, kontrola przypisów i plan red teamu AI w kancelarii

· 14 min aby przeczytać
Przemysław Majdak
AI dla kancelarii i bezpieczeństwo AI

„Red Teaming AI" Philipa A. Durseya (2025) to ponad 900 stron o tym, jak atakować systemy uczące się: od zatruwania danych, przez kradzież modelu, po prompt injection. Część o mechanizmach ataków jest dobra, ale w druku zostały polecenia do autora i placeholdery w bibliografii. Sprawdziłem więc 34 losowe przypisy: do źródła, które mówi to, co podano, prowadzi 24, dwóch cytowanych prac nie udało się znaleźć, a w czterech lista autorów nie zgadza się z rzeczywistą. Ten wpis to recenzja i mapa serii, w której nie streszczam książki, tylko atakuję stos AI, jaki wdrażam w kancelariach.

O książce​

Autor: Philip A. Dursey, wydawca AI Security LLC, ©2025. PDF ma 1060 stron, z czego tekst główny to 910 stron druku, dalej glosariusz, bibliografia rozdziałów i kompendium narzędzi. Strony podaję według numeracji druku.

CzęśćRozdziałyStronyCo zawiera
I. Foundations1-31-78czym ryzyko AI różni się od klasycznego, definicja red teamingu, metodyka
II. Attack Tools & Techniques4-1179-376zatrucie danych, evasion, ekstrakcja modelu, membership inference, prompt injection, infrastruktura, prywatność, socjotechnika
III. AI Red Teaming in Action12-19377-676rekonesans, narzędzia, red team LLM, wizji, mowy i innych domen, obejścia, raport
IV. Building Resilient AI Systems20-21677-760obrony, red teaming w cyklu wytwarzania
V. Strategy, Foresight, and Responsibility22-25761-910budowa zespołu, zagrożenia przyszłości, regulacje i etyka

Czym atak na AI różni się od pentestu​

To jest pytanie, od którego książka zaczyna, i najlepsza część pierwszych trzech rozdziałów. W klasycznej aplikacji logika siedzi w kodzie, więc pentest sprawdza kod i infrastrukturę wokół niego. W systemie uczącym się logika powstaje z danych: „Unlike traditional software where logic is fixed in code, ML model logic emerges from data during training" (rozdz. 1, s. 12). Skaner kodu tej warstwy nie widzi: „Code scanners simply don't see these semantic or data-driven flaws" (rozdz. 1, s. 11).

Dursey odróżnia red teaming AI od pentestu obrazem, który dobrze się zapamiętuje: pentest to „checking the locks on the doors and windows of the AI lab" (rozdz. 2, s. 28). Jego ilustracja: system antyfraudowy przechodzi pentest (SQLi, XSS, konfiguracja), a pół roku później przepuszcza oszustwa, bo ktoś nauczył się delikatnie zmieniać wzorce transakcji (rozdz. 2, s. 40). Autor nie podaje źródła, więc traktuję to jako przykład, a nie opis incydentu.

Ta sama obserwacja pada niezależnie u Donniego Wendta w „The Cybersecurity Trinity": system uczący się w środowisku z przeciwnikiem trzeba budować, „assuming it will be attacked in all phases" (Wendt, s. 132), a chronionym artefaktem są dane i model, nie kod źródłowy (s. 134). Jedno zastrzeżenie: pentest też jest próbką, a nie dowodem braku podatności. Różnica nie leży w kompletności testu, tylko w jego przedmiocie.

Moje streszczenie tej różnicy: model jest jednocześnie danymi, kodem i konfiguracją. Kto pisze do danych treningowych albo do bazy wiedzy, ten pisze reguły. Kto czyta odpowiedzi modelu, ten mierzy jego granicę decyzyjną i dane, na których się uczył. Kto podmienia plik modelu, podmienia kod, bo plik w formacie pickle wykonuje kod przy ładowaniu. Każdy z tych trzech kanałów dostanie w serii osobny pomiar.

Z rozdziału 3 biorę jedną zasadę, która przyda się przy każdym raporcie: „Validate the consequences, not just the vulnerability" (rozdz. 3, s. 69). Partnera kancelarii nie interesuje, że model dał się namówić na zignorowanie instrukcji. Interesuje go, czy przez to wyciekły akta albo zmienił się termin w streszczeniu pisma.

Co jest mocne​

Taksonomia ataków w części II. Rozdziały 4-10 przechodzą przez klasyczne ataki na uczenie maszynowe i odwołują się do prac, od których ta dziedzina się zaczęła: Goodfellow, Madry, Carlini i Wagner, Athalye (obfuscated gradients), Tramèr (kradzież modelu), Shokri (membership inference). Czytane razem dają jedną oś, której autor wprost nie nazywa: odpowiedź modelu jest pomiarem. Pewność klasyfikatora, embedding, a nawet samo „tak/nie" pozwalają zmapować granicę decyzyjną (evasion), skopiować model (ekstrakcja), sprawdzić, czy rekord był w danych treningowych (membership inference), i odtworzyć te dane (inwersja). Wniosek, który z tego wyciągam: każda obrona, która ogranicza wyjście, podnosi koszt ataku, ale go nie usuwa.

Prywatność jako przepływ, nie tajność. Rozdział 10 opiera się na ramie contextual integrity Helen Nissenbaum (s. 298-304): naruszeniem prywatności jest przepływ informacji poza kontekst, w którym ją powierzono, a nie tylko ujawnienie nazwiska. To najlepsza rama pojęciowa w książce i dokładnie ta, której potrzeba przy ocenie anonimizacji akt. Usunięte imię i nazwisko nie wystarczą, gdy w piśmie zostają zawód, miejscowość, data i kwota.

Eksfiltracja przez render Markdowna (rozdz. 8, s. 237 i 242). Odpowiedź modelu z obrazkiem, którego adres zawiera dane, wysyła te dane w chwili, gdy interfejs czatu wyrenderuje obrazek. Model nie potrzebuje do tego żadnego narzędzia. W serii o wzorcach GenAI pisałem o zabezpieczeniach i o agentach z narzędziami; ten kanał działa bez nich.

Zasada, którą autor stawia najmocniej: obrona testowana tylko znanymi atakami testuje samą siebie. Rozdział 5 wymaga ataku adaptacyjnego, czyli pisanego przez kogoś, kto zna obronę: „defenses must be evaluated against adaptive attackers aware of the defense" (s. 146). Glosariusz słusznie ostrzega, że gradient masking „can give a false sense of security" (s. 930-931).

Słabe punkty​

Książka nie stosuje własnej najmocniejszej zasady. Rozdział 20 każe testować obrony „known TTPs" (s. 685) i „known bypasses" (s. 697), a rozdział 21 proponuje jako próg wydania odsetek znanych promptów jailbreak, które przechodzą przez filtr (s. 725-726). Taki test przypina konkretne prompty, a nie zamyka klasy ataku. Pisałem o tym przy garaku po polsku: zero procent w skanerze nie znaczy, że model jest odporny.

Druk wygląda na nieskończoną redakcję. Sprawdziłem w PDF miejsca, które zanotowałem przy lekturze:

  • polecenie do autora zamiast historii: „WAR STORY: Emergent Behavior Leading to Policy Violation - Describe a scenario where an LLM developed an unexpected capability…" (rozdz. 3, s. 52), i drugie takie w rozdziale 17: „WAR STORY: Detail a specific instance (simulation, game, research paper) of an RL agent reward hacking… Add citation(s) if applicable." (s. 573);
  • notatki w bibliografii: „(Note: Representative placeholder; verify specific relevant NIST pubs.)" (s. 19), „(Reviewer Note: Verify/update date if placeholder)" (s. 75), „(Note: Added 'et al.' as typical for arXiv papers…" (s. 253);
  • trzy pozycje bibliografii rozdziału 23 to „[CITE REQUIRED: …]" bez źródła (s. 846-847), a przy raporcie Gladstone AI stoi „(Note: Add specific URL if available, otherwise cite as internal or pre-publication report)" (s. 846);
  • w tekście głównym zostało odwołanie „[i]-[j]" zamiast numerów przypisów (s. 4).

Moja hipoteza: tak wygląda tekst redagowany z pomocą modelu językowego bez końcowej korekty. Autor tego nie deklaruje. Takie ślady widziałem już w innej książce: w „Supply Chain Software Security" Aamiruddina Syeda (Apress, 2024) w druku została cała odpowiedź modelu: „Based on the information provided in the document and your request for a chapter focusing on (…), here is a section that addresses these topics" (Syed, s. 24). Niezależnie od przyczyny, przypis w książce Durseya nie jest dowodem, że źródło istnieje i mówi to, co podano. Dlatego zmierzyłem, jak często tak jest.

Autopromocja. Metodyka STRATEGEMS jest opisana jako „the author's proprietary implementation framework" (s. 61) na poziomie haseł, a wśród platform do testów autor wymienia jako pierwszą „HYPERGAME INJX" (s. 68), czyli tę samą markę. Glosariusz opisuje STRATEGEMS jako metodykę „developed by an entity called HYPERGAME" (s. 957-958), bez wzmianki, że to firma autora.

Część V. Jeden raport Gladstone AI odpowiada za 44 ze 122 odwołań do przypisów w tekście rozdziału 22 i za 29 z 49 w rozdziale 23 (moje liczenie skryptem po tekście PDF). Rozdział 23 to poza tym futurologia, rozdział 24 ma wyraźną ramę ideologiczną. Te rozdziały pomijam w serii poza mostem do AI Act.

Pomiar: czy przypisy prowadzą do źródła​

Pytanie: jeśli wezmę z tej książki twierdzenie z przypisem, jak często przypis prowadzi do istniejącego źródła, które mówi to, co podano?

Metoda. Wyciągnąłem tekst PDF i skryptem rozdzieliłem bibliografie rozdziałów 4-10 i 14-23 (rozdziały o mechanizmach ataków i ich testowaniu, z bibliografią opartą na pracach naukowych). W tych 17 rozdziałach jest 327 pozycji bibliografii, z czego 310 jest cytowanych w tekście (według mojego parsowania). Z każdego rozdziału wylosowałem dwa cytowane przypisy (stałe ziarno, razem 34) i dla każdego zapisałem zdanie, które przypis ma podpierać. Źródła sprawdzały agenty Claude'a z dostępem do sieci, czytając abstrakt albo pełny tekst i zapisując dosłowny cytat ze źródła z adresem. Werdykty „nie znaleziono" sprawdziłem dodatkowo sam, osobnym wyszukiwaniem. Kategorie:

  • A: źródło istnieje i podpiera twierdzenie (przy ogólnikowym twierdzeniu wystarczy, że źródło jest na temat);
  • B: istnieje, ale twierdzenie jest przesunięte: inna liczba, szerszy zakres, szczegół dopisany;
  • C: istnieje, ale nie podpiera twierdzenia albo mówi coś innego;
  • D: nie udało się znaleźć źródła;
  • ?: nie dało się sprawdzić (paywall).

Osobno flaga błędnych danych bibliograficznych: autorzy, rok, miejsce publikacji, martwy adres.

Wynik:

WerdyktLiczbaUdział
A: podpiera2471%
B: przesunięte39%
C: nie podpiera39%
D: nie znaleziono źródła26%
?: paywall26%
błędne dane bibliograficzne (niezależnie od werdyktu)926%

24 z 34 to 71%, a 95-procentowy przedział ufności (Wilson) dla takiej próby to 54-83%. Przy 34 przypisach nie da się powiedzieć więcej niż „mniej więcej siedem na dziesięć". W rozdziałach 4-10 wynik to 10 z 14, w rozdziałach 14-23 to 14 z 20. Różnica mieści się w szumie tak małej próby, ale oba werdykty D wypadły w rozdziale 17.

Przykłady, które pokazują, jak wyglądają błędy:

  • Szczegół dopisany do źródła (B). Książka opisuje BadNets jako atak, po którym znak stop z naklejką jest czytany jako „Speed Limit 80" (s. 87). Praca Gu i in. mówi o klasie „speed-limit"; liczby 80 ani „mph" w jej tekście nie ma.
  • Źródło na inny temat (C). Przy CVE-2024-0132 w NVIDIA Container Toolkit (s. 277) przypis prowadzi do artykułu o styczniowych łatkach sterowników GPU (CVE-2024-0150, CVE-2024-0146), w którym CVE-2024-0132 nie pada.
  • Pozycje, których nie udało się znaleźć (D). „Adversarial poisoning attacks on reinforcement learning-driven adaptive bitrate algorithms" (AISec '22): nie ma jej w spisie tych warsztatów w Crossref i nie znalazłem jej wyszukiwarką. „Adversarial Learning in Real-World Fraud Detection: Challenges, Advances, and Opportunities" (ACM Computing Surveys, 2024): nie ma go w podanym tomie i numerze (Crossref); najbliższa jest praca innych autorów o tytule kończącym się na „Challenges and Perspectives" (Lunghi i in., 2023).
  • Prawdziwa praca, cudzy autorzy. Pod adresem z bibliografii rozdziału 23 jest praca „Automated Penetration Testing Using Deep Reinforcement Learning" autorstwa Hu, Beurana i Tana. Książka przypisuje ją komuś innemu i umieszcza na innej konferencji. W czterech z 34 przypisów lista autorów nie zgadza się z rzeczywistą; przy pracy Nasra i in. o ekstrakcji danych z ChatGPT pojawiają się „M. Carlini" i „K. Tramer", których wśród autorów nie ma.

Prawdziwy tytuł z obcymi autorami i wiarygodnie brzmiący tytuł, którego nie ma, to błędy, jakie zostawia model językowy uzupełniający bibliografię. Że tak powstała ta bibliografia, to znowu moja hipoteza, a nie ustalenie.

Numeracja przypisów w rozdziale 14 nie trzyma się bibliografii. Tekst odwołuje się do przypisów [27]-[36] (np. s. 465-470), a bibliografia rozdziału ma 26 pozycji. Numery w tekście są przesunięte względem bibliografii, więc czytelnik, który idzie za numerem, trafia na inną pracę. Jeden z werdyktów C (przypis przy narzędziu garak prowadzi do wpisu o odtwarzaniu danych treningowych) najpewniej wynika właśnie z tego przesunięcia, ale dla czytelnika efekt jest ten sam.

Trzy miejsca znane z lektury​

Przy czytaniu zanotowałem trzy liczby do sprawdzenia. Po sprawdzeniu w źródłach:

KsiążkaŹródłoOcena
„up to 15% of an LLM's output text was found to match content from its training set, sometimes revealing entire paragraphs of copyrighted or personal data" (s. 459)Aerni i in. (arxiv.org): do 15% tekstu z popularnych modeli konwersacyjnych pokrywa się z fragmentami z Internetu, przy zwykłych, nieatakujących promptachliczba istnieje, opis przesunięty: Internet jest tu przybliżeniem zbioru treningowego, a o danych osobowych praca nie mówi; numer przypisu w tekście prowadzi do innej pozycji
„over 5% of the tokens ChatGPT produced were exact copies of its training data" (s. 461)wpis autorów pracy Nasra i in. na blogu (not-just-memorization.github.io): „over five percent of the output ChatGPT emits is a direct verbatim 50-token-in-a-row copy from its training dataset"liczba jest w źródle, ale na blogu, nie w artykule naukowym (tam: dane treningowe emitowane 150 razy częściej niż przy normalnym działaniu); przypisy w tekście wskazują inne pozycje bibliografii
„Researchers demonstrated in late 2024 that using a second LLM to simply paraphrase (…) was highly effective at erasing the hidden signal" (s. 632)Kirchenbauer i in. (arxiv.org, czerwiec 2023): „We find that watermarks remain detectable even after human and machine paraphrasing"przypis mówi odwrotnie niż książka, a data się nie zgadza; tezę książki podpierają inne prace (np. Krishna i in. 2023), ale nie ta, którą podano

Wniosek dla serii. Siedem na dziesięć to za mało, żeby przypis z tej książki był dowodem, i za dużo, żeby go zignorować. Przypis służy mi jako wskazówka, gdzie szukać. Liczbę biorę dopiero ze źródła pierwotnego, a gdy źródło mówi co innego, piszę to wprost.

Ocena​

2/5. Część II (rozdziały 4-10) jest warta przeczytania jako mapa pojęć i lista odnośników do prac, od których zaczęła się ta dziedzina. Reszta powtarza tę samą taksonomię w formie procedur i jest redakcyjnie niedokończona. Na źródło faktów książka się nie nadaje. Dla kogo: dla kogoś, kto zna klasyczne bezpieczeństwo aplikacji i chce uporządkowanej listy ataków na ML, z nazwiskami i tytułami prac do doczytania. Kto chce wiedzieć, jak zaatakować konkretnego asystenta z LLM, więcej wyniesie z OWASP Top 10 for LLM i z samych prac źródłowych.

Dlaczego seria to red team, a nie streszczenie​

Książka daje mechanizmy. Liczby, które pokazują, czy te mechanizmy działają w praktyce, musiałbym i tak sprawdzać w źródłach, a część z nich (pomiar wyżej) się nie broni. Robię więc odwrotnie niż w serii o wzorcach GenAI: biorę z książki mechanizm ataku i sprawdzam go na stosie, który wdrażam w kancelariach. Ten stos to aplikacja do OCR akt, aplikacja do anonimizacji, wyszukiwanie po aktach (RAG) i lokalny asystent na modelu językowym uruchomionym na stacji z RTX 5090, bez wysyłania dokumentów do chmury.

Każdy wpis odpowiada na pytanie, które zadaje partner kancelarii: czy to może wyciec i którędy. Schemat stały: scenariusz z kancelarii (kto atakuje, co chce osiągnąć, jaka szkoda), mechanizm z książki ze stroną, pomiar na stacji na danych syntetycznych, co zadziałało jako obrona, czego nie da się naprawić, i pytania do dostawcy AI.

Zasady pomiarów:

  • Tylko dane syntetyczne. Akta, strony, kwoty i sygnatury są fikcyjne.
  • Model zawsze z nazwą i wersją. W poprzedniej serii ten sam test dawał na różnych modelach skrajnie różne wyniki, więc tam, gdzie się da, mierzę na dwóch modelach i podaję rozrzut między powtórzeniami.
  • Liczby z książki tylko po sprawdzeniu źródła. Gdy źródło mówi co innego, piszę to wprost.

Mapa serii​

#WpisRozdziałyPytanie kancelarii
0Recenzja i mapa serii (ten wpis)całośćczy tej książce można ufać
1Model zagrożeń kancelarii i rekonesans2, 3, 12, 19kto atakuje AI kancelarii i co zdradza sam interfejs
2Pismo od strony przeciwnej8, 14, 18czy ukryta instrukcja w piśmie przejdzie przez OCR i zmieni streszczenie
3Anonimizacja, która nie anonimizuje10, 7czy z zanonimizowanego pisma da się wskazać osobę
4Czy model zapamiętuje akta6, 7, 10, 14co zostaje w modelu douczonym na aktach
5Kto pisze do bazy wiedzy4, 9czy jeden dokument w RAG może zmienić odpowiedzi asystenta
6Obrony, raport i regulacje11, 19-24czy obrona wytrzyma atak pisany pod nią

Linki pojawią się w tabeli w miarę publikacji. Wpis 6 zamknie serię listą kontrolną audytu AI w kancelarii, zebraną z pomiarów we wpisach 1-5.