Red teaming agentów AI: jak systematycznie wykrywać podatności

Red teaming agentów AI to systematyczne, symulowane atakowanie agentów AI w celu wykrycia podatności, takich jak prompt injection, jailbreaki, nadużycie narzędzi i wyciek danych, zanim wykorzystają je prawdziwi atakujący. Łączy zautomatyzowane narzędzia ataku z ręczną kreatywnością w wieloetapowych atakach i dostarcza mierzalnych wyników, takich jak wskaźniki skuteczności ataków, zamiast binarnych list podatności. W odróżnieniu od testu funkcjonalnego nie pyta: „czy agent działa?”, lecz: „jak można go wykorzystać wbrew jego właściwemu przeznaczeniu?”.

Ten artykuł jest częścią hubu „Bezpieczeństwo agentów AI według OWASP” i pokazuje konkretnie, jak ofensywnie sprawdzisz ryzyka skatalogowane w OWASP Agentic Top 10 (ASI01–ASI10).

Trzy szybkie odpowiedzi

• Co jest atakowane? Specyficzna dla agentów powierzchnia ataku: nie tylko model, ale też wywołania narzędzi, pamięć trwała, komunikacja między agentami i human-in-the-loop. Celem jest wykrycie przejęcia celu, nadużycia narzędzi, zatruwania pamięci i wycieku danych.
• Czym? Skanerami open source (Garak, PyRIT, DeepTeam, Promptfoo) dla szerokiego pokrycia, ręcznym red teamingiem dla ataków wieloetapowych oraz programem bug bounty dla pokrycia długoterminowego.
• Jak często? Kwartalny test bazowy plus testy wyzwalane zdarzeniami (nowe narzędzia, zmiany promptów, aktualizacje modelu, krytyczne CVE).

Dlaczego AI red teaming to nie klasyczny pentest

Najważniejsze rozróżnienie na początek: AI red teaming nie jest synonimem tradycyjnego testu penetracyjnego. Działy zakupów w regionie DACH (Niemcy, Austria, Szwajcaria) regularnie mylą jedno z drugim, co ma kosztowne skutki, gdy pentest wykonany za pomocą Burp Suite zostaje zaakceptowany jako „dowód bezpieczeństwa AI”.

Różnice są fundamentalne:

Agent AI często w ogóle nie „psuje się” w klasycznym sensie: wykonuje instrukcje, co do których wprowadzono go w błąd, że są uprawnione. Ponieważ agenci i model bazowy nie potrafią niezawodnie odróżnić instrukcji od danych, każdy tekst, który czyta agent, jest częścią powierzchni ataku. To wymaga innej dyscypliny testowania.

Jakich podatności red team szuka celowo

Red teaming przechodzi po kolei przez specyficzne dla agentów klasy zagrożeń z OWASP Agentic Top 10. W praktyce oznacza to celowe konstruowanie następujących ataków:

• Prompt injection / przejęcie celu (ASI01). Bezpośrednie i pośrednie wstrzyknięcia, ukryte instrukcje w dokumentach, korpusie RAG, e-mailach, zaproszeniach z kalendarza, opisach PR lub wynikach narzędzi. Szczególnie perfidny jest wieloturowy dryf „boiling frog”, w którym każdy pojedynczy krok wygląda wiarygodnie, ale skumulowana trajektoria jest złośliwa.
• Jailbreaki. Obchodzenie barier bezpieczeństwa w celu wywołania zakazanych działań lub treści.
• Nadużycie narzędzi (ASI02). Uprawniona funkcja (np. send_email) zostaje użyta niezgodnie z przeznaczeniem; wykorzystuje się tryby automatycznego zatwierdzania lub tryby „YOLO”, które wyłączają prośby o potwierdzenie.
• Zatruwanie pamięci i kontekstu (ASI06). Treści wprowadzone jednorazowo na stałe zatruwają pamięć trwałą; „delayed tool invocation” uruchamia się dopiero po kilku tygodniach, po słowie wyzwalającym.
• Wyciek danych. Eksfiltracja przez zmanipulowane obrazy w Markdownie, łańcuchy przekierowań lub nadużywane serwery proxy.
• Ataki między agentami (ASI07) i wykorzystanie zaufania człowiek-agent (ASI09). Sfałszowane wiadomości między agentami oraz celowe obchodzenie ludzkiej warstwy zatwierdzania za pomocą pewnie sformułowanych, ale zmanipulowanych rekomendacji.

O tym, że te ataki są realne, świadczą udokumentowane incydenty: EchoLeak (CVE-2025-32711, CVSS 9.3 według Microsoftu) był pierwszym rzeczywistym atakiem zero-click prompt injection w produkcyjnym systemie LLM i obszedł klasyfikator XPIA (Cross-Prompt Injection Attempt) Microsoftu. CamoLeak (CVSS 9.6) wyprowadzał znak po znaku sekrety z prywatnych repozytoriów i kod źródłowy przez własne proxy obrazów Camo GitHuba. Oba przypadki pokazują, że kompetentni badacze w ciągu kilku miesięcy obchodzili każdy opublikowany guardrail.

Metoda: automatycznie czy ręcznie

Dojrzały red teaming łączy dwa uzupełniające się tryby.

Tryb automatyczny oznacza skalę i powtarzalność. Skanery uruchamiają przeciwko agentowi obszerne biblioteki sond i mierzą, jaki odsetek przechodzi. Nadają się do ciągłej integracji w CI/CD i do testów regresyjnych po każdej zmianie. Słabość: wykrywają głównie znane wzorce ataków.

Tryb ręczny oznacza kreatywność i kontekst. Doświadczeni analitycy konstruują wieloetapowe kampanie dopasowane do konkretnego agenta, czyli właśnie te ataki, których skanery nie widzą. Przykłady z badań: „Agent Session Smuggling” przeciwko protokołowi A2A (Palo Alto Unit 42, 31 października 2025 r.) to nie jednorazowy atak typu injection, lecz długotrwała kampania socjotechniczna agent przeciwko agentowi. A2A opracował Google, a od czerwca 2025 r. protokół znajduje się pod opieką Linux Foundation. Atak na pamięć Google Gemini (Johann Rehberger, luty 2025 r.) wykorzystał „delayed tool invocation”, by zatruć pamięć z opóźnieniem.

Narzędzia i frameworki (stan na 2026 r.)

Poniższe narzędzia to sprawdzone w praktyce elementy składowe. Dane o wersjach i rynku według stanu na 2026 r.

Komercyjne: Lakera Red (Lakera z Zurychu, od października 2025 r. część Check Point), HiddenLayer AIDR, Robust Intelligence (Cisco), Trustwise i Cranium.

Bug bounty z zakresem AI: HackerOne (GitHub korzystał z HackerOne przy ujawnieniu CamoLeak), Bugcrowd oraz mająca siedzibę w UE i dobrze dopasowana do firm w Europie platforma Intigriti.

Raportowanie: mierzalne i zmapowane na frameworki

Wartość red teamingu w całości zależy od raportu. Ponieważ wyniki są probabilistyczne, trzeba je skwantyfikować. Przydatne wskaźniki:

• Wskaźnik skuteczności ataków: odsetek udanych ataków w każdej klasie.
• Wskaźnik wykrywalności: ile ataków wykrył monitoring.
• Czas do wykrycia: ile czasu minęło do wykrycia ataku.
• Promień rażenia: ile kolejnych agentów lub systemów w łańcuchu zostałoby dotkniętych.

Każde ustalenie powinno zostać zmapowane na uznane frameworki: OWASP Agentic Top 10 (ASI01–ASI10) jako rejestr ryzyk, MITRE ATLAS jako playbook przeciwnika (z uczciwym zastrzeżeniem, że ATLAS pozostaje 6–12 miesięcy w tyle za frontem rozwoju agentów, zwłaszcza w przypadku ASI07, ASI08 i ASI10) oraz, jako podejście wschodzące (stan na 2026 r.), AIVSS (wersja 0.8) do oceny ilościowej. Ustalenia można też ustrukturyzować zgodnie z AVID, co pozwala wykorzystać je jako powtarzalne dowody audytowe dla ISO 42001 A.5 i art. 9 unijnego AI Act. Ważne dla działów zakupów: „OWASP-compliant” nie jest wiarygodnym stwierdzeniem. OWASP nie certyfikuje.

Jak często i kto

Częstotliwość (praktyczna zasada): kwartalny test bazowy plus testy wyzwalane zdarzeniami, przed każdą nową integracją narzędzia z uprawnieniami destrukcyjnymi, po każdej istotnej zmianie promptu lub komunikatu systemowego, po każdej aktualizacji wersji modelu i doraźnie, gdy tylko CVE lub PoC dotyczy Twojego stacku.

Kto: koncerny z własnym stackiem agentów operującym na wrażliwych danych utrzymują dedykowany AI red team (wewnętrzny lub zewnętrzny na stałym kontrakcie), który pracuje z Garak, PyRIT i DeepTeam w oparciu o framework OWASP_ASI_2026, a do tego program bug bounty. MŚP wdrażające agentów opartych na zarządzanych API zlecają red teaming wyspecjalizowanym usługodawcom, bo w firmie brakuje kompetencji specyficznych dla ML.

Dla podmiotów finansowych w UE testy ofensywne są regulowane. DORA jest rozporządzeniem UE, obowiązuje bezpośrednio od 17 stycznia 2025 r. i wymaga regularnych testów odporności (art. 24–25). Testy penetracyjne prowadzone w oparciu o analizę zagrożeń (TLPT) (art. 26–27) muszą przeprowadzać tylko te podmioty finansowe, które wskazał właściwy organ nadzoru. W Niemczech wytyczne orientacyjne BaFin dotyczące ryzyk ICT przy wykorzystaniu AI z 18.12.2025 wskazują adwersaryjne testy penetracyjne i symulację ataków (data poisoning, evasion) jako odpowiednie środki. Wytyczne są wyraźnie niewiążące. Kto eksploatuje krytyczne systemy AI bez takich testów, powinien mimo to umieć to uzasadnić podczas kontroli.

Przykład z praktyki w liczbach

Ubezpieczyciel prowadzi wieloagentowy workflow do likwidacji szkód. Wewnętrzny red team konstruuje pośredni atak typu injection: w zeskanowanej kopii listu lekarskiego ukryto, w postaci tekstu możliwego do odtworzenia przez OCR, instrukcję automatycznego zatwierdzania spraw określonych kategorii. Agent „Risk Scoring” przejmuje zmanipulowaną ocenę i przekazuje ją agentom „Pricing” i „Compliance”.

Zmierzone wskaźniki: skuteczność ataku injection 1 na 1 (udany), czas do wykrycia > 4 godziny, promień rażenia: 3 kolejnych agentów w łańcuchu. Dla porównania: badania Galileo AI (grudzień 2025 r.) wykazały w symulowanych systemach wieloagentowych, że jeden skompromitowany agent zatruł 87% dalszego procesu decyzyjnego w ciągu 4 godzin. Udokumentowany incydent w dziale zakupów firmy produkcyjnej (2025 r.): agenta przez trzy tygodnie stopniowo przekonywano, że jego limit zatwierdzania wynosi 500 000 USD, a następnie atakujący złożył fałszywe zamówienia na 5 mln USD w 10 transakcjach. Takie ustalenia przekładają abstrakcyjne ryzyka na liczby zrozumiałe dla zarządu.

Praktyczna checklista

• Zdefiniuj zakres: które narzędzia, pamięci, ścieżki między agentami i punkty kontrolne HITL są objęte testem?
• Wyprowadź scenariusze oparte na modelu zagrożeń z OWASP ASI01–ASI10.
• Osadź automatyczny skan bazowy (Garak/PyRIT/DeepTeam) w CI/CD.
• Uzupełnij go ręcznymi, wieloetapowymi kampaniami (boiling frog, A2A, delayed invocation).
• Zbieraj wskaźniki: wskaźnik skuteczności ataków, wskaźnik wykrywalności, czas do wykrycia, promień rażenia.
• Zmapuj ustalenia na OWASP/MITRE ATLAS/AIVSS i dokumentuj je zgodnie z AVID.
• „Testowe wstrzyknięcia” sprawdzające, czy human-in-the-loop rzeczywiście działa.
• Ustal kadencję: co kwartał plus testy wyzwalane zdarzeniami.

Dla agencji i decydentów B2B

Kto buduje agentów dla klientów lub wykorzystuje ich we własnym stacku marketingowym i sprzedażowym, powinien traktować red teaming jako stały element procesu dostarczania i eksploatacji, a nie jako jednorazowy test odbiorczy. Dla agencji to również wyróżnik: wykazane wskaźniki skuteczności ataków i raportowanie zmapowane na OWASP budują wśród klientów zaufanie, którego nie zapewni zdanie „korzystamy z guardrails”. Blck Alpaca pomoże Ci zbudować konfigurację red teamingu dopasowaną do dojrzałości i otoczenia regulacyjnego Twojej firmy: od wyboru narzędzi, przez opracowanie scenariuszy, po raport gotowy na audyt. Odezwij się do nas, zanim Twój agent trafi na produkcję.