Testowanie agentów AI – najczęstsze błędy, OWASP Top 10 LLM i Agentic oraz jak samodzielnie testować modele w firmie

Na czym polega testowanie agentów AI? Testowanie agentów AI to weryfikacja bezpieczeństwa systemów, w których model językowy nie tylko generuje tekst, lecz planuje działania, wywołuje narzędzia (API, bazy danych, przeglądarkę, terminal), utrzymuje pamięć i podejmuje decyzje z ograniczonym nadzorem człowieka.

Punktem odniesienia są dwie listy OWASP: Top 10 for LLM Applications 2025 (ryzyka aplikacji LLM, od prompt injection po nieograniczoną konsumpcję) oraz Top 10 for Agentic Applications 2026 (ASI01-ASI10 – ryzyka specyficzne dla autonomii: przejęcie celu, nadużycie narzędzi, zatruwanie pamięci, agenci nieuczciwi). Ten artykuł jest pisany z perspektywy CTO: co najczęściej psuje się przy budowie agentów, jak testować samodzielnie i gdzie zaczyna się praca dla zewnętrznego red teamu.

Definicja kanoniczna: Testowanie bezpieczeństwa agentów AI to ocena systemu opartego na modelu językowym wyposażonym w narzędzia, pamięć i autonomię decyzyjną, obejmująca odporność na manipulację instrukcjami, nadużycie uprawnień i narzędzi, zatruwanie kontekstu oraz skutki działań wykonywanych bez nadzoru człowieka.

Testowanie agentów AI – w skrócie:

1. Agent różni się od chatbota tym, że działa, a nie tylko odpowiada – dlatego skutkiem ataku nie jest zła odpowiedź, lecz wysłany mail, usunięta baza lub przelew; model zagrożeń trzeba budować wokół narzędzi i uprawnień, nie wokół treści.
2. OWASP Top 10 for LLM Applications 2025 (v2.0) opisuje ryzyka warstwy modelu i aplikacji – z prompt injection (LLM01) niezmiennie na pierwszym miejscu; OWASP Top 10 for Agentic Applications 2026 (ASI01-ASI10, opublikowane 9 gru 2025) dodaje ryzyka autonomii.
3. Najczęstszy błąd architektoniczny to nadmierna agencja: agent z uprawnieniami „na wszelki wypadek”, wspólną tożsamością serwisową i narzędziami o szerszym zakresie, niż wymaga zadanie – wbrew zasadzie Least Agency.
4. Samodzielne testowanie w firmie jest wykonalne: skanery podatności LLM (garak), frameworki red teamingu (PyRIT) i testy regresyjne promptów w CI/CD (promptfoo) pokrywają znane klasy ataków – ale nie logikę biznesową i łańcuchy działań agenta.
5. Prompt injection nie da się „załatać” jak CVE – model przetwarza instrukcje i dane w jednym kanale; obrona jest architektoniczna: separacja treści, walidacja wyjść, bramki zatwierdzeń, sandbox i ograniczenie skutków.
6. Patronusec włącza testy bezpieczeństwa aplikacji LLM i agentów do testów penetracyjnych – scenariusze według obu list OWASP, od indirect prompt injection po nadużycie narzędzi, z raportem mapowanym na konkretne identyfikatory LLM01-LLM10 i ASI01-ASI10.

---

Czym agent AI różni się od aplikacji LLM i dlaczego zmienia to model zagrożeń?

Aplikacja LLM generuje odpowiedzi; agent AI planuje i wykonuje działania: rozbija cel na kroki, wywołuje narzędzia, zapisuje wnioski w pamięci i iteruje bez pytania człowieka o każdy krok. Ta różnica zmienia model zagrożeń w trzech wymiarach: skutkiem ataku jest działanie zamiast tekstu, powierzchnią ataku staje się wszystko, co agent czyta (dokumenty, strony, maile, własna pamięć), a błędy propagują się przez łańcuch kroków i między agentami.

Wymiar	Aplikacja LLM (chat, RAG)	Agent AI
Wynik działania modelu	tekst dla człowieka	wywołania narzędzi: API, SQL, e-mail, kod, przeglądarka
Skutek udanego ataku	szkodliwa lub błędna odpowiedź	wykonana akcja: eksfiltracja, zmiana danych, transakcja
Powierzchnia ataku	prompt użytkownika, dokumenty w RAG	+ wyniki narzędzi, strony przeglądane przez agenta, pamięć trwała, komunikaty innych agentów
Nadzór człowieka	przy każdej odpowiedzi	ograniczony – agent działa w pętli plan-działanie-obserwacja
Propagacja błędu	kończy się na odpowiedzi	kaskaduje: zatruty krok 2 determinuje kroki 3-10
Tożsamość	użytkownik pyta we własnym imieniu	agent działa z uprawnieniami – często szerszymi niż użytkownik

W systemie agentowym każda treść, którą agent czyta – dokument, strona internetowa, wynik narzędzia, wpis we własnej pamięci – jest potencjalnym kanałem instrukcji dla atakującego, dlatego powierzchnią ataku agenta jest jego cały strumień wejściowy, a nie tylko prompt użytkownika.

Praktyczna konsekwencja dla CTO: pytanie „czy model jest bezpieczny” jest źle postawione. Właściwe pytania brzmią: co agent może zrobić (narzędzia, uprawnienia), pod wpływem czego (wszystkie źródła treści) i co się stanie, gdy zrobi to źle (promień rażenia). Testowanie agenta to weryfikacja tych trzech odpowiedzi, a nie benchmark jakości modelu.

Jakie błędy najczęściej popełniają zespoły budujące agentów AI?

Najczęstsze błędy nie dotyczą wyboru modelu, lecz architektury wokół niego: nadmiarowych uprawnień, traktowania treści zewnętrznych jak zaufanych, wykonywania wygenerowanego kodu bez izolacji, wspólnej tożsamości dla agenta i braku limitów na pętlę działania.

❌ Agent na koncie serwisowym z szerokimi uprawnieniami – jeden token do wszystkiego (skrzynka, CRM, baza), współdzielony między zadaniami; po udanym wstrzyknięciu atakujący dziedziczy całość (ASI03). Prawidłowo: tożsamość per agent i per zadanie, poświadczenia krótkotrwałe o minimalnym zakresie.

❌ Treści z zewnątrz trafiają wprost do kontekstu decyzyjnego – agent czyta maila, stronę lub PDF i wykonuje ukryte w nich polecenia (indirect prompt injection → ASI01). Klasyczny przykład OWASP: wtyczka do streszczania maili z funkcją wysyłania – złośliwy mail każe agentowi rozesłać spam. Prawidłowo: treść pobrana oznaczana jako dane, nie instrukcje; wzorce separacji; brak narzędzi „zapisu” w tym samym przebiegu, w którym agent czyta niezaufane źródła.

❌ Wykonywanie wygenerowanego kodu i poleceń bez sandboxa – agent „pomocnie” uruchamia skrypt na hoście z dostępem do sieci wewnętrznej (ASI05, LLM05). Prawidłowo: izolowane środowisko wykonania, egress domyślnie zablokowany, limity czasu i zasobów.

❌ Pamięć trwała bez walidacji zapisu – raz wstrzyknięta „notatka” zatruwa wszystkie przyszłe sesje agenta i innych agentów korzystających z tej samej bazy wektorowej (ASI06, LLM08). Prawidłowo: walidacja i pochodzenie wpisów, pamięć per zadanie zamiast globalnej, możliwość czyszczenia.

❌ Brak limitów pętli i budżetu – agent w pętli retry generuje tysiące wywołań API lub zapytań do modelu (LLM10, ASI08 – kaskada). Prawidłowo: limity kroków, kosztów i czasu, wyłącznik awaryjny.

❌ Zatwierdzenie człowieka na podstawie streszczenia agenta – użytkownik klika „OK” na opisie akcji napisanym przez agenta, nie na surowej akcji (ASI09). Prawidłowo: bramka pokazuje dokładne wywołanie (adresat, kwota, zapytanie SQL), nie narrację.

❌ Testowanie tylko „szczęśliwej ścieżki” przed wdrożeniem – demo działa, więc produkcja jedzie; nikt nie próbował wstrzyknięcia przez dane, konfliktu celów ani awarii narzędzia w połowie łańcucha.

Większość incydentów z agentami AI nie wynika ze słabości modelu, lecz z decyzji architektonicznych podjętych wokół niego: nadmiarowych uprawnień, zaufania do treści zewnętrznych i braku izolacji wykonywanych działań.

Co obejmuje OWASP Top 10 for LLM Applications 2025 i które ryzyka dotyczą także agentów?

OWASP Top 10 for LLM Applications 2025 (v2.0, opublikowana 18 lis 2024 przez OWASP GenAI Security Project) porządkuje dziesięć ryzyk warstwy modelu i aplikacji – wszystkie dotyczą również agentów, bo agent jest aplikacją LLM z rozszerzoną powierzchnią. Nowości względem wydania 2023 odzwierciedlają praktykę produkcyjną: wyciek promptu systemowego (LLM07), słabości wektorów i osadzeń w RAG (LLM08) oraz nieograniczona konsumpcja (LLM10).

ID	Ryzyko	Istota	Znaczenie dla agenta
LLM01	Prompt Injection	wejście (bezpośrednie lub ukryte w treści) zmienia zachowanie modelu	główny wektor przejęcia celu agenta; wariant multimodalny – instrukcje w obrazach
LLM02	Sensitive Information Disclosure	wyciek sekretów, PII, danych firmowych przez odpowiedzi lub ślady	agent z dostępem do systemów ma czym wyciekać; eksfiltracja przez narzędzia (np. żądanie HTTP z danymi w URL)
LLM03	Supply Chain	skompromitowane modele, adaptery, zależności	+ serwery MCP, definicje narzędzi, wtyczki pobierane dynamicznie
LLM04	Data and Model Poisoning	zatrute dane treningowe lub dostrajające	zatruty korpus RAG działa jak trwałe wstrzyknięcie
LLM05	Improper Output Handling	wyjście modelu wykonywane bez walidacji (XSS, SSRF, RCE)	wyjście agenta to wywołania narzędzi – walidacja parametrów jest krytyczna
LLM06	Excessive Agency	nadmiar funkcji, uprawnień lub autonomii	rozszerzone w 2025 właśnie z powodu architektur agentowych; fundament ASI02-ASI03
LLM07	System Prompt Leakage	ujawnienie promptu systemowego i sekretów w nim	ujawnia atakującemu narzędzia, ograniczenia i sposób ich obejścia
LLM08	Vector and Embedding Weaknesses	manipulacja bazą wektorową i pobieraniem kontekstu	pamięć agenta zwykle stoi na tej samej infrastrukturze
LLM09	Misinformation	konfabulacje przyjmowane jako fakty	agent działa na podstawie konfabulacji (np. instaluje nieistniejący, podstawiony pakiet)
LLM10	Unbounded Consumption	zapytania wyczerpujące zasoby i budżet; ekstrakcja modelu	pętle agenta mnożą koszt; wektor DoS

Prompt injection utrzymuje pierwsze miejsce w OWASP Top 10 dla aplikacji LLM od pierwszego wydania, ponieważ model przetwarza instrukcje i dane w jednym kanale językowym – żadna pojedyncza kontrola nie zamyka tej klasy ataku, a obrona musi być warstwowa.

Dla zespołu wdrażającego ważna jest jeszcze jedna obserwacja z dokumentu OWASP: ryzyka się łańcuchują. Typowy scenariusz produkcyjny to LLM01 → LLM05/LLM06: wstrzyknięta instrukcja (przez dokument w RAG) powoduje wygenerowanie wyjścia, które aplikacja wykonuje z uprawnieniami agenta. Testy muszą więc sprawdzać łańcuchy, nie pojedyncze kategorie.

Co dodaje OWASP Top 10 for Agentic Applications 2026 (ASI01-ASI10)?

OWASP Top 10 for Agentic Applications 2026 – opublikowana 9 gru 2025 przez OWASP GenAI Security Project, po recenzji ponad 100 ekspertów i premierze na Black Hat Europe 2025 – kataloguje dziesięć ryzyk specyficznych dla systemów autonomicznych: planujących, używających narzędzi, utrzymujących pamięć i koordynujących się z innymi agentami. Zasadą architektoniczną spinającą całą listę jest Least Agency: agentowi przyznaje się minimum autonomii potrzebne do bezpiecznego, ograniczonego zadania.

ID	Ryzyko	Istota	Pierwsza linia obrony	Powiązanie z LLM Top 10
ASI01	Agent Goal Hijack	atakujący zmienia cel agenta przez złośliwą treść	treść pobrana = niezaufana; cele ograniczone i jawne	LLM01
ASI02	Tool Misuse and Exploitation	legalne narzędzia użyte w niebezpieczny sposób	zakres narzędzi per zadanie; walidacja parametrów	LLM06
ASI03	Identity and Privilege Abuse	agent dziedziczy lub eskaluje uprawnienia	tożsamość per agent; krótkotrwałe poświadczenia o wąskim zakresie	LLM06
ASI04	Agentic Supply Chain	skompromitowane narzędzia, wtyczki, serwery MCP	podpisane komponenty; AIBOM i pochodzenie; pinowanie wersji	LLM03
ASI05	Unexpected Code Execution	agent generuje lub uruchamia kod/polecenia niebezpiecznie	sandbox; egress domyślnie zablokowany	LLM01, LLM05
ASI06	Memory and Context Poisoning	zatruta pamięć agenta i bazy RAG wpływają na przyszłe decyzje	walidacja zapisów; kontekst efemeryczny per zadanie	LLM04, LLM08
ASI07	Insecure Inter-Agent Communication	podszywanie się i manipulacja w systemach wieloagentowych	wzajemne uwierzytelnianie; podpisane komunikaty	–
ASI08	Cascading Failures	drobny błąd propaguje się przez planowanie i wykonanie	izolacja promienia rażenia; bezpieczniki (circuit breakers)	–
ASI09	Human-Agent Trust Exploitation	użytkownik nadmiernie ufa rekomendacjom agenta	wymuszone potwierdzenia pokazujące surową akcję	LLM09
ASI10	Rogue Agents	skompromitowany agent działa szkodliwie, wyglądając legalnie	monitoring behawioralny; wyłączniki awaryjne	–

Zasada Least Agency – przyznawania agentowi wyłącznie minimalnej autonomii wymaganej do bezpiecznego, ograniczonego zadania – jest architektonicznym fundamentem całej listy OWASP Top 10 for Agentic Applications 2026.

Warto zwrócić uwagę na trzy pozycje bez odpowiednika w liście LLM, bo to one wyznaczają „nową” pracę testową: ASI07 (komunikacja między agentami – kto uwierzytelnia komunikat „od agenta zatwierdzającego”?), ASI08 (kaskady – jeden zatruty stan uruchamia destrukcyjne działania wielu agentów) i ASI10 (agent nieuczciwy – utrzymujący się między sesjami, podszywający się pod zaufany system). Każda pozycja listy ma udokumentowany incydent rzeczywisty – od ukrytych promptów zamieniających copiloty w kanały eksfiltracji po autonomicznego agenta kodującego, który usunął produkcyjną bazę danych podczas code freeze.

Jak samodzielnie testować modele i agentów w firmie – narzędzia i proces?

Samodzielne testowanie opiera się na trzech warstwach: automatycznych skanerach podatności LLM uruchamianych okresowo (garak), frameworkach do półautomatycznego red teamingu scenariuszy (PyRIT) oraz testach regresyjnych promptów i polityk w potoku CI/CD (promptfoo), uzupełnionych manualnymi sesjami adwersarialnymi zespołu. Zasada jest ta sama, co przy skanach aplikacji: automat pokrywa znane klasy, człowiek – logikę i łańcuchy.

Warstwa	Narzędzia (open source)	Co pokrywa	Czego nie pokrywa	Kiedy uruchamiać
Skan podatności LLM	garak (NVIDIA) – kilkadziesiąt sond: jailbreaki, wycieki, toksyczność, halucynacje pakietów	znane wzorce ataków na model i prompt systemowy	kontekst biznesowy, narzędzia agenta	okresowo i po zmianie modelu lub promptu systemowego
Red teaming scenariuszy	PyRIT (Microsoft) – orkiestracja ataków wieloetapowych, konwersje ładunków; giskard – skan + testy	ataki adaptacyjne, sekwencje, warianty kodowania	pełna ocena skutków w systemach docelowych	przed wdrożeniem i przy istotnych zmianach
Regresja w CI/CD	promptfoo – asercje na wyjścia, wbudowane pluginy red team mapowane na OWASP LLM i Agentic	pilnowanie, że poprawka nie cofa się z kolejnym wydaniem	nowe, nieznane klasy ataków	każdy build / pull request
Testy manualne	sesje adwersarialne zespołu + scenariusze z OWASP AI Testing Guide	logika biznesowa, łańcuchy LLM01→LLM06, nadużycie narzędzi	skala i systematyczność	przed wdrożeniem, kwartalnie

Proces, który działa w praktyce (i który da się wdrożyć siłami zespołu w 2-4 tygodnie):

1. Model zagrożeń per agent – lista narzędzi z uprawnieniami, źródeł treści i skutków najgorszego przypadku; mapowanie na ASI01-ASI10 jako checklist projektowy.
2. Zestaw testów bazowych – garak przeciwko endpointowi modelu/aplikacji; wyniki jako punkt odniesienia.
3. Scenariusze agentowe – dla każdego narzędzia: „co się stanie, jeśli treść wejściowa każe go użyć inaczej?”; ładunki indirect injection w dokumentach, mailach, stronach testowych; próby eksfiltracji przez parametry narzędzi (URL, adresat, treść zapytania).
4. Bramki w CI/CD – promptfoo z progami blokującymi: żadna zmiana promptu, modelu ani definicji narzędzi nie wchodzi bez przejścia zestawu; dokładnie ta sama logika, co bramki SAST/SCA.
5. Rejestr ustaleń – każda podatność z identyfikatorem OWASP, właścicielem i terminem, w tym samym procesie co zarządzanie podatnościami infrastruktury.

Automatyczne skanery podatności LLM pokrywają znane wzorce ataków, ale nie odpowiedzą na pytanie, co agent zrobi z Twoimi narzędziami pod wpływem wrogiej treści – tę odpowiedź dają scenariusze budowane z modelu zagrożeń konkretnego agenta.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że zespoły zaczynające od narzędzi („odpalmy skaner”) utykają na setkach niskowartościowych ustaleń, a zespoły zaczynające od modelu zagrożeń znajdują krytyczne problemy w dniach. Najskuteczniejsze pierwsze ćwiczenie nie wymaga żadnego narzędzia: weź listę narzędzi swojego agenta i dla każdego dokończ zdanie „atakujący, który kontroluje dowolny dokument czytany przez agenta, może za pomocą tego narzędzia…”. Jeśli którakolwiek odpowiedź zawiera „wysłać”, „usunąć” albo „przelać” bez bramki zatwierdzenia – masz priorytet zanim uruchomisz pierwszy skan. W testach penetracyjnych aplikacji LLM zaczynamy dokładnie od tego ćwiczenia z zespołem klienta.

Jakie praktyki architektoniczne najskuteczniej ograniczają ryzyko agentów?

Skuteczna obrona jest warstwowa i architektoniczna, bo prompt injection nie ma „łatki”: separacja instrukcji od danych, najmniejsza agencja w narzędziach i tożsamości, walidacja wyjść przed wykonaniem, bramki człowieka na działaniach nieodwracalnych, sandbox z kontrolą egress dla kodu, pamięć walidowana i efemeryczna oraz monitoring behawioralny z wyłącznikiem awaryjnym.

Osiem praktyk w kolejności wdrażania:

1. Least Agency w narzędziach – narzędzia definiowane per zadanie, nie per agent; parametry walidowane schematem (lista dozwolonych domen, limity kwot, whitelist tabel); operacje odczytu i zapisu rozdzielone.
2. Tożsamość per agent i per zadanie – żadnych współdzielonych kont serwisowych; poświadczenia krótkotrwałe, wąsko zakresowane, rotowane; działania agenta atrybuowalne w logach (ASI03, ASI07).
3. Separacja treści niezaufanych – treść pobrana (RAG, web, mail) opakowana i oznaczona jako dane; polityka „read-only w przebiegach czytających niezaufane źródła” – agent, który w tym samym łańcuchu czyta internet i może wysyłać dane, jest z definicji kanałem eksfiltracji.
4. Walidacja wyjść przed wykonaniem – wyjście modelu traktowane jak każde niezaufane wejście (LLM05): parsowanie strukturalne, odrzucanie wywołań spoza schematu, sanityzacja przed renderowaniem.
5. Bramki człowieka pokazujące surową akcję – dla działań nieodwracalnych lub finansowych: dokładne wywołanie (adresat, kwota, polecenie), nie streszczenie agenta (ASI09); progi kwotowe i kategorie wymagające zatwierdzenia zapisane w polityce, nie w prompcie.
6. Sandbox i kontrola egress dla kodu – wykonanie w izolacji, sieć wychodząca domyślnie zablokowana z listą wyjątków, limity CPU/czasu/dysku (ASI05).
7. Pamięć z pochodzeniem i terminem życia – zapisy walidowane, oznaczone źródłem, per zadanie tam, gdzie to możliwe; okresowe czyszczenie; testy odczytu pamięci w scenariuszach (ASI06).
8. Limity, monitoring, wyłącznik – budżet kroków/kosztów per przebieg, alerty na anomalie behawioralne (nagła zmiana wzorca wywołań narzędzi), udokumentowany kill switch i procedura odcięcia agenta (ASI08, ASI10, LLM10).

Obrona przed atakami na agentów AI nie polega na doskonaleniu promptu systemowego, lecz na architekturze ograniczającej skutki: agent, którego najgorszy możliwy błąd jest odwracalny i widoczny, pozostaje bezpieczny nawet wtedy, gdy manipulacja modelem się powiedzie.

Dwie uwagi porządkujące dla CTO. Po pierwsze, komponenty agentowe to także klasyczny łańcuch dostaw oprogramowania: serwery MCP, definicje narzędzi i modele podlegają tym samym zasadom co biblioteki – inwentaryzacja (AIBOM/SBOM), pinowanie wersji, weryfikacja pochodzenia – czyli praktykom znanym z SCA i SBOM oraz obowiązkom, które CRA nakłada na producentów. Po drugie, jeśli organizacja podlega AI Act, dokumentacja modelu zagrożeń i testów agenta zasili obowiązki dla systemów wysokiego ryzyka – warto projektować ją od początku w formacie dowodowym.

Kiedy samodzielne testy wystarczą, a kiedy potrzebny jest zewnętrzny red teaming AI?

Samodzielne testy wystarczają do higieny ciągłej: regresji znanych ataków, bramek w CI/CD i weryfikacji podstawowych scenariuszy nadużycia narzędzi. Zewnętrzny test jest potrzebny w czterech sytuacjach: przed udostępnieniem agenta klientom lub na dane produkcyjne, gdy agent dostaje narzędzia o skutkach nieodwracalnych, gdy wymaga tego klient lub regulacja oraz gdy wewnętrzny zespół testuje własny projekt – i przestaje widzieć jego założenia.

Granica przebiega wzdłuż trzech pytań:

• Czy umiemy myśleć jak atakujący naszego systemu? Zespół, który budował agenta, testuje w ramach własnych założeń; zewnętrzny tester łamie założenia – to ta sama logika, dla której pentest nie jest skanem.
• Czy skutki błędu są odwracalne? Agent piszący szkice odpowiedzi znosi iterację na produkcji; agent z dostępem do przelewów, produkcyjnej bazy lub skrzynki zarządu – nie.
• Czy ktoś od nas tego wymaga? Ankiety due diligence klientów coraz częściej zawierają sekcję AI; dla podmiotów regulowanych testy aplikacji, w tym opartych na LLM, wchodzą w programy testów z DORA art. 24-25 i analizy ryzyka ISO 27001.

Zewnętrzny test bezpieczeństwa agenta AI jest odpowiednikiem testu penetracyjnego aplikacji: weryfikuje łańcuchy ataku i logikę, których automatyczne skanery nie modelują, i dostarcza raport, który można przedstawić klientowi lub audytorowi.

Patronusec realizuje testy bezpieczeństwa aplikacji LLM i agentów jako moduł testów penetracyjnych: scenariusze budowane z modelu zagrożeń klienta, ataki według OWASP Top 10 LLM 2025 i Agentic 2026 (indirect injection przez RAG i pocztę, nadużycie i łańcuchowanie narzędzi, eksfiltracja przez parametry, zatruwanie pamięci, obejścia bramek zatwierdzeń), a raport mapuje każde ustalenie na identyfikator LLM/ASI z rekomendacją architektoniczną – w formacie gotowym pod audyt i ankiety klientów.

Checklist CTO – 12 pytań kontrolnych przed wdrożeniem agenta

1. Czy istnieje spisany model zagrożeń agenta: narzędzia, uprawnienia, źródła treści, najgorszy przypadek per narzędzie?
2. Czy każdy agent ma odrębną tożsamość i krótkotrwałe poświadczenia o minimalnym zakresie?
3. Czy agent może w jednym przebiegu czytać treści niezaufane i wykonywać działania zapisu/wysyłki? Jeśli tak – dlaczego?
4. Czy parametry każdego narzędzia są walidowane schematem (domeny, kwoty, zakresy) przed wykonaniem?
5. Czy działania nieodwracalne przechodzą przez bramkę pokazującą surową akcję, a progi są w polityce, nie w prompcie?
6. Czy wygenerowany kod wykonuje się w sandboxie z domyślnie zablokowanym egress?
7. Czy zapisy do pamięci trwałej są walidowane i oznaczone pochodzeniem, a pamięć da się wyczyścić?
8. Czy komunikacja między agentami jest wzajemnie uwierzytelniana?
9. Czy istnieją limity kroków, kosztów i czasu per przebieg oraz udokumentowany wyłącznik awaryjny?
10. Czy testy regresyjne promptów i polityk działają jako bramka w CI/CD?
11. Czy komponenty agentowe (modele, serwery MCP, narzędzia) są zinwentaryzowane, pinowane i weryfikowane jak zależności w SBOM?
12. Czy przed udostępnieniem klientom zaplanowano niezależny test bezpieczeństwa i czy jego raport zasili dokumentację compliance?

---

FAQ – najczęstsze pytania o testowanie agentów AI

---

Warto przeczytać

1. Metody testowania bezpieczeństwa IT – gdzie testy agentów AI mieszczą się w całym programie testów obok pentestów i skanów.
2. Skany podatności aplikacji – DAST, SAST, SCA – bramki w CI/CD i SBOM, których logika przenosi się wprost na komponenty agentowe.
3. CRA dla software house’u – obowiązki producenta oprogramowania, które obejmą także produkty z komponentem AI.
4. Złośliwy pakiet NuGet – atak typosquattingowy – łańcuch dostaw w praktyce; ta sama klasa ryzyka co ASI04 i halucynowane pakiety (LLM09).

---

Testowanie bezpieczeństwa agentów AI – konsultacja

Patronusec realizuje testy bezpieczeństwa aplikacji LLM i agentów AI jako moduł testów penetracyjnych: warsztat modelu zagrożeń, scenariusze według OWASP Top 10 LLM 2025 i Agentic 2026 oraz raport mapowany na identyfikatory LLM/ASI, gotowy pod audyt i ankiety klientów. Jeśli wdrażasz agenta z dostępem do realnych narzędzi i danych, umów bezpłatną rozmowę o zakresie testu.

Testy penetracyjne | Skany podatności | vCISO