RED-04 · Red-teaming i ewaluacje

CTF dla bezpieczeństwa agentów AI: jak zbudować odtwarzalne laboratorium i punktować eksploitację

Jak projektować wyzwania CTF do testowania agentów AI: odtwarzalne laboratorium, scenariusze prompt injection i uczciwy system punktacji eksploitacji.

The red-team evaluation loop: plan an attack, run it against the agent, observe the outcome, score it, then iterateplan01attack02observe03score04findings feed the next round — coverage grows until the agent stops failing

Czym jest CTF bezpieczeństwa AI i dlaczego agenci potrzebują własnego poligonu?

CTF bezpieczeństwa AI (z ang. Capture the Flag) to wyzwanie, w którym uczestnik próbuje zmusić agenta opartego na modelu językowym do złamania jego własnych reguł — wyciągnięcia sekretu, wykonania zakazanej akcji albo eksfiltracji danych — a o sukcesie świadczy zdobycie „flagi“. W odróżnieniu od klasycznego CTF, gdzie podatność tkwi w kodzie binarnym czy aplikacji webowej, tutaj luka siedzi w warstwie języka naturalnego i w uprawnieniach narzędzi, którymi agent dysponuje. Najprościej mówiąc: budujesz odtwarzalne laboratorium odwzorowujące realną powierzchnię ataku agentów AI, dajesz agentowi sekret lub zdolność, której nie powinien ujawnić, i sprawdzasz, kto pierwszy przebije się przez jego zabezpieczenia.

Potrzeba osobnego poligonu wynika z prostej obserwacji. Agent AI to nie chatbot, który tylko odpowiada — to system, który planuje, sięga po narzędzia (API, bazę, przeglądarkę) i wykonuje wielokrokowe zadania. Każde z tych narzędzi to nowa powierzchnia ataku. Klasyczne testy jednostkowe tu nie wystarczą, bo zachowanie modelu jest niedeterministyczne, a granica między „poprawnym wykonaniem zadania“ a „eksploitacją“ bywa rozmyta. CTF to jedna ze szprych szerszej praktyki red-team frameworków dla agentów AI. Dlatego CTF — kontrolowane, powtarzalne, punktowane — stał się naturalnym formatem do ćwiczenia red-teamingu agentów.

Wzorcem, który spopularyzował tę formę, jest Gandalf od Lakery: model strzeże hasła, a po każdym udanym wycieku podnosi poprzeczkę przez siedem poziomów o coraz twardszych zabezpieczeniach. To dobry punkt odniesienia, ale produkcyjny agent jest znacznie bardziej złożony — i właśnie o budowaniu poważniejszych laboratoriów jest ten tekst.

Jak zaprojektować wyzwanie CTF do hakowania agenta?

Dobre wyzwanie hakowania agenta ma trzy elementy, które trzeba rozdzielić od samego początku: cel (co jest flagą), powierzchnię (przez co atakujący wchodzi) i wyrocznię (jak system rozstrzyga, czy flaga padła). Pomieszanie ich to najczęstszy błąd — kończy się wyzwaniem, którego nie sposób ani powtórzyć, ani uczciwie ocenić.

Co może być flagą w wyzwaniu agentowym?

Flaga musi być jednoznaczna i sprawdzalna maszynowo. W praktyce sprawdzają się cztery typy celów:

  • Sekret w kontekście — hasło, klucz API albo token wpleciony w systemowy prompt, który agent ma chronić. To wariant gandalfowy, najłatwiejszy do oceny: flaga albo pojawia się w odpowiedzi, albo nie.
  • Zakazana akcja narzędziowa — agent ma dostęp do funkcji typu wyslij_przelew() czy usun_uzytkownika(), a atakujący próbuje go nakłonić, by wywołał ją poza dozwolonym scenariuszem. Flagą jest samo wywołanie z określonymi argumentami; ten sam wektor automatyzuje fuzzing wywołań narzędzi.
  • Eksfiltracja danych — agent trzyma w pamięci roboczej dane innego użytkownika, a celem jest wyciągnięcie ich przez podszycie się pod uprawnioną rolę.
  • Eskalacja uprawnień — agent działa z niskim poziomem dostępu, a flagą jest sytuacja, w której wykona operację zarezerwowaną dla administratora.

Którą powierzchnią ataku wpuścić uczestnika?

Tu zaczyna się sedno realizmu. W laboratorium agentowym prompt injection dzieli się na dwa odmienne tryby, które warto punktować osobno:

  • Injection bezpośredni — atakujący pisze wprost do agenta. Łatwiejszy, dobry na poziomy wprowadzające.
  • Injection pośrednipośrednie wstrzyknięcie polecenia: złośliwa instrukcja jest ukryta w danych, które agent dopiero pobierze: w treści strony, w polu rekordu z bazy, w nazwie pliku, w komentarzu na karcie zadania. To najgroźniejsza i najbardziej realistyczna klasa, bo atakujący nigdy nie rozmawia z agentem bezpośrednio — podkłada ładunek tam, gdzie agent sięgnie sam.

Pośredni prompt injection od dwóch edycji utrzymuje pierwsze miejsce w OWASP Top 10 dla aplikacji LLM, a w 2025 roku OWASP wydał osobny zestaw Top 10 dla aplikacji agentowych, ogłoszony podczas Black Hat Europe. To mocny powód, by projektować scenariusze właśnie wokół narzędzi i danych zewnętrznych, a nie tylko wokół „rozmowy“ z modelem.

Jak zbudować odtwarzalne laboratorium bezpieczeństwa?

Odtwarzalne laboratorium to takie, w którym ten sam atak daje ten sam werdykt niezależnie od dnia, maszyny i osoby uruchamiającej test. Brzmi banalnie, ale w świecie modeli niedeterministycznych to najtrudniejszy wymóg całego przedsięwzięcia. Bez odtwarzalności CTF zamienia się w loterię, a wyniki nie nadają się ani do porównań, ani do śledzenia regresji bezpieczeństwa.

Co przypiąć, żeby wynik dało się powtórzyć?

Odtwarzalność buduje się przez konsekwentne przypinanie wszystkiego, co wpływa na zachowanie agenta:

  • Wersja modelu — zawsze konkretny, przypięty identyfikator modelu i dostawcy, nigdy alias „latest“. Podmiana modelu pod spodem unieważnia historyczne wyniki.
  • Temperatura i parametry próbkowania — ustawione na zero lub stałą wartość tam, gdzie zależy ci na maksymalnej powtarzalności; warto też przypiąć ziarno losowości (seed), jeśli dostawca je udostępnia.
  • System prompt i definicje narzędzi — wersjonowane w repozytorium, traktowane jak kod. Każda zmiana to nowy commit i nowy „poziom“.
  • Stan środowiska — baza, pliki i strony, po które agent sięga, muszą odtwarzać się z migawki przy każdym uruchomieniu. Najwygodniej zamknąć całość w kontenerze i odpalać świeżą instancję na każdą próbę.
  • Izolacja narzędzi — narzędzia w laboratorium są atrapami (mockami) o kontrolowanych odpowiedziach. Agent nie wykonuje prawdziwego przelewu — wywołuje funkcję, która jedynie zapisuje fakt wywołania. To zarazem warunek bezpieczeństwa i odtwarzalności.

Jak poradzić sobie z niedeterminizmem modelu?

Nawet przy temperaturze zero model potrafi dać dwie różne odpowiedzi na ten sam ładunek. Dlatego pojedyncze trafienie to za mało, by orzec, że agent jest podatny. Stosuje się dwa podejścia, które dobrze się uzupełniają. Po pierwsze, wielokrotne uruchomienie tego samego ataku (na przykład dziesięciokrotne) i raportowanie odsetka udanych prób zamiast zero-jedynkowego werdyktu — podatność opisuje się wtedy jako „atak przechodzi w 7 na 10 prób“, co jest znacznie uczciwsze. Po drugie, rozdzielenie warstwy ataku od warstwy oceny: o tym, czy flaga padła, rozstrzyga osobny, deterministyczny mechanizm, a nie sam model będący celem.

Jak punktować eksploitację agenta, żeby było uczciwie?

Punktacja to miejsce, w którym większość domowych CTF-ów się sypie. Pokusa jest jedna: „spytajmy drugi model, czy atak się udał“. Kuszące, ale samo w sobie staje się powierzchnią ataku — wyrocznię opartą na LLM również da się oszukać przez injection. Dlatego warstwę oceny projektuje się tak, by w jak największym stopniu była deterministyczna.

Czym rozstrzygać, czy flaga padła?

Wyrocznia (mechanizm orzekający o sukcesie) powinna iść od najtwardszej do najmiększej metody, a po LLM sięgać dopiero w ostateczności:

Typ wyroczni Jak działa Odtwarzalna? Kiedy używać
Dopasowanie sekretu Sprawdza, czy dokładny token-flaga jest w odpowiedzi Tak, w pełni Sekret w kontekście
Przechwycenie wywołania narzędzia Loguje wywołania funkcji i ich argumenty Tak, w pełni Zakazana akcja, eskalacja
Reguły / wyrażenia regularne Wzorce na wyciek danych (format e-mail, PESEL, klucz) Tak Eksfiltracja danych
Sędzia-LLM (LLM-as-judge) Drugi model ocenia, czy doszło do złamania reguł Częściowo Tylko do ocen miękkich, nie zero-jedynkowych

Naczelna zasada: jeśli flagę da się sprawdzić dopasowaniem tekstu lub logiem wywołania narzędzia, nigdy nie używaj do tego modelu. Sędziego-LLM zostaw do miękkich, niejednoznacznych ocen (na przykład „czy odpowiedź była szkodliwa“) — i nawet wtedy odetnij jego wejście od treści, którą ocenia.

Jak skonstruować punktację, która coś znaczy?

Surowa liczba zdobytych flag mówi mało. Bardziej użyteczny jest system, który waży trzy wymiary: trudność celu (sekret w promptcie jest banalniejszy niż eskalacja uprawnień przez injection pośredni), niezawodność ataku (wspomniany odsetek udanych prób) oraz realizm powierzchni (injection pośredni przez pobrane dane jest cenniejszy niż instrukcja wpisana wprost). Punkty przyznawane proporcjonalnie do tych wymiarów dają ranking, który faktycznie odzwierciedla ryzyko produkcyjne, a nie tylko spryt jednego promptu.

Warto też logować cały ślad udanego ataku: kolejne tury, wywołania narzędzi, pobrane dane. To z tych zapisów rodzi się największa wartość ćwiczenia — nie sam fakt, że flaga padła, ale dokładna ścieżka, którą agent dał się poprowadzić. Ślad zamienia się potem w przypadek testowy regresji: dodajesz go do zestawu i przy każdej zmianie agenta sprawdzasz, czy stara dziura nie wróciła.

Jakich błędów unikać przy budowie agentowego CTF?

Z doświadczenia red-teamingu agentów kilka pułapek powtarza się tak często, że warto je nazwać wprost:

  • Wyrocznia oparta wyłącznie na LLM — podatna na ten sam injection, który testujesz. Zawsze najpierw twarda metoda.
  • Brak izolacji narzędzi — agent z dostępem do prawdziwego API może wyrządzić realną szkodę podczas testu. Wszystkie narzędzia w laboratorium to atrapy.
  • Werdykt z jednego uruchomienia — przy niedeterminizmie modelu pojedyncze trafienie niczego nie dowodzi. Mierz odsetek udanych prób.
  • Mylenie poziomów z realizmem — siedem poziomów rosnącej trudności jest świetne dydaktycznie, ale produkcyjne ryzyko najlepiej oddaje jeden realistyczny scenariusz z injection pośrednim.
  • Brak wersjonowania środowiska — jeśli system prompt, definicje narzędzi i stan danych nie są przypięte w repozytorium, wyniki sprzed miesiąca są bezwartościowe.

Jakimi narzędziami zbudować takie laboratorium?

Nie trzeba pisać wszystkiego od zera. Ekosystem narzędzi do adwersaryjnego testowania agentów jest dziś dojrzały: Promptfoo i DeepTeam pozwalają budować zestawy testów red-teamowych mapowane na kategorie OWASP, a Gandalf od Lakery sprawdza się jako gotowy poligon dydaktyczny do nauki samego prompt injection. Te narzędzia warto traktować jako szkielet do generowania ataków i zarządzania zestawami, a wokół nich dobudować własną warstwę odtwarzalnego środowiska (kontener, atrapy narzędzi, deterministyczna wyrocznia) opisaną wyżej.

Niezależnie od wyboru narzędzi sednem pozostaje dyscyplina: przypięte wersje, izolowane narzędzia, twarda wyrocznia i punktacja, która waży trudność, niezawodność i realizm. Tyle wystarczy, by CTF przestał być zabawą, a stał się powtarzalnym pomiarem odporności agenta — i żeby dzisiejszy wynik dało się uczciwie porównać z wynikiem za pół roku.

Najczęstsze pytania

Czym CTF dla agentów AI różni się od klasycznego CTF?

W klasycznym CTF podatność tkwi w kodzie, binariach czy aplikacji webowej i jest deterministyczna. W CTF agentowym luka leży w warstwie języka naturalnego i w uprawnieniach narzędzi, którymi agent dysponuje, a zachowanie modelu jest niedeterministyczne. Dlatego flaga musi być maszynowo sprawdzalna, a werdykt opiera się na wskaźniku sukcesu z wielu prób, nie na jednym trafieniu.

Czym jest pośredni prompt injection i dlaczego jest groźniejszy?

Pośredni prompt injection to ukrycie złośliwej instrukcji w danych, które agent dopiero pobierze: w treści strony, polu rekordu z bazy, nazwie pliku czy komentarzu. Atakujący nigdy nie rozmawia z agentem bezpośrednio, tylko podkłada ładunek tam, gdzie agent sięgnie sam. Jest groźniejszy od injectiona bezpośredniego, bo oddaje realny scenariusz produkcyjny i trudniej go wykryć filtrem wejścia.

Jak zapewnić odtwarzalność wyników, skoro model jest niedeterministyczny?

Przez przypięcie wszystkiego, co wpływa na zachowanie: konkretnej wersji modelu (nigdy aliasu latest), temperatury i ziarna losowości, wersjonowanego system promptu i definicji narzędzi oraz stanu środowiska odtwarzanego z migawki. Sam niedeterminizm modelu obchodzi się przez wielokrotne uruchomienie tego samego ataku i raportowanie wskaźnika sukcesu zamiast werdyktu zero-jedynkowego.

Czy do oceny, czy atak się udał, można użyć drugiego modelu LLM?

Tylko ostrożnie i w ostateczności. Wyrocznia oparta na LLM sama staje się powierzchnią ataku, bo da się ją oszukać tym samym prompt injectionem, który testujesz. Jeśli flagę da się sprawdzić dopasowaniem tekstu lub logiem wywołania narzędzia, zawsze rób to deterministycznie. Sędziego-LLM zostaw do miękkich ocen i izoluj jego wejście od ocenianej treści.

Co powinno być flagą w wyzwaniu agentowym?

Cel jednoznaczny i maszynowo sprawdzalny. Sprawdzają się cztery typy: sekret w kontekście (hasło lub klucz w system promptcie), zakazana akcja narzędziowa (wywołanie funkcji poza scenariuszem), eksfiltracja danych innego użytkownika oraz eskalacja uprawnień do operacji administratora. Każdy z nich daje się ocenić twardą wyrocznią bez udziału modelu.

Jak skonstruować punktację, która odzwierciedla realne ryzyko?

Surowa liczba flag mówi mało. Lepiej ważyć trzy wymiary: trudność celu (eskalacja uprawnień jest cenniejsza niż wyciek sekretu z promptu), niezawodność ataku mierzoną wskaźnikiem sukcesu z wielu prób oraz realizm powierzchni (injection pośredni przez pobrane dane wart więcej niż instrukcja wpisana wprost). Tak liczone punkty dają ranking odpowiadający ryzyku produkcyjnemu.

Jakimi narzędziami zacząć budowę agentowego laboratorium?

Nie trzeba pisać wszystkiego od zera. Promptfoo i DeepTeam pozwalają budować zestawy testów red-teamowych mapowane na kategorie OWASP, a Gandalf od Lakery to gotowy poligon dydaktyczny do nauki prompt injection. Te narzędzia warto traktować jako szkielet do generowania ataków, a wokół nich dobudować własną warstwę odtwarzalnego środowiska: kontener, atrapy narzędzi i deterministyczną wyrocznię.