Benchmarki bezpieczeństwa agentów AI: jak mapować testy na MITRE ATLAS i OWASP Top 10 dla aplikacji agentowych (ASI)

Większość zespołów testuje dziś agentów AI tak, jak kiedyś testowała chatboty: zarzuca model garścią złośliwych promptów i sprawdza, czy się złamie. To strzelanie na oślep. Agent ma narzędzia, pamięć, tożsamość i prawo do działania w prawdziwych systemach — więc i jego bezpieczeństwa nie zmierzymy pojedynczą odpowiedzią, lecz całym łańcuchem decyzji i wywołań narzędzi prowadzonym pod presją ataku. Ten artykuł pokazuje, jak zbudować powtarzalne stanowisko ewaluacyjne agenta (evaluation harness) i jak każdy test przypiąć do dwóch ram, które dziś naprawdę liczą się w branży: MITRE ATLAS i OWASP Top 10 dla aplikacji agentowych (ASI). To jedna ze szprych szerszej praktyki red-team frameworków dla agentów AI.

Jak mapować benchmarki bezpieczeństwa agentów AI na MITRE ATLAS i OWASP ASI?

Najkrótsza odpowiedź: traktuj OWASP ASI jako listę ryzyk biznesowych (co może pójść nie tak z perspektywy aplikacji), a MITRE ATLAS jako słownik taktyk i technik napastnika (jak ktoś to ryzyko wykorzysta). Pojedynczy benchmark — na przykład AgentDojo czy InjecAgent — jest narzędziem pomiarowym: dostarcza scenariusze ataku i metrykę skuteczności. Mapowanie polega na tym, by dla każdego scenariusza testowego wskazać jego miejsce w obu rejestrach jednocześnie: który punkt OWASP ASI sprawdza i którą technikę ATLAS odwzorowuje. Dzięki temu wynik testu przestaje być liczbą w próżni, a staje się dowodem na to, że konkretne, nazwane ryzyko jest pokryte.

W praktyce wygląda to tak: scenariusz „złośliwy e-mail z ukrytą instrukcją każe agentowi wysłać dane na zewnętrzny adres“ mapuje się równocześnie na ASI01 (przejęcie celu agenta) po stronie OWASP oraz na technikę pośredniego wstrzyknięcia promptu (indirect prompt injection) w taktyce wykonania ATLAS. Jeden scenariusz, dwie etykiety, jedna metryka — Attack Success Rate. Tak powstaje macierz pokrycia, którą można pokazać audytorowi, zespołowi ryzyka i zarządowi.

Czym różni się MITRE ATLAS od OWASP Top 10 dla aplikacji agentowych?

To nie są rywalizujące standardy — uzupełniają się i opisują problem z dwóch stron. ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) to żywa baza wiedzy MITRE, zbudowana na wzór ATT&CK. W wydaniu z listopada 2025 (v5.1.0) liczyła 16 taktyk, 84 techniki, 32 mitygacje i 42 studia przypadków, a kolejne aktualizacje z początku 2026 dorzuciły techniki właściwe dla agentów. ATLAS odpowiada na pytanie: „jakimi krokami napastnik realnie atakuje system AI“ — od zatruwania danych treningowych, przez evasion, po manipulację pamięcią i celem agenta.

OWASP Top 10 dla aplikacji agentowych (firmuje je Agentic Security Initiative, stąd skrót ASI) patrzy z perspektywy obrońcy budującego aplikację. To skondensowana, recenzowana lista dziesięciu najpoważniejszych klas ryzyka w systemach agentowych, którą wywiad o zagrożeniach rozkłada na czynniki pierwsze. Mówi językiem skutków: przejęcie celu, nadużycie narzędzi, eskalacja uprawnień, zatrucie pamięci. ATLAS jest encyklopedyczny i napastniczy; ASI — porządkujący priorytety i obronny.

Wymiar	MITRE ATLAS	OWASP Top 10 dla aplikacji agentowych (ASI)
Perspektywa	Napastnik (taktyki i techniki)	Obrońca / twórca aplikacji (klasy ryzyka)
Struktura	Macierz taktyka → technika → podtechnika	Ranking 10 ryzyk (ASI01–ASI10)
Granulacja	16 taktyk, 84 techniki (v5.1.0)	10 pozycji z opisem i mitygacjami
Główne zastosowanie	Modelowanie zagrożeń, red-team, ocena pokrycia	Priorytetyzacja, projektowanie zabezpieczeń, audyt
Aktualizacja	Ciągła baza wiedzy	Cykliczne wydanie (edycja 2026)

W uproszczeniu: ASI mówi, co chronić i w jakiej kolejności; ATLAS mówi, jak to zostanie zaatakowane i jak rozpisać to na testy.

Czym jest stanowisko ewaluacyjne agenta i z czego się składa?

Stanowisko ewaluacyjne agenta (evaluation harness) to powtarzalne środowisko, które wielokrotnie uruchamia agenta na zdefiniowanym zestawie zadań i ataków, a następnie liczy wyniki według ustalonych metryk. Różnica wobec zwykłego promptowania jest fundamentalna: stanowisko mierzy zachowanie w pełnym łańcuchu wywołań narzędzi, a nie pojedynczą odpowiedź modelu.

Dobre stanowisko ma cztery warstwy. Pierwsza to scenariusze — pary „zadanie użytkownika plus iniekcja napastnika“ ukryta w danych, które agent dostaje z narzędzi (w e-mailu, wyniku wyszukiwania, dokumencie). Druga to środowisko z narzędziami — symulowane lub odizolowane klienty poczty, kalendarze, bankowość, repozytoria, które agent realnie wywołuje. Trzecia to metryki — przede wszystkim Attack Success Rate (odsetek udanych ataków) oraz Utility under Attack (czy agent mimo ataku nadal poprawnie wykonuje uczciwe zadanie). Czwarta to mapowanie — etykiety ASI i ATLAS przypięte do każdego scenariusza, by wyniki dało się agregować po ryzyku, nie tylko po liczbie testów.

Bez czwartej warstwy zostaje sam wynik liczbowy. Z nią masz argument: „pokrywamy osiem z dziesięciu ryzyk ASI i dwadzieścia technik ATLAS, a oto luki“. To różnica między raportem dla inżyniera a raportem dla osoby, która podpisuje się pod ryzykiem.

Które benchmarki warto wpiąć w stanowisko?

Nie buduj wszystkiego od zera. Kilka publicznych benchmarków pokrywa najważniejsze klasy ataków na agentów i nadaje się do wpięcia jako gotowe źródło scenariuszy.

AgentDojo to dziś punkt odniesienia dla testów wstrzyknięć promptu w środowisku zadaniowym. Składa się z 97 realistycznych zadań i 629 przypadków testowych bezpieczeństwa — agent zarządza pocztą, obsługuje bankowość internetową albo rezerwuje podróż, a część zwracanych mu danych jest spreparowana. Jego kluczowa zaleta: środowisko jest dynamiczne i wielokrokowe, więc mierzy zachowanie agenta od początku do końca, a nie pojedynczy krok.

InjecAgent celuje wąsko w ataki pośredniego wstrzyknięcia: 1054 przypadki testowe podzielone na bezpośrednią szkodę (Direct Harm) i kradzież danych (Data Stealing), rozpisane na 17 narzędzi użytkownika i 62 narzędzia napastnika. Jest węższy niż AgentDojo — skupia się na pojedynczych krokach — ale właśnie dlatego świetnie nadaje się do regresji jednej, konkretnej klasy ryzyka.

Do tego dochodzą zestawy ASB oraz nowsze, dynamiczne benchmarki w rodzaju AgentDyn, które rozszerzają testowanie na bardziej otwarte, zmienne środowiska. Zasada doboru jest prosta: weź jeden benchmark szeroki i zadaniowy (AgentDojo) jako rdzeń, jeden wąski i precyzyjny (InjecAgent) do regresji, a braki w pokryciu ASI/ATLAS uzupełnij własnymi scenariuszami.

Jak przypiąć konkretny test do ASI i ATLAS — przykładowa macierz

Najlepiej pokazać to na powiązaniach. Poniższa tabela odwzorowuje typowe scenariusze testowe na obie ramy. To roboczy szkielet, nie oficjalny crosswalk — każda organizacja powinna dopasować go do własnego modelu zagrożeń.

Scenariusz testowy	Ryzyko OWASP ASI	Taktyka / technika ATLAS
Ukryta instrukcja w treści e-maila przekierowuje agenta	ASI01 — przejęcie celu agenta	Wykonanie: pośrednie wstrzyknięcie promptu
Agent używa legalnego narzędzia do destrukcyjnej operacji	ASI02 — nadużycie narzędzi	Wpływ / wykonanie przez narzędzia agenta
Wyciek poświadczeń pozwala działać poza zakresem roli	ASI03 — nadużycie tożsamości i uprawnień	Eskalacja uprawnień / dostęp do poświadczeń
Zatruty komponent w łańcuchu zależności runtime	ASI04 — podatności łańcucha dostaw	Dostęp początkowy: zatrucie łańcucha dostaw ML
Wstrzyknięcie prowadzi do wykonania kodu	ASI05 — nieoczekiwane wykonanie kodu	Wykonanie kodu sterowane językiem naturalnym
Trwałe zatrucie pamięci zmienia późniejsze zachowanie	ASI06 — zatrucie pamięci i kontekstu	Utrwalenie: manipulacja pamięcią agenta
Sfałszowane komunikaty między agentami	ASI07 — niebezpieczna komunikacja między agentami	Wykonanie / obejście w systemach wieloagentowych

Działa to tak: zaczynasz od scenariusza w benchmarku, przypisujesz mu jedną etykietę ASI (priorytet biznesowy) oraz jedną lub więcej technik ATLAS (rozpis na obronę i monitoring). Po przejściu całego stanowiska agregujesz wyniki w dwóch widokach — po ASI dla zarządu, po ATLAS dla zespołu detekcji. Te same testy, dwie narracje, jeden zestaw dowodów.

Jak zmierzyć dojrzałość pokrycia, a nie tylko to, „czy przeszło“?

Pojedynczy przebieg stanowiska mówi, ile ataków się udało. Dojrzałość to coś więcej — to odsetek istotnych technik ATLAS, które masz pokryte testem oraz kontrolą detekcyjną. MITRE wprost zaleca takie podejście: ocenia się, jaki procent istotnych technik ATLAS wiąże się z monitoringiem i gotowością do reagowania na incydenty właściwe dla AI. To przesuwa pomiar z „zdaliśmy benchmark“ na „znamy swoją powierzchnię ataku i wiemy, gdzie mamy dziury“.

Praktyczny zestaw metryk dla stanowiska: Attack Success Rate (im niżej, tym lepiej), Utility under Attack (im wyżej, tym lepiej — agent ma być bezpieczny i użyteczny), pokrycie ASI (ile z dziesięciu ryzyk ma przynajmniej jeden aktywny test), pokrycie ATLAS (ile istotnych technik ma test i detekcję) oraz trend regresji między wydaniami modelu lub promptu systemowego. Tę ostatnią metrykę łatwo zlekceważyć: agent, który był bezpieczny w zeszłym miesiącu, po zmianie promptu systemowego lub modelu bazowego potrafi po cichu się cofnąć.

Najczęstsze błędy przy ewaluacji bezpieczeństwa agentów

Pierwszy błąd to mierzenie samej odpowiedzi modelu zamiast pełnego łańcucha narzędzi. Agent szkodzi nie tym, co napisze, lecz tym, co wywoła — wysłanym e-mailem, usuniętym plikiem, przelewem. Stanowisko musi obserwować wywołania narzędzi, a nie tekst — dokładnie to robi fuzzing wywołań narzędzi.

Drugi błąd to pomiar bezpieczeństwa w oderwaniu od użyteczności. Łatwo zbudować agenta, który odrzuca każdą podejrzaną instrukcję, a przy okazji nie wykonuje uczciwych zadań. Dlatego Utility under Attack jest tak samo ważne jak Attack Success Rate — bezpieczny, ale bezużyteczny agent to porażka produktowa.

Trzeci błąd to testy jednorazowe. Benchmarki statyczne starzeją się, a napastnicy się dostosowują. Stanowisko powinno działać w potoku CI przy każdej zmianie modelu, promptu systemowego czy zestawu narzędzi — inaczej mierzysz stan z przeszłości. Czwarty błąd to brak mapowania: zbiór zielonych testów bez przypięcia do ASI i ATLAS nie powie ci, czego nie sprawdziłeś. Luka w pokryciu jest groźniejsza niż test, który jawnie świeci się na czerwono.

Podsumowanie: od liczby do dowodu pokrycia

Bezpieczeństwo agenta AI to nie jeden wynik, lecz macierz: scenariusze ataku zebrane na powtarzalnym stanowisku, każdy przypięty jednocześnie do ryzyka OWASP ASI i techniki MITRE ATLAS, zmierzony metrykami skuteczności i użyteczności. ASI nadaje priorytety i język dla decydentów. ATLAS rozpisuje atak na testy i kontrole detekcyjne. Benchmarki w rodzaju AgentDojo i InjecAgent dostarczają gotowych scenariuszy. Dopiero połączenie tych trzech warstw zamienia ewaluację z teatru bezpieczeństwa w sprawdzalny dowód pokrycia — taki, który obroni się i przed audytorem, i przed prawdziwym napastnikiem.

---

Materiał ma charakter edukacyjny i nie zastępuje audytu bezpieczeństwa konkretnego wdrożenia. Nazwy ram (MITRE ATLAS, OWASP) oraz benchmarków należą do ich właścicieli; dane techniczne podano za publicznymi wydaniami według stanu na początek 2026 r.