Bezpieczeństwo agentów AI & OWASP

Czym jest bezpieczeństwo agentów AI według OWASP

Bezpieczeństwo agentów AI według OWASP to systematyczne zabezpieczanie autonomicznych agentów AI przed zagrożeniami, które wynikają z ich zdolności do samodzielnego planowania, wywoływania narzędzi, zapisywania danych w pamięci trwałej i działania przy minimalnym zatwierdzaniu kolejnych kroków przez człowieka. Podczas gdy klasyczny chatbot przede wszystkim odpowiada (prompt na wejściu, odpowiedź modelu na wyjściu, ewentualnie ugruntowana przez RAG), agenci planują, wnioskują, wybierają narzędzia, zapisują pamięć i działają. To przesunięcie poziomu abstrakcji poszerza powierzchnię ataku w trzech wymiarach: autonomii (wieloetapowe plany, samodzielna modyfikacja kontekstu i pamięci), korzystania z narzędzi (system plików, API, konektory baz danych, sandboxy do wykonywania kodu, serwery MCP, węzły protokołu A2A) oraz trwałości (długotrwałe magazyny pamięci, wektorowe bazy danych, łańcuchy zaufania między agentami).

OWASP ujmuje to we własnym sformułowaniu GenAI Security Project (Sotiropoulos et al., 9 grudnia 2025 r.) tak: systemy agentowe dziedziczą wszystkie ryzyka LLM i wprowadzają zupełnie nowe klasy podatności, wynikające z autonomii, integracji narzędzi, koordynacji wielu agentów i trwałego stanu. Dla decydentów w Europie kluczowy wniosek brzmi: kto czyta wyłącznie LLM Top 10, systematycznie nie docenia ryzyka agentowego.

Dwie kluczowe listy OWASP

OWASP GenAI Security Project (genai.owasp.org) publikuje rodzinę nakładających się na siebie dokumentów dotyczących bezpieczeństwa AI. Dwa z nich mają kluczowe znaczenie dla agentów:

• OWASP Top 10 dla aplikacji LLM 2025 (LLM01:2025 do LLM10:2025). Obejmuje ryzyka modelu i aplikacji w każdej aplikacji GenAI/LLM: konwersacyjnej, opartej na RAG, typu copilot lub agentowej. To punkt odniesienia, który większość zespołów bezpieczeństwa już zna. Od 3 sierpnia 2026 r. dostępne jest wydanie 2026. Excessive Agency zajmuje w nim 3. miejsce (LLM03:2026). Przyporządkowania na tej stronie są zgodne z numeracją z 2025 r.
• OWASP Top 10 for Agentic Applications 2026 (ASI01 do ASI10). Lista opublikowana 9 grudnia 2025 r. przez tę samą inicjatywę (Agentic Security Initiative) przy udziale ponad 100 współtwórców i Expert Review Board (m.in. NIST, Alan Turing Institute, Microsoft AI Red Team, AWS/CoSAI, Zenity). To fundament modelowania zagrożeń specyficznych dla agentów.

Ważna uwaga dotycząca taksonomii: kanoniczna lista z grudnia 2025 r. różni się od wcześniejszej wersji roboczej OWASP („Agentic AI Threats and Mitigations v1.0”, luty 2025 r., często cytowanej jako „15 agentic threats”). Wiele artykułów praktyków z początku i połowy 2025 r. nadal stosuje tę roboczą numerację (np. „Memory Poisoning jako ASI01”). Należy ona do historycznych wersji roboczych, a nie do ostatecznej listy Top 10. Dawne kategorie są dziś włączone do skonsolidowanej listy. Memory Poisoning mieści się w ASI06, obejście HITL w ASI09.

ASI01–ASI10 w skrócie

Dziesięć kanonicznych zagrożeń agentowych i ich główne kategorie kontroli:

Kluczowa jest logika wzmocnienia: według mapowania DeepTeam ASI01 = LLM01 (Prompt Injection) × LLM06 (Excessive Agency), tyle że z wieloetapowym wykonaniem, które zwielokrotnia szkody ponad skutki pojedynczej odpowiedzi. ASI03, ASI07 i ASI08 nie mają bezpośredniego odpowiednika w LLM Top 10, a ASI10 jest tylko częściowo powiązane z LLM06:2025.

Prompt injection i Agent Goal Hijack (ASI01)

W przypadku ASI01 atakujący manipuluje celami, wyborem zadań lub ścieżkami decyzyjnymi agenta, bezpośrednio przez prompt injection albo pośrednio przez ukryte instrukcje w dokumentach, korpusie RAG, e-mailach, zaproszeniach z kalendarza, opisach PR lub wynikach narzędzi. Sedno problemu: agenci i model, na którym działają, nie potrafią niezawodnie odróżnić instrukcji od danych, więc każdy tekst, który agent czyta, staje się częścią powierzchni ataku.

Udokumentowanym punktem zwrotnym jest EchoLeak (CVE-2025-32711, CVSS 9.3), ujawniony przez Aim Labs w czerwcu 2025 r. w Microsoft 365 Copilot: pierwszy realnie udokumentowany przypadek zero-click prompt injection w systemie produkcyjnym. Jeden spreparowany e-mail ominął klasyfikator XPIA firmy Microsoft i przez dozwolone proxy Teams wyprowadził najbardziej wrażliwe treści z kontekstu Copilota, bez ani jednego kliknięcia użytkownika (Aim Labs ukuło termin „LLM Scope Violation”; szczegóły techniczne: arXiv 2509.10540, Reddy et al., wrzesień 2025 r.). Microsoft załatał lukę po stronie serwera. Inne przypadki: GitHub Copilot YOLO Mode (CVE-2025-53773) oraz CamoLeak w GitHub Copilot Chat (CVSS 9.6), który dzięki obejściu CSP przez własne proxy obrazów Camo firmy GitHub wykradał znak po znaku sekrety z prywatnych repozytoriów. Akademickim źródłem tej dyscypliny jest praca Greshake et al. (arXiv 2302.12173, 2023) o pośrednim prompt injection.

Przykład z regionu DACH (Niemcy, Austria, Szwajcaria): agent obsługi klienta w banku, który czyta współdzieloną skrzynkę pocztową, może przez e-mail z „podziękowaniem” zawierający ukryte instrukcje zostać nakłoniony do ujawnienia w następnej odpowiedzi fragmentów transakcji innych klientów.

Nadużycie narzędzi (ASI02) i Excessive Agency

ASI02 subtelnie różni się od nadużycia uprawnień: dostęp jest zgodny z uprawnieniami, ale użycie już nie. Agent działa w ramach przyznanych mu praw, lecz stosuje dozwolone narzędzie w niebezpieczny sposób: usuwa dane, zbyt często wywołuje kosztowne API, wykonuje destrukcyjne operacje. Excessive Agency (LLM06:2025), czyli przyznanie niekontrolowanej swobody działania bez wystarczającego ograniczenia zakresu i nadzoru człowieka, stanowi koncepcyjny pomost do ASI02 i częściowo do ASI10.

Udokumentowany przypadek: w Amazon Q Code Assistant (CVE-2025-8217, lipiec 2025 r.) atakujący przejęli token GitHub i przemycili destrukcyjne prompty do rozszerzenia VS Code v1.84.0, które z flagami --trust-all-tools --no-interactive mogły bez potwierdzenia usunąć systemy plików i zasoby chmurowe; rozszerzenie zainstalowało około 1 miliona programistów. Środki zaradcze: zasada najmniejszych uprawnień dla każdego narzędzia, walidacja schematu każdego argumentu narzędzia, listy dozwolonych i zabronionych działań dla każdej roli agenta, wyłączenie automatycznego zatwierdzania (trybów „YOLO”) dla wszystkiego, co dotyka baz danych, płatności, komunikacji lub wdrożeń, a także limity kosztów z circuit breakerami.

Memory & Context Poisoning (ASI06)

W przeciwieństwie do chatbotów, które między sesjami zapominają, agenci utrzymują pamięć trwałą: historię rozmów, preferencje, wyuczony kontekst, magazyny RAG. To tworzy trwałe powierzchnie ataku: jedna udana iniekcja trwale zatruwa pamięć, payload działa bez końca, a każda kolejna sesja dziedziczy kompromitację.

Udokumentowane przykłady: atak na pamięć Google Gemini (luty 2025 r., Johann Rehberger) zademonstrował „delayed tool invocation”: przesłany dokument polecał Gemini zapisywać fałszywe informacje, gdy w przyszłości pojawią się określone słowa wyzwalające. Badanie „Invitation Is All You Need!” (Nassi, Cohen, Yair, sierpień 2025 r.) przedstawiło 14 scenariuszy ataku na asystentów opartych na Gemini, uruchamianych przez e-maile, zaproszenia z kalendarza i udostępnione dokumenty. Według analizy ryzyka przeprowadzonej przez autorów 73% przeanalizowanych zagrożeń stanowi wysokie lub krytyczne ryzyko dla użytkowników. Blogi poświęcone bezpieczeństwu, powołując się na Lakerę, opisują zachowanie typu „uśpiony agent”: skompromitowani agenci mają rozwijać trwałe fałszywe przekonania na temat zasad bezpieczeństwa i bronić ich przed ludźmi. Środki zaradcze: traktowanie zapisów w pamięci jako operacji wrażliwych z punktu widzenia bezpieczeństwa, metadane pochodzenia (źródło, znacznik czasu, ścieżka pozyskania, poziom pewności) dla każdego wpisu, izolacja per tenant, regularne audyty pamięci oraz procedury usuwania zgodne z art. 17 RODO (prawo do usunięcia danych).

Środki zaradcze i human-in-the-loop (ASI09)

Agenci generują dopracowane wyniki, które brzmią autorytatywnie. Ludzie mają skłonność im ufać. ASI09 (Human-Agent Trust Exploitation) czyni właśnie tę warstwę zaufania celem ataku: błąd automatyzacji, uleganie autorytetom i „polished hallucination” sprawiają, że osoby zatwierdzające bez namysłu przepuszczają rekomendacje. Warstwa nadzoru, pomyślana jako zabezpieczenie, staje się słabym punktem. Dostawcy rozwiązań bezpieczeństwa opisują niepotwierdzony niezależnie przypadek, w którym agenta zakupowego miano przez trzy tygodnie przekonywać, że jego limit autoryzacji wynosi 500 000 USD; następnie atakujący miał złożyć fałszywe zamówienia na 5 mln USD.

Skuteczne bramki HITL wymagają niezależnej weryfikacji dowodów, a nie tylko rekomendacji agenta: stopniowanych zatwierdzeń (większy wpływ → więcej zatwierdzających lub mocniejsze dowody), wzorców UI, które aktywnie pokazują rozumowanie, pochodzenie źródeł i poziom pewności (a nie samego przycisku „Zatwierdź”), oraz okresowych „test injections”, które sprawdzają, czy HITL naprawdę działa (jak ćwiczenia przeciwpożarowe). Jest to bezpośrednio zbieżne z art. 14 unijnego AI Act (nadzór ze strony człowieka).

Ogólna zasada to obrona w głąb: żaden pojedynczy guardrail nie jest uniwersalnym rozwiązaniem. EchoLeak ominął klasyfikator XPIA firmy Microsoft; kompetentni badacze w ciągu kilku miesięcy obeszli każdy opublikowany guardrail (Bedrock Guardrails, Google Model Armor, Gemini Safety). Potrzebnych jest kilka uzupełniających się warstw: filtry wejściowe (np. Llama Guard 4, NVIDIA NeMo Guardrails, Microsoft Prompt Shield, Lakera Guard) + egzekwowanie zakresu i pochodzenia + filtry wyjściowe + monitorowanie zachowań. Guardraile zwykle dodają 100–500 ms opóźnienia na każdą warstwę i w wielojęzycznych kontekstach DACH (przełączanie kodów DE/FR/IT/EN) dają więcej fałszywych alarmów. Deklaracje dostawców w rodzaju „blokuje 99,x% ataków prompt injection” należy traktować jako marketing, dopóki nie zweryfikuje ich niezależny red team.

Zgodność z regulacjami w regionie DACH (informacyjnie, nie stanowi porady prawnej)

Listy OWASP nie są certyfikacją, a „OWASP-compliant” nie jest wiarygodną deklaracją dostawcy: dostawcy mogą wdrażać zalecenia OWASP, ale nie mogą być „compliant”. Listy te dobrze jednak przekładają się na ramy zgodności w regionie DACH:

• Art. 15 unijnego AI Act (dokładność, solidność i cyberbezpieczeństwo) szeroko obejmuje systemy wysokiego ryzyka, ale jest neutralny technologicznie; pośrednie wstrzykiwanie promptów, specyfika NHI i kaskady wieloagentowe nie zostały jeszcze skodyfikowane w normie i pozostają odpowiedzialnością podmiotu stosującego.
• Art. 32 RODO (środki techniczne i organizacyjne): większość zagrożeń ASI dotyczy poufności, integralności, dostępności i odporności. ASI06 dotyczy na przykład art. 5 ust. 1 lit. d (prawidłowość) i art. 17 (usunięcie danych).
• ISO/IEC 42001:2023 (załącznik A, 38 zabezpieczeń w ramach 9 celów) dostarcza zabezpieczeń referencyjnych, m.in. A.6.2.4 (V&V), A.6.2.6 (eksploatacja/monitorowanie) i A.6.2.8 (logowanie).
• NIS2 / DORA: w przypadku podmiotów kluczowych i ważnych NIS2 w art. 21 ust. 2 wymaga m.in. bezpieczeństwa łańcucha dostaw (→ ASI04) i kontroli dostępu (→ ASI03); DORA w art. 28–30 reguluje ryzyko związane z zewnętrznymi dostawcami usług ICT, co ma bezpośrednie znaczenie dla łańcuchów dostaw MCP i agentów w sektorze finansowym.

Nadzór w regionie DACH: wytyczne BaFin (18 grudnia 2025 r.) i komunikat nadzorczy FINMA 08/2024 nie są wiążące, ale wyraźnie przesuwają ciężar dowodu podczas audytów; oba dokumenty zalecają m.in. adwersarialne testy penetracyjne lub oparte na scenariuszach ćwiczenia z cyberbezpieczeństwa. W Austrii FMA poszła w ich ślady, publikując dokument informacyjny „Nutzung von KI im Finanzsektor” (wersja 1.0, stan na 11 września 2026 r.). Również ten dokument nie jest wiążący. Stwierdza, że aplikacje AI już dziś muszą spełniać neutralne technologicznie wymogi prawa rynku finansowego, w tym DORA, oraz że organ zarządzający ponosi ostateczną odpowiedzialność także za ryzyka ICT związane z AI. BSI w raporcie o stanie bezpieczeństwa 2025 wskazuje pośredni prompt injection jako obecnie najistotniejszy wektor ataku na systemy LLM i stwierdza, że nie istnieje jeden wysoce skuteczny środek, który by go powstrzymał.

Perspektywy i wskazówki praktyczne

OWASP Agentic Top 10 ma obecnie wersję 1.0 (9 grudnia 2025 r.) i prawdopodobnie będzie aktualizowana co najmniej raz w roku. Warto dodać genai.owasp.org do zakładek, zamiast traktować listę jako statyczną. Trzy trzeźwe uwagi praktyczne. Po pierwsze, MITRE ATLAS jako katalog taktyk przeciwników pozostaje 6–12 miesięcy w tyle za agentowym frontem, zwłaszcza w przypadku ASI07, ASI08 i ASI10. Po drugie, wykrywanie w produkcyjnych wdrożeniach agentów jest wciąż słabe: większość stosów observability zbudowano dla klasycznych aplikacji i nie wychwytują one anomalii w śladach rozumowania, naruszeń pochodzenia przy zapisach do pamięci ani sygnałów dryfu zachowań; wniosek „nie widzimy tego w SIEM, więc to się nie dzieje” jest niebezpiecznie błędny. Po trzecie, „AI red teaming” to nie to samo co klasyczny pentest (inne umiejętności, inne narzędzia, takie jak Garak/PyRIT/DeepTeam, wyniki probabilistyczne zamiast binarnych).

Dla podmiotów wdrażających agentów pragmatyczny punkt wyjścia wygląda tak: założyć rejestr ryzyk na podstawie OWASP Agentic Top 10, zmapować go na ISO 42001 i art. 15 unijnego AI Act, traktować każdego agenta jako odrębną Non-Human Identity z krótkotrwałymi poświadczeniami, wdrożyć guardraile w modelu obrony w głąb, zabezpieczyć destrukcyjne operacje prawdziwym HITL i mieć w gotowości kill switch do izolowania zbuntowanych agentów. Więcej o prompt injection, red teamingu, monitorowaniu i ścieżkach audytu znajdziesz w artykułach poniżej.