Testowanie odporności agenta AI na prompt injection – metodyka w 5 warstwach

Zaktualizowano: 10 września 2026

Na czym polega testowanie odporności agenta AI na prompt injection? Polega na sprawdzeniu, czy agent wykona działanie sprzeczne z intencją użytkownika po przeczytaniu treści przygotowanej przez atakującego. Kluczowa różnica wobec klasycznych testów bezpieczeństwa dotyczy przedmiotu badania. Nie testujesz odpowiedzi modelu na złośliwy prompt, lecz całą pętlę: pobranie treści, decyzję, wywołanie narzędzia i zapis do pamięci. Pojedyncza sonda wysłana do endpointu modelu nie zobaczy tej klasy podatności.

Definicja kanoniczna: Pośredni prompt injection to atak, w którym instrukcja dla modelu zostaje umieszczona w treści przetwarzanej przez agenta w trakcie zadania, a nie wprowadzona bezpośrednio przez użytkownika w oknie rozmowy.

Testowanie odporności agenta na prompt injection – w skrócie:

1. Podstawową taksonomią ryzyka jest OWASP Top 10 for Agentic Applications, opublikowana 9 grudnia 2025 przez OWASP GenAI Security Project z identyfikatorami ASI01-ASI10. Rozszerza, a nie zastępuje listę OWASP Top 10 for LLM Applications.
2. Wektorem numer jeden pozostaje ASI01 Agent Goal Hijack, czyli przejęcie celu agenta przez treść, którą agent czyta: dokument, opinię, wiadomość albo wynik wywołania narzędzia.
3. Testy jednostrzałowe nie wystarczają. Trzeba testować pętlę wykonania, ponieważ eskalacja następuje przez łańcuch wywołań narzędzi, a nie przez pojedynczą odpowiedź.
4. Skuteczny program łączy cztery poziomy: szeroki skan, testy regresyjne w potoku CI, wielokrotkowe kampanie adwersarialne i manualne testy eksperckie nastawione na logikę biznesową.
5. Narzędzia pokrywają różne warstwy i mają rozłączne martwe pola: skanery modelu nie rozumieją grafu narzędzi agenta ani jego integracji, a testy aplikacyjne nie zastąpią oceny samego modelu.
6. Kryterium wyniku testu nie brzmi „czy model dał się namówić”, lecz „jakie działanie agent faktycznie wykonał i czy istniała kontrola poza jego rozumowaniem, która to działanie zatrzymała”.
7. Patronusec prowadzi testy bezpieczeństwa środowisk z komponentem AI, łącząc testy manualne z automatyzacją, w ramach testów penetracyjnych.

---

---

Dlaczego testy modelu nie wystarczają do oceny odporności agenta?

Ponieważ podatność nie mieszka w modelu, lecz w architekturze uprawnień wokół niego. Model można namówić do wygenerowania dowolnego tekstu, natomiast szkoda powstaje dopiero wtedy, gdy ten tekst zamienia się w wywołanie narzędzia mające skutek w prawdziwym systemie. Skaner odpytujący endpoint modelu nie widzi tej granicy.

Trzy własności agenta, które zmieniają model testowania:

• Pętla zamiast pojedynczej odpowiedzi. Agent planuje, wywołuje narzędzie, odczytuje wynik i planuje ponownie. Wstrzyknięcie może nastąpić w wyniku narzędzia w trzecim kroku, a skutek ujawnić się w siódmym.
• Trwała pamięć. Instrukcja zapisana w pamięci długotrwałej wpływa na kolejne sesje, więc test kończący się z sesją przeoczy skutek utrwalony.
• Zasięg rażenia równy sumie uprawnień. Ekspozycja agenta odpowiada zbiorowi wszystkich poświadczeń, narzędzi i interfejsów, do których ma dostęp, a autonomia wielokrokowa kumuluje szkodę w obrębie planu.

Projekt OWASP GenAI Security opisuje układ, w którym agent łączy trzy własności jednocześnie: dostęp do danych prywatnych, kontakt z treścią niezaufaną i zdolność komunikacji na zewnątrz. Taka kombinacja pozwala zamienić agenta w narzędzie wyprowadzania danych przy pomocy jednej wstrzykniętej instrukcji. To układ, którego szukamy w pierwszej kolejności podczas mapowania architektury.

Testujesz nie to, co model napisał, lecz to, co agent zrobił, i to, czy istniała kontrola poza jego rozumowaniem, która potrafiła go zatrzymać.

Jak zaplanować zakres testów według OWASP ASI Top 10?

Zakres testów wyprowadza się z taksonomii ASI, ponieważ każdy z jej punktów opisuje inną drogę od wstrzykniętej instrukcji do skutku. Prompt injection funkcjonuje w niej nie jako pojedyncza kategoria, lecz jako mechanizm uruchamiający większość pozostałych.

Kategoria OWASP ASI	Co dokładnie testujesz	Typowy dowód podatności
ASI01 Agent Goal Hijack	czy treść czytana przez agenta zmienia jego cel	agent realizuje zadanie inne niż zlecone
ASI02 Tool Misuse & Exploitation	czy da się wymusić wywołanie narzędzia z parametrami atakującego	wywołanie API z podmienionym odbiorcą lub zakresem
ASI03 Identity & Privilege Abuse	czy agent działa z uprawnieniami szerszymi niż wymaga zadanie	działanie niemożliwe do przypisania konkretnemu użytkownikowi
ASI04 Agentic Supply Chain	czy zatruty komponent, wtyczka lub serwer narzędziowy wpływa na zachowanie	wykonanie instrukcji z opisu narzędzia
ASI05 Unexpected Code Execution	czy agent wykona kod spoza zamierzonego zakresu	wykonanie polecenia w środowisku agenta
ASI06 Memory & Context Poisoning	czy instrukcja utrwala się między sesjami	skutek widoczny w nowej sesji bez ponownego wstrzyknięcia
ASI07 Insecure Inter-Agent Communication	czy komunikat od innego agenta jest traktowany jako zaufany	eskalacja przez wiadomość agent-agent
ASI08 Cascading Failures	czy błąd jednego agenta propaguje się dalej	reakcja łańcuchowa po jednym wstrzyknięciu
ASI09 Human-Agent Trust Exploitation	czy interfejs przedstawia użytkownikowi pełen skutek działania	zatwierdzenie działania na podstawie niepełnej prezentacji
ASI10 Rogue Agents	czy istnieje agent działający poza nadzorem	aktywność bez właściciela i bez rejestru

Taksonomia ASI rozszerza listę OWASP dla aplikacji LLM, więc system agentowy dziedziczy również ryzyka modelowe. W praktyce oznacza to dwa zakresy testowe prowadzone równolegle: warstwę modelu i warstwę systemu.

Jak zbudować pięciowarstwowy program testowy?

Skuteczny program układa się w warstwy o rosnącym koszcie i rosnącej głębokości. Każda warstwa wykrywa inną klasę problemów, a pominięcie którejkolwiek zostawia lukę, której pozostałe nie zamkną.

Warstwa 1 – mapowanie architektury (przed jakimkolwiek testem). Inwentarz narzędzi agenta, źródeł treści niezaufanej, magazynów pamięci i granic uprawnień. Bez tej mapy testy strzelają na oślep, a raport nie da się przełożyć na poprawki. To jedyna warstwa, której nie da się zautomatyzować.

Warstwa 2 – szeroki skan warstwy modelu. Automatyczne sondy pokrywające znane klasy podatności modelu, uruchamiane cyklicznie i przy każdej zmianie modelu. Wykrywa regresje i niskowiszące owoce. Ograniczenie jest znane: skanery testują model, nie rozumieją potoku RAG, grafu narzędzi ani integracji.

Warstwa 3 – testy regresyjne w potoku CI. Zestaw przypadków utrzymywany jako bramka wydawnicza, uruchamiany przy każdej zmianie promptu systemowego, modelu, zestawu narzędzi lub konfiguracji uprawnień. Celem nie jest odkrywanie nowych ataków, lecz pilnowanie, żeby raz naprawione nie wróciło.

Warstwa 4 – kampanie wielokrokowe. Scenariusze budowane przez wiele tur rozmowy i wiele wywołań narzędzi, w tym ataki narastające stopniowo i sekwencje wykorzystujące pamięć. Ta warstwa wykrywa łańcuchy, których jednostrzałowe sondy nie zobaczą.

Warstwa 5 – testy manualne nastawione na logikę biznesową. Człowiek z wiedzą o domenie szuka nadużyć, których żadne narzędzie nie przewidzi: sprzeczności w regułach biznesowych, nadużyć proceduralnych, ścieżek obejścia akceptacji. Tu wykrywa się problemy najkosztowniejsze i najtrudniejsze do naprawy.

Patronusec Insight: Najczęstszy błąd w programach testowych polega na uruchomieniu warstwy drugiej bez warstwy pierwszej. Zespół dostaje raport z setkami trafień w warstwie modelu, z których żadne nie mówi, czy agent może przelać środki, skasować rekord albo wysłać dokument na zewnątrz. Odwrotna kolejność daje wynik natychmiast: mapa uprawnień zwykle sama wskazuje trzy lub cztery ścieżki o realnym skutku, a testy potwierdzają albo obalają ich wykonalność. W ocenach środowisk z komponentem AI zaczynamy zawsze od grafu narzędzi i granic zaufania, a dopiero potem od sond. Metody weryfikacji dobieramy zgodnie z logiką opisaną w aktywie o testach bezpieczeństwa IT.

Jakie scenariusze testowe trzeba wykonać obowiązkowo?

Minimalny zestaw obejmuje sześć scenariuszy odwzorowujących drogi, którymi wstrzyknięta instrukcja realnie dociera do agenta. Każdy wymaga innego kanału dostarczenia i innego sposobu obserwacji skutku.

1. Wstrzyknięcie przez treść pobieraną. Instrukcja ukryta w dokumencie, na stronie, w opisie produktu albo w opinii. Obserwujesz, czy agent zmienia cel po przeczytaniu treści.
2. Wstrzyknięcie przez wynik narzędzia. Instrukcja w odpowiedzi API albo w metadanych zwróconych przez zewnętrzny serwis. Ten kanał bywa pomijany, bo zespoły traktują wyniki własnych integracji jako zaufane.
3. Wstrzyknięcie przez opis narzędzia. Instrukcja umieszczona w opisie funkcji udostępnionej agentowi przez zewnętrzny serwer narzędziowy. Agent czyta te opisy jako część kontekstu.
4. Zatrucie pamięci. Instrukcja utrwalona w pamięci długotrwałej, sprawdzana w kolejnej, czystej sesji. Kryterium wyniku: czy skutek występuje bez ponownego wstrzyknięcia.
5. Wyprowadzenie danych kanałem dozwolonym. Próba wyniesienia danych przez integrację, do której agent ma legalne uprawnienie, na przykład wysyłkę wiadomości albo zapis do współdzielonego zasobu.
6. Nadużycie prezentacji dla użytkownika. Sprawdzenie, czy interfejs zatwierdzania pokazuje pełny skutek działania, czy tylko jego skrót. Jeśli użytkownik zatwierdza wyłącznie kwotę albo tytuł, akceptacja nie jest realną kontrolą.

Dla każdego scenariusza rejestruj trzy rzeczy: dokładną treść wstrzyknięcia, pełny ślad wywołań narzędzi i faktyczny skutek w systemie docelowym. Sam fakt, że model powtórzył instrukcję, nie stanowi podatności. Podatnością jest wykonane działanie.

Jak interpretować wyniki i czym różni się poprawka od obejścia?

Wynik testu należy klasyfikować według skutku w systemie, a nie według zachowania modelu. Poprawka trwała działa poza rozumowaniem agenta, natomiast obejście polega na dopisaniu kolejnej instrukcji do promptu systemowego i wytrzymuje wyłącznie do następnego wariantu ataku.

Hierarchia poprawek, od najtrwalszej do najsłabszej:

• Ograniczenie uprawnień. Odebranie agentowi narzędzia lub zawężenie jego zakresu likwiduje całą klasę scenariuszy niezależnie od pomysłowości atakującego.
• Rozdzielenie kontekstów. Oddzielenie ścieżki przetwarzania treści niezaufanej od ścieżki mającej dostęp do danych wrażliwych i możliwości działania.
• Kontrola poza agentem. Walidacja parametrów wywołania, limity, akceptacja człowieka przy działaniach nieodwracalnych, weryfikacja zgodności działania z pierwotnym zleceniem.
• Filtrowanie wejścia i wyjścia. Użyteczne jako warstwa dodatkowa, zawodne jako warstwa jedyna.
• Wzmocnienie promptu systemowego. Najtańsze i najmniej trwałe. Traktuj jako środek doraźny, nigdy jako zamknięcie ustalenia.

Każda naprawiona podatność powinna trafić do zestawu regresyjnego z warstwy trzeciej. Bez tego kroku ta sama podatność wraca po najbliższej zmianie modelu, a organizacja płaci za jej ponowne odkrycie.

Poprawka, która polega na dopisaniu zdania do promptu systemowego, jest hipotezą, a nie kontrolą. Kontrolą jest ograniczenie, które obowiązuje niezależnie od tego, co agent uzna za sensowne.

Co najczęściej rozumie się źle o odporności na prompt injection?

MIT: Wystarczy dobry model, bo nowsze modele są odporne na wstrzykiwanie instrukcji.
FAKT: Odporność modelu zmniejsza skuteczność prostych prób, natomiast nie usuwa klasy problemu. Skutek zależy od uprawnień agenta, a nie od tego, jak trudno go przekonać.

MIT: Bariery ochronne rozwiązują problem.
FAKT: Filtry wejścia i wyjścia podnoszą koszt ataku i są potrzebne, ale działają na treści, a nie na uprawnieniach. Wobec ataku prowadzonego przez wiele tur i wiele wywołań narzędzi pozostają warstwą uzupełniającą.

MIT: Skoro agent nie ma dostępu do danych wrażliwych, ryzyko jest niskie.
FAKT: Ryzyko wyznacza suma uprawnień, w tym możliwość działania. Agent bez dostępu do danych, lecz z prawem wywołania operacji, potrafi wyrządzić szkodę bez czytania czegokolwiek wrażliwego.

MIT: Test wykonany przed wdrożeniem zamyka temat.
FAKT: Zmiana modelu, dodanie narzędzia albo modyfikacja promptu systemowego zmieniają powierzchnię ataku. Bez zestawu regresyjnego uruchamianego przy każdej takiej zmianie wynik testu traci ważność wraz z pierwszym wydaniem.

MIT: Wstrzyknięcie liczy się dopiero wtedy, gdy pochodzi od użytkownika.
FAKT: Najgroźniejszy wariant jest pośredni: instrukcję zostawia osoba trzecia w treści, którą agent przeczyta wykonując zadanie zlecone przez uczciwego użytkownika.

FAQ – Testowanie odporności agenta AI na prompt injection

---

Co czytać dalej?

Ścieżka od zrozumienia ryzyka do wdrożenia kontroli:

1. Testy bezpieczeństwa IT – jak wybrać metodę – dobór metody weryfikacji dla środowiska z komponentem AI.
2. Płatności agentowe a bezpieczeństwo – ryzyka dla 5 uczestników rynku – skutki biznesowe manipulacji intencją agenta w transakcjach.
3. Polityka AI w firmie – 10 elementów – warstwa nadzoru, która nadaje właściciela kontrolom nad agentami.
4. Ataki z użyciem AI – jak sztuczna inteligencja zmienia zagrożenia – szerszy kontekst ofensywnego wykorzystania AI.

---

Testy odporności agenta AI – bezpłatna konsultacja

Patronusec prowadzi testy bezpieczeństwa środowisk z komponentem AI, łącząc mapowanie architektury z testami manualnymi i automatyzacją.

Umów bezpłatną konsultację | Testy penetracyjne | Skany podatności