OWASP Top 10 dla aplikacji agentowych: jak mitygować każde ryzyko na produkcji
Produkcyjny playbook do OWASP Top 10 dla aplikacji agentowych: jak spełnić i mitygować każde z dziesięciu ryzyk konkretnymi kontrolami, guardrailami i governance.
Definicja
OWASP Top 10 dla aplikacji agentowych to społecznościowy framework bezpieczeństwa opublikowany w grudniu 2025 r., który porządkuje najważniejsze ryzyka właściwe autonomicznym agentom AI — systemom, które planują, wywołują narzędzia i działają wielokrokowo. Rozszerza listę OWASP LLM Top 10 na warstwę agenta.
Autonomiczni agenci AI wyszli z dem do produkcji szybciej niż kontrole, które miały ich okiełznać. W grudniu 2025 r. OWASP odpowiedział osobną listą Top 10 dla aplikacji agentowych — uznając, że agent to nie powiększony chatbot, lecz nowa klasa systemu, który działa. Ten przewodnik omawia każdą kategorię i obronę, która rzeczywiście robi różnicę.
Dlaczego agenci potrzebują własnej Top 10?
Model językowy produkuje tekst. Agent zamienia ten tekst w skutki: czyta dokument, postanawia wywołać narzędzie, a narzędzie robi coś realnego — odpytuje bazę, wysyła e-mail, przelewa pieniądze. Ta jedna zmiana architektury przestawia model zagrożeń całkowicie. Zmanipulowane wyjście było kiedyś błędną odpowiedzią; u agenta staje się błędnym działaniem.
Dwa incydenty pokazały to dobitnie. W lipcu 2025 r. agent kodujący usunął produkcyjną bazę danych w trakcie pracy. W grudniu 2025 r. inny agent wyczyścił dysk programisty. Żaden nie był egzotycznym exploitem — oba były zwykłymi błędami zakresu i nadzoru.
- Nadmierne uprawnienia agenta34%
- Prompt injection (bezpośredni + pośredni)28%
- Zatruwanie narzędzi i wyników16%
- Brak nadzoru przy działaniach o dużym skutku14%
- Zatruwanie pamięci / retrievalu8%
Dziesięć kategorii w czterech grupach
Listę łatwiej przełożyć na działanie w czterech grupach.
1. Manipulowanie tym, co agent czyta
Prompt injection to ryzyko numer jeden. Wariant bezpośredni celuje w prompt użytkownika; wariant pośredni ukrywa instrukcje w dokumentach, stronach i wynikach narzędzi, które agent pobiera później. Ponieważ agenci przeglądają i pobierają treści autonomicznie, to właśnie pośredni injection jest głównym wektorem — atakujący nigdy nie rozmawia z agentem wprost.
Obrona: każdą treść z zewnątrz traktuj jako niezaufane wejście, nigdy jako instrukcje. Oddziel płaszczyznę danych od płaszczyzny sterowania i ogranicz to, co agent może zrobić po przeczytaniu wrogiego tekstu.
2. Nadużywanie narzędzi agenta
Tool poisoning to manipulowanie narzędziami albo ich wynikami. Nadmierne uprawnienia — stale najbardziej kosztowna kategoria — to po prostu agent dysponujący większą mocą, niż wymaga zadanie. Gdy coś pójdzie nie tak, szerokie uprawnienia zamieniają drobny błąd w poważny incydent.
Obrona: minimalne uprawnienia per narzędzie, zawężone poświadczenia i lista dozwolonych akcji. Jeśli agent ma tylko czytać, nie może mieć prawa zapisu.
3. Psucie pamięci agenta
Zatruwanie pamięci sadzi fałszywe lub złośliwe treści w pamięci długotrwałej, embeddingach lub bazie retrievalu, tak by zostały później przywołane jako zaufany kontekst. Ładunek przetrwa między sesjami i po cichu obciąża wiele przyszłych decyzji.
Obrona: waliduj to, co trafia do pamięci, segmentuj pamięć według poziomu zaufania oraz wygaszaj lub przeglądaj długo żyjące wpisy.
4. Utrata człowieka
Ostatnia grupa jest organizacyjna: brak nadzoru przy działaniach o dużym skutku oraz nadmierne zaufanie między agentami w systemach wieloagentowych, gdy jeden agent przyjmuje wynik drugiego jako automatycznie bezpieczny.
Obrona: punkt akceptacji przez człowieka przed działaniami nieodwracalnymi i jawne granice zaufania między agentami.
Ryzyka w skrócie
| Ryzyko | Na czym polega | Główna obrona |
|---|---|---|
| Prompt injection (pośredni) | Ukryte instrukcje w pobranej treści przejmują agenta | Treść z zewnątrz jako dane; rozdział płaszczyzny sterowania i danych |
| Nadmierne uprawnienia | Zbyt szerokie prawa wzmacniają każdy błąd | Minimalne uprawnienia per narzędzie; domyślnie tylko odczyt |
| Zatruwanie narzędzi | Podmienione narzędzia lub wyniki sterują agentem | Przypinanie i weryfikacja narzędzi; walidacja wyników; lista dozwolonych akcji |
| Zatruwanie pamięci | Fałszywy kontekst trwa między sesjami | Walidacja zapisów; segmentacja wg zaufania; wygaszanie wpisów |
| Brak nadzoru | Brak bramki człowieka przed działaniem nieodwracalnym | Człowiek w pętli przy działaniach o dużym skutku |
Postawa na start, która działa
Nie potrzebujesz wszystkich dziesięciu kontroli od pierwszego dnia. Najwięcej dają ruchy powtarzalne we wszystkich powyższych incydentach:
- Minimalne uprawnienia — zawęź każde narzędzie i poświadczenie.
- Człowiek w pętli przy działaniach destrukcyjnych lub kosztownych.
- Treść z zewnątrz jako niezaufana — dane, nigdy polecenia.
- Traceuj wszystko — nie obronisz tego, czego nie widzisz.
Te cztery odcinają utratę danych i nieautoryzowane wydatki — skutki, które naprawdę bolą — i dają przestrzeń, by dojrzeć z resztą. Słownictwo wyjaśniamy w słowniku AgentOps; zegar regulacyjny opisujemy w materiałach o ładzie.
Najczęstsze pytania
Czym bezpieczeństwo agenta różni się od bezpieczeństwa LLM?
LLM generuje wyłącznie tekst, a agent zamienia ten tekst w działanie — wywołuje narzędzia, zapisuje dane w systemach produkcyjnych i przenosi środki. Ten sam prompt injection, który kiedyś dawał najwyżej błędną odpowiedź, dziś potrafi usunąć bazę, wykonać przelew albo ujawnić listę klientów. Dlatego bezpieczeństwo agenta musi chronić całą pętlę decyzja–działanie, a nie samo wyjście modelu. Trzeba rozważyć, do jakich narzędzi agent ma dostęp, jakie uprawnienia niesie każde z nich i co stanie się po przeczytaniu wrogiej treści. W praktyce dochodzą trzy kwestie, których ochrona LLM nie znała: autoryzacja narzędzi, odwracalność działań i nadzór w czasie wykonania. Model traktuj jako jeden niezaufany element systemu, który działa, a kontrole projektuj wokół działań, nie wokół słów.
Czy prompt injection naprawdę jest nie do rozwiązania?
Nie istnieje pojedyncze rozwiązanie, które sprawi, że prompt injection zniknie, a kto je sprzedaje, mija się z prawdą. Skoro agent czyta niezaufany tekst, a potem na jego podstawie działa, realnym celem jest zmniejszenie zasięgu szkody, nie zagwarantowanie czystego wejścia. Większość pracy wykonują cztery kontrole. Każdą treść z zewnątrz traktuj jako dane, nigdy jako instrukcje. Każde narzędzie ogranicz do minimalnych uprawnień. Przy działaniach o dużym skutku wymagaj akceptacji człowieka, a ślady wykonania monitoruj pod kątem anomalii. Po ich nałożeniu udany injection wciąż nie sięgnie niczego istotnego. Zespoły błądzą, szukając idealnego filtra wejścia — filtry pomagają na marginesie, ale trwałą obroną jest ograniczenie tego, co agentowi wolno zrobić, gdy wroga treść jest już w kontekście.
Od czego zacząć w małym zespole?
Zacznij od dwóch kontroli, które najtaniej blokują najgorsze skutki: minimalnych uprawnień dla każdego narzędzia i poświadczenia oraz punktu akceptacji przez człowieka przy działaniach destrukcyjnych lub kosztownych. Razem odcinają dwa scenariusze, które naprawdę bolą — nieodwracalną utratę danych i nieautoryzowane wydatki — a ich wdrożenie zajmuje dni, nie kwartały. Agent kodujący z prawem tylko do odczytu repozytorium nie skasuje go; agent, który musi czekać na zgodę przed płatnością, nie wyczyści konta. Gdy te zabezpieczenia trzymają, dodaj tracing wykonania, by widzieć, co agent zrobił i dlaczego. Potem dołóż obsługę wejścia i higienę pamięci w miarę rozrostu systemu. Kolejność ma znaczenie: najpierw ogranicz szkodę, potem obserwuj, na końcu dopracowuj.
Które ryzyko agentowe jest najbardziej kosztowne?
Nadmierne uprawnienia — agent dysponujący większą mocą, niż wymaga zadanie — to konsekwentnie najbardziej kosztowna kategoria i stoi za dużą częścią udokumentowanych incydentów. Powód to dźwignia: gdy nadmiernie uprzywilejowany agent popełni zwykły błąd albo wykona wstrzykniętą instrukcję, szeroki dostęp zamienia drobną pomyłkę w wielką. Manipulacja na agencie, który tylko streszcza i ma prawo odczytu, daje błędne zdanie; ta sama manipulacja na agencie z prawem usuwania i płatności daje skasowaną bazę lub fałszywy przelew. Dlatego minimalne uprawnienia wyprzedzają niemal każdą inną kontrolę — ograniczają najgorszy możliwy skutek niezależnie od tego, jak agent został oszukany. Zawężaj poświadczenia per narzędzie, domyślnie preferuj odczyt, a zapis i wydatki ukryj za jawną zgodą. Ograniczanie mocy jest tańsze i pewniejsze niż próba zapobieżenia każdej pomyłce.