OWASP Top 10 dla aplikacji agentowych (ASI01–ASI10): wektory ataku i podatność każdego ryzyka

Agenty AI przestały być tylko wersją pokazową. Same wywołują narzędzia, czytają pocztę, sięgają po API, uruchamiają kod i podejmują decyzje bez człowieka klikającego „zatwierdź“ przy każdym kroku. Przez to obszar ataku przesuwa się tam, gdzie klasyczne listy podatności nigdy nie zaglądały. Dlatego w grudniu 2025 roku projekt OWASP Gen AI Security wydał osobną listę: OWASP Top 10 dla aplikacji agentowych, oznaczoną kodami od ASI01 do ASI10.

Czym jest OWASP Top 10 dla aplikacji agentowych i co oznacza ASI01–ASI10?

OWASP Top 10 dla aplikacji agentowych to lista dziesięciu najpoważniejszych ryzyk bezpieczeństwa charakterystycznych dla systemów, w których agent AI działa autonomicznie — sam planuje, wywołuje narzędzia i komunikuje się z innymi agentami. Kody od ASI01 do ASI10 (skrót od Agentic Security Issues) numerują te ryzyka od najważniejszego. Listę opublikowano 9 grudnia 2025 roku; prowadzili ją John Sotiropoulos, Keren Katz i Ron F. Del Rosario, a recenzowały setki współtwórców z branży.

Lista ASI to jeden z frameworkowych filarów, na których opieramy nasz przegląd krajobrazu zagrożeń agentów AI w 2026. Kluczowa różnica wobec wcześniejszej listy OWASP dla modeli językowych (LLM Top 10) jest taka: tamta opisywała ryzyka pojedynczego modelu, który odpowiada na zapytanie. Tutaj problemem jest autonomia i sprawczość — agent nie tylko generuje tekst, lecz wykonuje działania w prawdziwych systemach. Pomyłka modelu zamienia się w realne polecenie wysłane do API, w usunięty plik, w przelew. Poniżej omawiam każde z dziesięciu ryzyk: czym jest, na czym pokazał się w praktyce i jaka jest jedna główna ochrona, od której warto zacząć.

Tabela skrótowa: ASI01–ASI10 w jednym spojrzeniu

Kod	Ryzyko	Sedno problemu	Główna ochrona
ASI01	Przejęcie celu agenta	Atakujący podmienia intencję agenta	Rozdzielenie instrukcji od danych
ASI02	Nadużycie narzędzi	Niebezpieczne wywołania narzędzi	Najmniejsze uprawnienia narzędzi + walidacja
ASI03	Nadużycie tożsamości i uprawnień	Agent działa z cudzymi prawami	Osobna tożsamość agenta, krótkie tokeny
ASI04	Podatności łańcucha dostaw	Złośliwe wtyczki, serwery MCP, rejestry	Weryfikacja źródeł i podpisów komponentów
ASI05	Niezamierzone wykonanie kodu	Agent uruchamia generowany kod	Izolowane środowisko (sandbox)
ASI06	Zatrucie pamięci i kontekstu	Skażona pamięć kształtuje przyszłe decyzje	Higiena i izolacja pamięci
ASI07	Niebezpieczna komunikacja między agentami	Podszyte wiadomości między agentami	Uwierzytelnianie i podpisywanie komunikatów
ASI08	Kaskadowe awarie	Jeden błąd rozlewa się po potoku	Bezpieczniki i ograniczanie tempa
ASI09	Nadużycie zaufania człowiek–agent	Agent skłania człowieka do złej decyzji	Czytelne uzasadnienia + punkty kontroli
ASI10	Agenty wymknięte spod kontroli	Skompromitowany lub dryfujący agent działa dalej	Ciągły nadzór i wyłącznik awaryjny

ASI01: Przejęcie celu agenta (Agent Goal Hijack)

Agent dostaje cel od użytkownika, ale po drodze czyta treści z zewnątrz — maila, stronę, dokument. Jeśli w tej treści ukryto polecenie, agent może je potraktować jak własne zadanie i zmienić kurs. To prompt injection podniesione do rangi przejęcia całej misji.

Pokazowym przykładem jest EchoLeak — atak, w którym sam tekst wiadomości wystarczał, by skłonić asystenta do wycieku danych, bez żadnego kliknięcia ofiary. Wystarczyło, że agent przeczytał spreparowaną treść; jego pełną sekcję zwłok wraz z dwoma innymi realnymi naruszeniami opisujemy osobno.

Główna ochrona: twarde rozdzielenie instrukcji od danych. Treści pobrane ze świata zewnętrznego traktuj jako dane do przetworzenia, nigdy jako polecenia do wykonania, i oznaczaj ich pochodzenie na każdym etapie.

ASI02: Nadużycie narzędzi (Tool Misuse)

Agent zyskuje moc dzięki narzędziom: wysyłaniu maili, zapytaniom do bazy, wywołaniom API. Nadużycie narzędzi to sytuacja, w której agent — namówiony lub przez własny błąd — używa ich w sposób szkodliwy albo poza zamierzonym zakresem.

Branża wskazuje tu na incydent z asystentem Amazon Q, gdzie udało się wprowadzić polecenia prowadzące do destrukcyjnych operacji. Narzędzie samo w sobie było legalne — problemem było to, do czego je nakłoniono.

Główna ochrona: zasada najmniejszych uprawnień dla każdego narzędzia plus walidacja argumentów. Operacje nieodwracalne (usuwanie, płatności, masowa wysyłka) chowaj za jawnym potwierdzeniem albo całkiem poza zasięgiem agenta. Konkretne wzorce architektoniczne, które to egzekwują, rozwijamy w materiałach o obronie i utwardzaniu agentów.

ASI03: Nadużycie tożsamości i uprawnień (Identity & Privilege Abuse)

Częsty skrót w projektach: agent dziedziczy poświadczenia człowieka lub konta usługowego o szerokich prawach i działa „jako ktoś inny“. Gdy zostanie zmanipulowany, robi to z pełnią cudzych uprawnień — a w logach wygląda to jak działanie zaufanego użytkownika.

Główna ochrona: nadaj agentowi własną, odrębną tożsamość z wąskim zakresem dostępu i krótko żyjącymi tokenami. Dzięki temu da się odróżnić działania agenta od działań człowieka i szybko odebrać mu prawa.

ASI04: Podatności łańcucha dostaw (Agentic Supply Chain Vulnerabilities)

Agenty składa się z cudzych klocków: wtyczek, bibliotek, rejestrów narzędzi i serwerów MCP, które podłączają zewnętrzne możliwości. Każdy taki element to potencjalne wejście dla atakującego — wystarczy podstawić złośliwy komponent.

OWASP przywołuje tu udokumentowane nadużycie integracji z GitHub przez MCP, gdzie zewnętrzny element wpłynął na zachowanie agenta. Zaufanie do „gotowego łącznika“ okazało się słabym ogniwem.

Główna ochrona: weryfikuj pochodzenie i integralność każdego komponentu — podpisy, przypięte wersje, lista dozwolonych serwerów MCP. Nie podłączaj narzędzi spoza zaufanego rejestru.

ASI05: Niezamierzone wykonanie kodu (Unexpected Code Execution)

Wiele agentów potrafi pisać i uruchamiać kod, żeby wykonać zadanie. To potężna funkcja i jednocześnie prosta droga do zdalnego wykonania kodu na maszynie, na której agent działa — jeśli wygenerowany kod jest złośliwy lub po prostu błędny.

Dobrze opisany jest przypadek AutoGPT, gdzie udało się doprowadzić do wykonania kodu poza zamierzonym zakresem. Agent zrobił dokładnie to, o co poproszono — tyle że prośba była pułapką.

Główna ochrona: uruchamiaj generowany kod wyłącznie w izolowanym środowisku (sandbox) z odciętą siecią, ograniczonym systemem plików i limitem zasobów. Nigdy nie wykonuj go bezpośrednio na hoście agenta.

ASI06: Zatrucie pamięci i kontekstu (Memory & Context Poisoning)

Agenty zapamiętują — notatki, historię rozmów, dane pobrane z bazy wiedzy. Zatrucie polega na wstrzyknięciu do tej pamięci fałszywej lub szkodliwej treści, która później cicho kształtuje decyzje. Atak nie musi działać natychmiast: skażony zapis czeka i uruchamia się przy następnym zadaniu.

Przykładem jest opisany atak na pamięć asystenta Gemini, gdzie udało się trwale zapisać manipulację wpływającą na późniejsze odpowiedzi.

Główna ochrona: higiena pamięci — oddzielaj pamięć per użytkownik i per sesja, sprawdzaj zawartość przed zapisem i pozwalaj na rewizję oraz czyszczenie tego, co agent „zapamiętał“.

ASI07: Niebezpieczna komunikacja między agentami (Insecure Inter-Agent Communication)

W układach wieloagentowych agenty wysyłają sobie nawzajem zadania i wyniki. Jeśli te komunikaty nie są uwierzytelniane, atakujący może podszyć się pod jednego z agentów i skierować całą grupę na manowce — fałszywa wiadomość rozchodzi się po sieci jak prawdziwa.

Główna ochrona: uwierzytelniaj i podpisuj każdy komunikat między agentami. Żaden agent nie powinien ufać poleceniu tylko dlatego, że „przyszło od innego agenta“.

ASI08: Kaskadowe awarie (Cascading Failures)

Agenty łączy się w potoki: wynik jednego jest wejściem drugiego. Pojedynczy fałszywy sygnał albo błąd potrafi się rozlać przez cały łańcuch i narastać — automatyzacja, która miała przyspieszać, przyspiesza też katastrofę.

Główna ochrona: wbuduj bezpieczniki — ograniczanie tempa działań, limity wywołań, wykrywanie anomalii i zdolność zatrzymania całego potoku, gdy coś idzie nie tak. Granice między etapami muszą wychwytywać błąd, zanim się rozprzestrzeni.

ASI09: Nadużycie zaufania człowiek–agent (Human-Agent Trust Exploitation)

Ludzie ufają płynnym, pewnym siebie odpowiedziom. Agent — przejęty lub błądzący — może użyć tej wiarygodności, by nakłonić człowieka do zatwierdzenia ryzykownego działania, ujawnienia danych albo zignorowania ostrzeżenia. To inżynieria społeczna, w której narzędziem jest sam asystent.

Główna ochrona: wymagaj od agenta czytelnego uzasadnienia i pokazania źródeł przy ważnych krokach, a decyzje o dużych skutkach trzymaj za jawnym punktem kontroli z udziałem człowieka, który widzi, na co się zgadza.

ASI10: Agenty wymknięte spod kontroli (Rogue Agents)

Najgroźniejsza pozycja na liście: agent skompromitowany, źle dostrojony albo dryfujący od celu, który mimo to działa dalej wewnątrz systemu. Nikt go nie zatrzymał, bo nadal „pracuje“.

OWASP przywołuje tu głośny przypadek Replit, gdzie agent doprowadził do skasowania danych podczas zadania — przykład tego, jak autonomiczny proces potrafi wyrządzić realną szkodę, zanim ktoś zareaguje.

Główna ochrona: ciągły nadzór nad zachowaniem agenta plus wyłącznik awaryjny. Musisz być w stanie wykryć dryf lub złośliwe działanie i natychmiast odciąć agentowi dostęp do narzędzi i danych.

Jak korzystać z tej listy w praktyce?

Lista ASI01–ASI10 nie jest po to, by zamknąć dziesięć osobnych dziur. Te ryzyka łączą się w łańcuchy: przejęcie celu (ASI01) prowadzi do nadużycia narzędzi (ASI02), które dzięki zbyt szerokim uprawnieniom (ASI03) kończy się wykonaniem kodu (ASI05). Dlatego warto patrzeć na cały przepływ od wejścia po działanie.

Praktyczny punkt startu, który nie wymaga przebudowy architektury, to trzy filary: najmniejsze uprawnienia (ASI02, ASI03), izolacja wykonania i pamięci (ASI05, ASI06) oraz nadzór z wyłącznikiem (ASI08, ASI10). Resztę dokłada się warstwami, w miarę jak agent dostaje więcej autonomii.

Pełną listę wraz z opisami ataków i wzorcami architektonicznymi publikuje projekt OWASP Gen AI Security — to dokument referencyjny, do którego warto wracać przy każdym audycie systemu agentowego.