3 czerwca OWASP wydał drugą edycję raportu „State of Agentic AI Security and Governance" — wersję 2.01. Jej centralne przesłanie streszcza się w jednym zdaniu: agentowe AI nie jest już eksperymentalnym przypadkiem brzegowym. Dla niemal każdej klasy ryzyka agentowego, którą OWASP śledzi, istnieją dziś incydenty produkcyjne, komunikaty producentów i numery CVE.
Dla nas to jest moment szczególny. Przez ostatnie tygodnie cyberflux opisywał te incydenty pojedynczo, jeden po drugim. Raport OWASP jest ramą, która spina je w taksonomię — i potwierdza, że to, co wyglądało na osobne przypadki, jest jedną, spójną klasą zagrożeń.
Od „emerging" do „field evidence"
Różnica między wersją 1.0 a 2.01 jest sama w sobie tezą. Wersja 1.0, opublikowana w lipcu 2025, traktowała autonomiczne agenty jako pojawiające się ryzyko — zagrożenie teoretyczne, modelowane z wyprzedzeniem. Wersja 2.01, wydana w czerwcu 2026, czyta rok dowodów z terenu i wiąże je bezpośrednio z architekturami wdrożeń, pokazując, gdzie zabezpieczenia zawiodły w praktyce.
To jest przejście od „co może się stać" do „co się stało, i oto CVE". Raport opiera się na żywych danych incydentowych, taksonomii dziesięciu największych ryzyk dla aplikacji agentowych i rosnącym katalogu narzędzi obronnych. Innymi słowy: branża przeszła w ciągu roku tę samą drogę, którą cyberflux przeszedł, opisując kolejne incydenty od Comment and Control po Claude Code GitHub Action.
Sednem raportu: „safety" i „security" to już jedno
Najważniejsza teza OWASP jest jednocześnie najbardziej elegancka — i warto ją wyłożyć dokładnie, bo zmienia sposób myślenia o całej kategorii.
W tradycyjnych środowiskach awarie bezpieczeństwa dzielą się na dwa rodzaje, którymi zajmują się różne zespoły. „Safety" to sytuacja, gdy system sam z siebie zachowuje się szkodliwie — błąd, awaria, niezamierzone działanie. „Security" to sytuacja, gdy ktoś z zewnątrz celowo wykorzystuje system — atak adwersarialny. Dwa różne zespoły, dwa różne procesy eskalacji, dwie różne taksonomie ryzyka.
OWASP twierdzi, że agentowe AI likwiduje tę granicę na poziomie wdrożenia. Gdy agent może autonomicznie wywoływać API, modyfikować kod i dotykać danych produkcyjnych, ta sama nadmiernie permisywna decyzja projektowa staje się jednocześnie luką „safety" i luką „security". To nie są dwa osobne problemy — to jeden problem, który można wyzwolić albo przez przypadek (agent robi coś szkodliwego sam), albo przez atak (ktoś go do tego nakłania).
Widzieliśmy to wprost przy Claude Code GitHub Action: nadmierne uprawnienia agenta czytającego niezaufane zgłoszenia były luką bezpieczeństwa (atakujący wstrzykuje prompt), ale ta sama konfiguracja byłaby luką „safety", gdyby agent po prostu źle zinterpretował zgłoszenie i sam wykonał destrukcyjną akcję. Jedna decyzja projektowa, dwa sposoby, by zawiodła. OWASP nazywa to, co my pokazywaliśmy na przykładzie.
Taksonomia, która mapuje nasze incydenty
Raport klasyfikuje systemy agentowe według roli operacyjnej — i ta klasyfikacja czyta się jak spis treści tego, co opisywaliśmy.
OWASP wyróżnia agenty korporacyjne, kodujące, skierowane do klienta, osobiste oraz infrastrukturalno-operacyjne. Każdy typ dostaje osobne traktowanie pod kątem granic zaufania i wyzwań governance, odzwierciedlając, jak ich blast radius rośnie wraz z autonomią i dostępem do narzędzi. To jest dokładnie wzorzec, który zapisaliśmy w Radarze: im więcej narzędzi i im większa autonomia, tym większy zasięg szkody z jednej kompromitacji.
Mapowanie naszych incydentów na tę taksonomię jest niemal bezpośrednie. Agent kodujący — Claude Code GitHub Action. Agent osobisty — Gemini przejmowany przez powiadomienie. Asystent skierowany do klienta — ChatGPT renderujący phishing w ChatGPhish. Każdy z tych przypadków to inny wiersz w taksonomii OWASP, ta sama klasa problemu w różnych rolach.
Jest też warstwa, którą OWASP wyróżnia jako szczególnie ryzykowną — i którą również opisywaliśmy. Na poziomie implementacji raport rozróżnia pełne frameworki orkiestracji, lekkie kompozycje bibliotek i natywne platformy low-code. Ostrzega, że „shadow AI" i przepływy budowane przez „obywateli-deweloperów" w środowiskach low-code to dziś jedne z najmniej widocznych i najwyższego ryzyka wdrożeń. To jest dokładnie wątek Langflow jako skarbca kluczy — platformy low-code, które spinają wiele usług i przez to skupiają ryzyko w jednym, słabo nadzorowanym miejscu.
Zatrute dane między najemcami — i pamięć jako cel
Raport opisuje też mechanizm, który widzieliśmy przy Miasmie i zatruciu pamięci Gemini: zatrute dane od dostawcy mogą rozprzestrzeniać się przez współdzielone konteksty agentów AI, tworząc międzynajemcze ryzyko łańcucha dostaw.
To jest nowa klasa, której nie było w tradycyjnym modelu zagrożeń. W klasycznym oprogramowaniu kontekst jednego klienta nie wycieka do drugiego. W systemach agentowych z współdzieloną pamięcią i kontekstem — zatrucie u jednego może propagować się do innych. Jeden z współliderów raportu prowadzi osobną pozycję taksonomii poświęconą właśnie zatruwaniu pamięci i kontekstu. Pisaliśmy przy Gemini, że zatruty fakt zapisany w pamięci na poziomie konta podąża za użytkownikiem wszędzie — OWASP klasyfikuje to jako osobną, nazwaną kategorię ryzyka.
Od taksonomii do audytu: crosswalk AIUC-1
Razem z raportem OWASP opublikował drugi dokument, który jest praktycznym dopełnieniem — i to on jest najciekawszy dla każdego, kto musi nie tylko zrozumieć ryzyko, ale wykazać, że je kontroluje.
AIUC-1 Crosswalk to dwukierunkowe mapowanie między wymaganiami standardu AIUC-1 a dziesięcioma największymi ryzykami z OWASP Agentic Security Initiative. Pomaga organizacjom przełożyć taksonomię ryzyka na konkretne wymagania audytowe — i odwrotnie. To jest most między „rozumiem zagrożenie" a „mogę udowodnić, że mam kontrolę", którego dotąd brakowało.
Znaczenie tego kroku jest praktyczne. Taksonomia mówi, czego się bać. Crosswalk mówi, co konkretnie wdrożyć i jak to zweryfikować wobec uznanego standardu. Dla organizacji pod presją regulacyjną — a tych przybywa — to jest różnica między „wiemy, że agenty są ryzykowne" a „mamy udokumentowany, audytowalny program kontroli". To jest ta sama logika, którą budujesz we własnej bazie wzorców — od opisu zagrożenia do konkretnej, sprawdzalnej reguły.
Co z tego wynika dla obrońcy
Raport nie jest lekturą tylko dla zespołów AI. Jego praktyczne zalecenia są konkretne i mapują się na wszystko, co opisywaliśmy.
Zasada najmniejszych uprawnień jako fundament. OWASP instruuje, by agenty działały ściśle według least privilege, z dostępem ograniczonym wyłącznie do zasobów niezbędnych do zadania. To jest dokładnie wniosek z Claude Code i prompt leaking: jedyną twardą granicą jest to, czego agent nie może zrobić, bo nie ma uprawnień — nie to, co napisano mu w instrukcji.
Walidacja wejścia i wyjścia, ciągłe monitorowanie, granularna kontrola dostępu. I — co istotne — wbudowanie tych modeli governance bezpośrednio w cykl wytwarzania oprogramowania i potoki CI/CD. Bezpieczeństwo agentów nie jest warstwą doklejaną po wdrożeniu; jest decyzją architektoniczną podejmowaną, zanim agent dostanie pierwszy token.
Ariel Fogel, jeden ze współliderów raportu, ujął problem zdaniem, które jest najlepszym podsumowaniem całej sytuacji: większość organizacji wdraża agenty szybciej, niż jest w stanie nimi zarządzać. To jest luka, którą raport próbuje zamknąć — i to jest dokładnie ta sama luka, którą cyberflux opisywał incydent po incydencie. Różnica jest taka, że teraz istnieje rama, by te incydenty nazwać, sklasyfikować i odnieść do audytowalnego standardu.
Co zrobić
Jeśli wdrażasz agenty AI w produkcji: przeczytaj taksonomię dziesięciu ryzyk i zmapuj na nią własne wdrożenia. Raport jest darmowy w ramach OWASP GenAI Security Project.
Zacznij od inwentaryzacji „shadow AI" — przepływów low-code i agentów budowanych poza nadzorem zespołu bezpieczeństwa. OWASP wskazuje je jako najwyższe ryzyko właśnie dlatego, że są najmniej widoczne.
Traktuj „safety" i „security" agentów jako jeden program, nie dwa. Jeśli masz osobne zespoły i osobne ścieżki eskalacji dla „agent zachował się źle" i „agent został zaatakowany" — przy systemach agentowych to jest sztuczny podział, który zostawia lukę na styku.
Jeśli jesteś pod presją regulacyjną lub audytową: AIUC-1 Crosswalk jest narzędziem, które przekłada taksonomię ryzyka na wymagania, które można wykazać. To jest most od zrozumienia do dowodu.
Źródła
OWASP GenAI Security Project — raport „State of Agentic AI Security and Governance" oraz AIUC-1 Crosswalk: https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/
CyberSecurityNews — analiza tezy o zlaniu „safety" i „security" oraz taksonomii ról: https://cybersecuritynews.com/owasp-ai-security-report-with-new-tools/
GBHackers — omówienie przejścia od v1.0 do v2.01 i kontekst danych incydentowych: https://gbhackers.com/owasp-unveils-ai-security-report/
Infosecurity Magazine — Enterprise Adoption Maturity Model i cytat Ariela Fogela: https://www.infosecurity-magazine.com/news/owasp-agentic-ai-security-maturity/
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł