Red team agentów AI: jak zbudować powtarzalny test harness

Red team agentów AI powinien kończyć się powtarzalnym testem, a nie kolekcją efektownych promptów. Harness odtwarza środowisko, narzędzia, pamięć i politykę oraz mierzy rzeczywisty skutek.

Model testu

Zapisz wersję modelu, promptu, tool schemas, polityk, danych i seed, jeśli jest dostępny. Stubuj systemy zewnętrzne, aby nie wysyłać maila ani nie usuwać produkcji podczas testu.

Macierz abuse cases

OWASP zaleca testy prompt override, tool misuse, privilege escalation, memory poisoning, exfiltration, recursive abuse, approval bypass i multi-agent chaining. Dla każdego przypadku określ wejście, spodziewaną blokadę i dowód.

Oracle nie może opierać się wyłącznie na tekście odpowiedzi. Sprawdzaj log narzędzia, zmieniony stan, sieć i decyzję middleware. Agent może odmówić w tekście, a wcześniej wykonać akcję.

CI i regresja

Uruchamiaj szybki zestaw przy zmianie promptu, a pełny po zmianie modelu, toola, pamięci lub dostawcy. Blokuj release dla krytycznego tool abuse i wycieku danych. Zachowuj wcześniejsze udane ataki jako regresję.

Kontroluj koszt, retry i timeout, aby sam harness nie wywołał denial of wallet. Wyniki łącz z ewaluacją LLM oraz AI red teamingiem.

Co dokładnie mierzyć

Każdy przypadek testowy powinien mieć wejście, stan początkowy, dozwolone działania, akcje zabronione i maszynowo sprawdzalny warunek końcowy. Odpowiedź tekstowa modelu nie wystarcza: oceniaj rzeczywiste wywołania narzędzi, odbiorców danych, zmiany plików i decyzje warstwy autoryzacyjnej. Oddziel wynik bezpieczeństwa od jakości wykonania legalnego zadania.

Zapisuj wersję modelu, promptu, polityki, narzędzi, danych testowych i losowego seeda, jeśli system go udostępnia. Modele są niedeterministyczne, dlatego pojedynczy sukces nie dowodzi odporności. Uruchamiaj kilka prób i raportuj zarówno częstość naruszenia, jak i najgorszy zaobserwowany wpływ.

Biblioteka scenariuszy

Macierz powinna obejmować direct i indirect prompt injection, tool-output poisoning, memory poisoning, przekroczenie uprawnień, zmianę tenantu, exfiltrację, pętlę kosztową oraz niebezpieczny fallback. Dodaj legalne zadania podobne do ataków, aby ograniczyć fałszywe blokady. Każdy incydent produkcyjny staje się zanonimizowanym testem regresyjnym.

Scenariusze przechowuj jako wersjonowane dane, a nie ręczne prompty w notatniku. Oczekiwane decyzje powinny być przeglądane przy zmianie polityki. Dzięki temu zespół widzi, czy poprawa jednej bariery nie zepsuła innej funkcji.

Bezpieczne uruchamianie harnessu

Używaj atrap narzędzi i danych syntetycznych. Symulowane wysłanie wiadomości lub przelew nie może dotknąć realnego odbiorcy. Ogranicz sieć, czas, koszt i liczbę kroków; harness testujący pętlę agenta sam potrzebuje circuit breakera.

Bramka release blokuje potwierdzony wyciek, cross-tenant access lub wykonanie zabronionego narzędzia. Zmiany statystyczne i wzrost liczby odmów mogą wymagać analizy, ale nie zawsze oznaczają regresję krytyczną. Raport powinien pokazywać konkretną ścieżkę, artefakty i warstwę, która zawiodła.

Triaging nieudanego testu

Najpierw potwierdź, czy naruszenie osiągnęło rzeczywisty executor, czy pozostało tekstową deklaracją modelu. Następnie wskaż pierwszą granicę, która powinna je zatrzymać: parser wejścia, polityka, approval, sandbox lub narzędzie. Poprawka na najwcześniejszej możliwej warstwie zwykle ogranicza większą klasę ataków.

Zapisz minimalny reproduktor, pełny trace i warunki środowiska. Jeżeli wynik jest niestabilny, zwiększ liczbę prób i porównaj rozkład, zamiast wybierać tylko najbardziej efektowny przykład. Fałszywe alarmy opisuj równie dokładnie, bo nadmierna liczba blokad skłania zespoły do wyłączania zabezpieczeń.

Governance zestawu testów

Każdy scenariusz ma właściciela, klasyfikację wpływu, datę przeglądu i powiązaną kontrolę. Usunięcie testu wymaga uzasadnienia, a nie tylko informacji, że nowy model odpowiada inaczej. Oddziel publiczne benchmarki od prywatnych przypadków wynikających z architektury firmy.

Raport okresowy powinien pokazywać trend, nowe klasy nadużyć, czas naprawy i pokrycie narzędzi. Sama liczba promptów nie mierzy bezpieczeństwa; ważniejsze jest, czy testowane są wszystkie drogi prowadzące do realnego skutku.

Wyniki krytyczne wymagają reprodukcji w kontrolowanym środowisku i przypisania właściciela poprawki. Po wdrożeniu zabezpieczenia uruchom nie tylko pierwotny scenariusz, ale też sąsiednie przypadki legalne. W ten sposób zespół sprawdza zarówno zamknięcie luki, jak i koszt funkcjonalny nowej kontroli.

Przechowuj także wersję oczekiwanego wyniku. Zmiana polityki może legalnie zmienić decyzję testu, ale powinna być jawna, zrecenzowana i powiązana z analizą ryzyka.

Źródła: OWASP AI Agent Security, NIST — Agent Security Red Teaming.