Ofensywne frameworki red-team dla agentów AI: Garak, PyRIT i Promptfoo w laboratorium

Jeśli budujesz albo wdrażasz agentów AI, prędzej czy później ktoś zada pytanie, którego nie da się odłożyć: „a sprawdziliśmy, czy da się to złamać?“. Red teaming agentów AI to właśnie ta kontrola — celowe atakowanie własnego systemu zanim zrobi to ktoś z zewnątrz. Problem w tym, że na rynku krąży kilka narzędzi o podobnej obietnicy, a każde rozwiązuje inny kawałek układanki. Ten tekst rozkłada na czynniki pierwsze trzy najczęściej wybierane: Garak, PyRIT i Promptfoo.

Które narzędzie do red teamingu agentów AI wybrać — krótka odpowiedź

Najkrócej, jak się da: Garak to skaner podatności samego modelu — uruchamiasz gotowe ataki przeciwko końcówce LLM i dostajesz szeroki przegląd słabości warstwy modelu. PyRIT to programistyczny framework Microsoftu do budowania własnych, wieloturowych scenariuszy ataku w Pythonie — najwięcej kontroli, najwięcej pracy. Promptfoo to narzędzie dla zespołów produktowych: testuje całą aplikację agentową, wpina się w CI/CD i mówi językiem podatności OWASP.

Reguła wyboru w jednym zdaniu: chcesz przeskanować model — bierzesz Garaka; chcesz napisać własny, sterowany atak na agenta — bierzesz PyRIT; chcesz testować aplikację przy każdym pull requeście — bierzesz Promptfoo. W praktyce dojrzałe zespoły używają więcej niż jednego, bo testują różne warstwy systemu. Resztę tekstu poświęcam temu, żeby ten wybór był świadomy, a nie zgadywany.

Wszystkie trzy mają otwarty kod i są darmowe w wersji podstawowej. Garak rozwija NVIDIA na licencji Apache 2.0, PyRIT pochodzi od Microsoftu i jest na licencji MIT, Promptfoo również ma rdzeń na MIT (z płatną nakładką dla dużych zespołów). Żadne z nich nie zamyka cię u jednego dostawcy modeli.

Czym właściwie jest red teaming agenta AI?

Red teaming to symulowany atak prowadzony po to, by znaleźć podatności, zanim znajdzie je prawdziwy przeciwnik. W kontekście agentów AI nie chodzi już tylko o to, czy model „powie coś brzydkiego“. Agent to model plus narzędzia, pamięć, dostęp do danych i zdolność do wykonywania wielokrotnych kroków — a każdy z tych elementów poszerza powierzchnię ataku.

Klasyczny pentest aplikacji webowej szuka dziur w kodzie i konfiguracji. Red teaming agenta szuka czegoś subtelniejszego: sposobów, by skłonić system probabilistyczny do zachowania, którego nie chcemy. Ten sam prompt zadany dwa razy może dać dwie różne odpowiedzi, więc pojedynczy test niczego nie dowodzi. Stąd nacisk na automatyzację i powtarzalność — sensowna ocena wymaga setek albo tysięcy prób, nie kilku ręcznych zapytań.

Jakie zagrożenia w ogóle testujemy?

Zanim wejdziemy w narzędzia, warto nazwać klasy zagrożeń, bo to one decydują, które narzędzie ma sens. Najczęściej weryfikuje się:

• Prompt injection — wstrzyknięcie instrukcji, która nadpisuje pierwotne polecenia systemowe (np. ukryte w treści dokumentu, który agent czyta); osobne laboratorium red-teamingu prompt injection pokazuje, jak to testować metodycznie.
• Jailbreak — obejście zabezpieczeń modelu tak, by wytworzył treść, której miał odmawiać.
• Eksfiltracja danych — wyciek danych wrażliwych, promptu systemowego albo zawartości bazy wektorowej (RAG).
• Treści szkodliwe i toksyczne — generowanie mowy nienawiści, instrukcji niebezpiecznych, dezinformacji.
• Halucynacje — pewne siebie zmyślanie faktów, w tym halucynacje nieistniejących pakietów albo adresów.
• Nadużycie uprawnień agenta — skłonienie agenta do wykonania akcji poza jego rolą albo do działania na cudzych zasobach (w nomenklaturze OWASP API: BOLA, BFLA); te ścieżki wyciąga na wierzch fuzzing wywołań narzędzi.

Garak, PyRIT i Promptfoo pokrywają te klasy w różnym stopniu i na różnych warstwach. To jest sedno różnicy między nimi.

Garak — skaner podatności na poziomie modelu

Garak (nazwa pochodzi od postaci ze świata Star Trek, oficjalnie rozwijany dziś przez NVIDIA) to narzędzie, które najprościej opisać jako „nmap dla modeli językowych“. Wskazujesz mu końcówkę LLM, on uruchamia bibliotekę gotowych ataków i raportuje, gdzie model się wyłożył. Sprawdza między innymi prompt injection, jailbreaki, halucynacje, generowanie treści toksycznych, wyciek danych, ataki oparte na kodowaniu (np. ukrywanie poleceń w Base64), generowanie złośliwego kodu czy halucynacje pakietów.

Co konkretnie Garak testuje?

Siłą Garaka jest skala gotowego arsenału. Narzędzie ma kilkadziesiąt modułów-prób (probes), a korpus ataków liczy ponad 150 różnych technik i tysiące szablonów promptów. Działa to w trzech trybach: próby statyczne odtwarzają znane exploity, próby dynamiczne oceniają odpowiedzi modelu pod kątem nowych słabości, a próby adaptacyjne iterują po nieudanych atakach, żeby generować coraz sprytniejsze warianty.

Po stronie oceny Garak używa detektorów — komponentów, które analizują odpowiedź modelu i orzekają, czy atak się powiódł. Detektor bywa prostym dopasowaniem łańcucha znaków, klasyfikatorem uczenia maszynowego albo osobnym modelem występującym w roli „sędziego“ (np. do oceny toksyczności). To ważne, bo jakość detektora przekłada się wprost na liczbę fałszywych alarmów w raporcie.

Gdzie Garak ma granice?

Garak świetnie pokrywa warstwę modelu, ale słabiej radzi sobie z warstwą aplikacji. Testuje końcówki modeli, nie pełne stosy aplikacyjne — jego pokrycie scenariuszy agentowych i RAG jest ograniczone. Innymi słowy: powie ci, czy sam model jest podatny na jailbreak, ale nie sprawdzi, czy twój agent z dostępem do narzędzia „wyślij e-mail“ da się nakłonić do rozesłania spamu. To nie jest wada — to świadomy zakres. Garak odpowiada na pytanie „jak odporny jest model, którego używam“, a nie „jak odporna jest moja aplikacja zbudowana na tym modelu“.

Garak integruje się też z NeMo Guardrails NVIDII, co czyni go naturalnym wyborem, jeśli już siedzisz w ekosystemie tej firmy. Jest na licencji Apache 2.0, bez płatnego poziomu — dostajesz całość za darmo.

PyRIT — framework do budowania własnych ataków

PyRIT (Python Risk Identification Tool) powstał wewnątrz Microsoftu — zaczął jako zbiór jednorazowych skryptów, gdy firma w 2022 roku zaczęła red teamować własne systemy generatywne, a dziś jest dojrzałym frameworkiem na licencji MIT, używanym przez zespół AI Red Team Microsoftu w setkach operacji. To nie jest skaner „włącz i czekaj na raport“. To biblioteka, z której składasz własny scenariusz ataku.

Na czym polega podejście PyRIT?

Tam, gdzie Garak uruchamia znane próby, PyRIT pozwala generować nowe — konfigurujesz orkiestrator, w którym jeden model (atakujący) atakuje drugi (twój cel). To otwiera drzwi do ataków, które trudno zakodować na sztywno: wieloturowych rozmów, w których przeciwnik stopniowo eskaluje, zamiast uderzać jednym promptem.

Framework dostarcza kilka cegiełek, które składasz wedle potrzeby:

• Ponad 50 zbiorów danych z gotowymi promptami przeciwnika — między innymi HarmBench, AdvBench czy XSTest — pokrywających treści szkodliwe, jailbreaki, eksfiltrację danych i uprzedzenia społeczne.
• Ponad 70 konwerterów promptów, które przekształcają atak, by ominąć filtry: Base64, ROT13, leetspeak, znaki mylące w Unicode, a także przeredagowanie przez inny model.
• Strategie ataku od prostego wysłania pojedynczego promptu, przez Crescendo (stopniowa eskalacja w kolejnych turach), po Tree of Attacks with Pruning (TAP) i ataki wieloturowe.

Do tego dochodzi silnik oceniający odpowiedzi. W jednym z ćwiczeń na systemie Copilot Microsoft wybrał kategorię zagrożenia, wygenerował kilka tysięcy złośliwych promptów i ocenił wyniki w kilka godzin zamiast tygodni — to dobrze pokazuje, do czego PyRIT jest stworzony.

Dla kogo jest PyRIT?

PyRIT jest dla badaczy bezpieczeństwa i inżynierów, którzy potrzebują pełnej kontroli nad przebiegiem ataku i nie boją się pisać Pythona. Architektura jest składalna — komponenty wymieniasz i łączysz, dodajesz obsługę nowych modeli i modalności. Cena za tę elastyczność jest oczywista: PyRIT wymaga więcej pracy niż uruchomienie skanera. Nie dostajesz raportu jednym poleceniem — dostajesz warsztat, z którego sam budujesz badanie. Jeśli twoim celem jest ustrukturyzowane testowanie polityk bezpieczeństwa z pełną kontrolą nad logiką, to jest twoje narzędzie.

Promptfoo — testowanie aplikacji w CI/CD

Promptfoo wychodzi z zupełnie innego punktu widzenia. To framework o otwartym kodzie do oceny modeli, który dorobił się modułu red teamingu i pentestu, i który myśli kategoriami aplikacji, nie samego modelu. Rozkłada tryby awarii LLM na modularne testery zwane wtyczkami (plugins), gdzie każda wtyczka generuje złośliwe ładunki celujące w konkretną słabość.

Co wyróżnia Promptfoo?

Po pierwsze, skala biblioteki wtyczek i ich organizacja. Promptfoo udostępnia ponad 150 wtyczek pogrupowanych w kategorie: marka, zgodność i kwestie prawne, zbiory danych, bezpieczeństwo i kontrola dostępu, zaufanie i bezpieczeństwo treści oraz wtyczki własne. Dzięki temu odwzorowuje testy wprost na uznane standardy — masz gotowe presety pod OWASP Top 10 dla aplikacji LLM oraz OWASP dla aplikacji agentowych. Wpisujesz owasp:llm na liście wtyczek i dostajesz zestaw testów pod całą tę listę zagrożeń.

Po drugie, orientacja na warstwę aplikacji i agenta. Promptfoo testuje całe stosy: chatboty, asystentów dokumentów, narzędzia wyszukujące i agentów przechodzących przez wieloetapowe procesy. Pokrywa rzeczy, których skaner modelu nie dotknie — na przykład BOLA (nieautoryzowany dostęp do zasobów innego użytkownika) i BFLA (wykonywanie akcji poza zakresem uprawnień roli), zatruwanie pamięci RAG czy eksfiltrację dokumentów.

Po trzecie — i to jest kluczowy argument dla zespołów produktowych — Promptfoo jest projektowany pod ciągłą integrację. Jeśli pracujesz w rytmie pull requestów, nocnych testów i pipeline’ów CI, wpina się tam naturalnie. Testujesz wcześnie i często, a nie raz przed wdrożeniem.

Status i licencja Promptfoo

Promptfoo działa na licencji MIT i jest używany przez zespoły w firmach takich jak Shopify czy Discord. W marcu 2026 roku narzędzie zostało przejęte przez OpenAI za około 86 milionów dolarów, ale rdzeń pozostał na licencji MIT — to ważne, bo oznacza, że projekt nadal jest otwarty i darmowy w użyciu. Płatna nakładka dodaje funkcje dla dużych organizacji (np. zgodność SOC 2, ISO 27001, funkcje zespołowe), ale do testowania własnej aplikacji nie jest potrzebna.

Garak, PyRIT i Promptfoo — tabela porównawcza

Poniższe zestawienie sprowadza różnice do najważniejszych wymiarów. Traktuj je jak ściągę, nie jak wyrok — granice między narzędziami bywają płynne i wiele zespołów łączy je ze sobą.

Wymiar	Garak	PyRIT	Promptfoo
Twórca	NVIDIA	Microsoft	Promptfoo (od 2026 w OpenAI)
Licencja	Apache 2.0	MIT	MIT (rdzeń)
Główna warstwa	Model	Model + scenariusz	Aplikacja / agent
Charakter	Skaner z gotowymi próbami	Framework programistyczny	Framework do oceny + wtyczki
Sposób użycia	Polecenie + raport	Kod w Pythonie	Konfiguracja + CLI/CI
Ataki wieloturowe	Ograniczone	Mocna strona (Crescendo, TAP)	Tak (testy agentowe)
Pokrycie RAG / agenta	Ograniczone	Zależne od własnego kodu	Mocna strona
Odwzorowanie na OWASP	Pośrednie	Nie wprost	Tak (presety OWASP)
Próg wejścia	Niski	Wysoki	Niski–średni
Najlepsze do	Skan podatności modelu	Badania, własne ataki	Testy aplikacji w CI/CD

Czym te narzędzia różnią się w praktyce?

Tabela pokazuje cechy, ale prawdziwa różnica leży w pytaniu, na które każde narzędzie odpowiada. Garak odpowiada: „jak podatny jest model, którego zamierzam użyć?“. PyRIT odpowiada: „czy potrafię wymyślić atak, którego nikt jeszcze nie skatalogował, i sprawdzić go w sposób powtarzalny?”. Promptfoo odpowiada: „czy moja konkretna aplikacja — z jej promptem systemowym, narzędziami i danymi — wytrzyma znane klasy ataków przy każdym wdrożeniu?“.

Skaner kontra framework — fundamentalna różnica

Garak i Promptfoo są bliżej „włącz i dostań raport“, choć Promptfoo wymaga skonfigurowania pod twoją aplikację. PyRIT jest po drugiej stronie spektrum — to nie produkt, który coś ci powie, lecz biblioteka, z której budujesz badanie. To przekłada się na koszt czasu: skanem Garaka zobaczysz pierwsze wyniki w ciągu minut, Promptfoo wymaga opisania, jak rozmawiać z twoją aplikacją, a PyRIT — napisania scenariusza w Pythonie.

Model kontra aplikacja — różnica warstwy

To najczęściej mylony aspekt. Garak testuje model. Promptfoo testuje aplikację zbudowaną na modelu. Jeśli przepuścisz Garaka przez końcówkę GPT i dostaniesz czysty raport, to nie znaczy, że twój agent jest bezpieczny — bo cała podatność może siedzieć w twoim prompcie systemowym, w sposobie podłączenia narzędzi albo w RAG-u, którego Garak nie dotyka. Odwrotnie: Promptfoo nie da ci tak wyczerpującego przeglądu słabości samego modelu bazowego jak Garak.

Statyczne kontra generowane ataki

Garak uruchamia głównie znany, choć ogromny katalog ataków. PyRIT generuje nowe ataki przy użyciu modelu-atakującego. Ta różnica decyduje o tym, czy znajdziesz podatności już opisane w literaturze (Garak), czy masz szansę natknąć się na coś, czego jeszcze nikt nie skatalogował (PyRIT). Promptfoo plasuje się pomiędzy — jego wtyczki generują ładunki dynamicznie, ale w ramach zdefiniowanych klas zagrożeń.

Kiedy użyć którego narzędzia?

Najlepszą odpowiedzią często nie jest „jedno z trzech“, lecz „które do której fazy“. Poniżej praktyczne dopasowania.

Wybierz Garaka, gdy…

• Wybierasz model bazowy i chcesz szybko porównać odporność kilku kandydatów.
• Potrzebujesz szerokiego, automatycznego pokrycia podatności warstwy modelu z eksportowalnym raportem (np. na potrzeby zgodności lub badań).
• Pracujesz w ekosystemie NVIDIA / NeMo Guardrails.
• Zależy ci na niskim progu wejścia i wyniku „od ręki“.

Wybierz PyRIT, gdy…

• Jesteś badaczem bezpieczeństwa i potrzebujesz wieloturowych, sterowanych ataków, których nie znajdziesz w gotowym katalogu.
• Chcesz testować konkretne polityki bezpieczeństwa w sposób ustrukturyzowany i powtarzalny.
• Masz kompetencje w Pythonie i akceptujesz wyższy nakład pracy w zamian za pełną kontrolę.
• Interesują cię techniki typu Crescendo czy TAP i własna logika orkiestracji ataku.

Wybierz Promptfoo, gdy…

• Budujesz własną aplikację albo agenta i chcesz testować jej całość, nie tylko model.
• Potrzebujesz wpiąć red teaming w pipeline CI/CD i uruchamiać go przy każdym pull requeście.
• Zależy ci na odwzorowaniu wyników na OWASP Top 10 dla LLM albo dla aplikacji agentowych.
• Twój zespół to inżynierowie produktu, którzy chcą testować wcześnie i często, a nie raz przed premierą.

A jeśli mam łączyć narzędzia?

Łączenie jest nie tylko dozwolone, ale często rozsądne, bo każde narzędzie pokrywa inną warstwę. Typowy, dojrzały układ wygląda tak: Garakiem skanujesz model bazowy na etapie jego wyboru, Promptfoo wpinasz w CI/CD jako stałą bramkę jakości bezpieczeństwa aplikacji, a PyRIT wyciągasz wtedy, gdy potrzebujesz pogłębionego, ręcznie sterowanego badania konkretnego ryzyka. To nie konkurenci do skreślenia — to trzy różne soczewki na ten sam system.

Jak zacząć red teaming agenta bez chaosu?

Narzędzie to dopiero połowa sprawy. Drugą połową jest metoda. Kilka zasad, które oszczędzają później bólu głowy:

Zacznij od modelu zagrożeń, nie od narzędzia. Najpierw nazwij, co dla twojego agenta byłoby porażką (wyciek danych klienta? wykonanie akcji bez autoryzacji? wygenerowanie szkodliwej treści?). Dopiero wtedy dobierasz narzędzie pod te konkretne ryzyka. Odwrotna kolejność — najpierw narzędzie, potem szukanie zastosowania — kończy się raportem, którego nikt nie czyta.

Testuj powtarzalnie, nie jednorazowo. Model jest niedeterministyczny, więc pojedynczy przebieg niczego nie dowodzi. Sens ma seria prób i śledzenie wskaźnika powodzenia ataku w czasie — zwłaszcza po każdej zmianie promptu systemowego czy modelu.

Pamiętaj o warstwie aplikacji. Czysty raport z testu modelu nie zwalnia z testu aplikacji. Najgroźniejsze podatności agentów żyją tam, gdzie model spotyka narzędzia, pamięć i dane zewnętrzne — a tego skaner modelu nie zobaczy.

Wpinaj testy w proces. Red teaming raz przed wdrożeniem to lepsze niż nic, ale prawdziwa wartość pojawia się, gdy testy chodzą automatycznie przy każdej zmianie. Stąd przewaga narzędzi przyjaznych CI/CD dla zespołów, które iterują szybko.

Testuj tylko własne systemy. To brzmi oczywiście, ale warto powtórzyć: red teaming prowadzisz na systemach, do których masz prawo. Atakowanie cudzych końcówek bez zgody to nie badanie bezpieczeństwa, tylko naruszenie.

Podsumowanie

Garak, PyRIT i Promptfoo nie są wymienne — odpowiadają na trzy różne pytania o bezpieczeństwo agenta AI. Garak skanuje odporność samego modelu i daje najszerszy gotowy arsenał ataków warstwy modelu. PyRIT to warsztat dla badaczy, którzy chcą budować własne, wieloturowe ataki z pełną kontrolą. Promptfoo testuje całą aplikację agentową, mówi językiem OWASP i wpina się w CI/CD, co czyni go domyślnym wyborem dla zespołów produktowych.

Świadomy wybór zaczyna się od pytania, na którą warstwę i fazę celujesz — model, scenariusz badawczy czy aplikacja w ciągłej integracji. A jeśli budujesz coś poważnego, najpewniejszą odpowiedzią będzie połączenie więcej niż jednego z nich.

---

Źródła: dokumentacja i repozytoria projektów NVIDIA Garak, Microsoft/Azure PyRIT oraz Promptfoo; blog bezpieczeństwa Microsoftu o frameworku PyRIT; dokumentacja Promptfoo dot. presetów OWASP. Stan wiedzy: czerwiec 2026.