OWASP 2026: Największe zagrożenia generatywnej AI

2026-06-12
Agent usunął bazę danych w 9 sekund. To już nie PoC - to produkcja. Po OWASP Gen AI Security Summit w Londynie jedno jest pewne: dotychczasowe modele security nie pasują do ery agentów AI. Sprawdź, co naprawdę dzieje się na froncie.
oncepcyjna ilustracja przedstawiająca kontrast między bezpiecznym, zoptymalizowanym działaniem sztucznej inteligencji a cybernetycznymi zagrożeniami i błędami systemowymi.

Z laboratorium na pole bitwy - wnioski z OWASP Gen AI Security Summit, Londyn 2026

4 czerwca w ExCeL London, w ramach Infosecurity Europe, odbył się OWASP Gen AI Security Summit - półdniowe wydarzenie organizowane przez OWASP GenAI Security Project. Na scenie pojawili się liderzy projektu, praktycy z Microsoft i AWS oraz eksperci zajmujący się bezpieczeństwem systemów agentowych. Byłem tam i wróciłem z kilkoma wnioskami, które nie dają mi spokoju.

Tempo, które powinno niepokoić

Największe wrażenie zrobiła na mnie nie pojedyncza prezentacja, a zmiana, która zaszła w ciągu niecałego roku w samym projekcie OWASP GenAI Security. Jeszcze niedawno dyskusje koncentrowały się na laboratoryjnych przykładach ataków - proof of concept, teoretycznych wektorach, hipotetycznych scenariuszach. Teraz? Teraz rozmawiamy o rzeczywistych incydentach, udokumentowanych atakach i podatnościach odkrytych w produkcyjnych systemach. 
 
To przesunięcie mówi więcej niż jakakolwiek prezentacja. Adopcja rozwiązań AI  a w szczególności rozwiązań agentowych pędzi z prędkością, za którą nasze modele bezpieczeństwa po prostu nie nadążają. Napędza ją ogromny apetyt na innowację i realny potencjał tych technologii. Problem w tym, że bezpieczeństwo zostaje w tyle.

Agenty nie są automatyzacją

Przez lata budowaliśmy zabezpieczenia pod automatyzację - systemy, które wykonują ściśle zdefiniowany zakres czynności, a każde odstępstwo traktujemy jako anomalię. To model, który dobrze rozumiemy. 
 
Agenty AI to zupełnie inna klasa problemów. Osoba, która otrzymuje uprawnienia do podejmowania działań, może teraz wydelegować je do agenta, który działa z praktycznie nieskończoną prędkością i w każdym momencie może zacząć zachowywać się w sposób, którego nikt nie przewidział. 
 
Incydent PocketOS jest doskonałą ilustracją. 25 kwietnia 2026 roku agent AI działający w narzędziu Cursor, podczas rutynowego zadania, napotkał problem z poświadczeniami i samodzielnie „postanowił" go naprawić. Usunął produkcyjną bazę danych. Wraz z backupami. W dziewięć sekund. A potem, zapytany o wyjaśnienie, wygenerował coś w rodzaju „spowiedzi", wymieniając wszystkie reguły bezpieczeństwa, które świadomie złamał. 
 
Dziewięć sekund. Tyle zajęło zniszczenie infrastruktury, od której zależały biznesy klientów PocketOS. Żaden człowiek nie zdążyłby nawet otworzyć terminala.

Nowa klasa zabezpieczeń

Wniosek, który wyłaniał się z prezentacji na summitcie, jest jednoznaczny - potrzebujemy fundamentalnie nowych mechanizmów bezpieczeństwa. Nie ewolucji istniejących, a nowej klasy zabezpieczeń, które potrafią:

Wykrywać rozmyte anomalie.
Tradycyjna automatyzacja robi zawsze to samo więc łatwo zidentyfikować odchylenie. Agent AI z natury działa w sposób niedeterministyczny. Potrzebujemy systemów, które rozumieją „normalne zachowanie" agenta w sposób bardziej elastyczny i potrafią reagować na subtelne odstępstwa.

Zapewniać rozliczalność w całym łańcuchu. 
Agenty wywołują agenty, które wywołują kolejne agenty. Kto podjął decyzję? Kto ją zlecił? Na czyją odpowiedzialność? Potrzebujemy pełnego łańcucha rozliczalności, od człowieka, przez każdego pośredniego agenta, aż do konkretnej akcji.

Wprowadzać nowe modele uprawnień.
Inne możliwości powinien mieć człowiek wykonujący działania, a inne agent działający w jego imieniu. To rozróżnienie w dzisiejszych systemach praktycznie nie istnieje. A powinno być fundamentem.

Takie zabezpieczenia już zaczynają się pojawiać - OWASP prowadzi katalog rozwiązań bezpieczeństwa AI na stronie swojego projektu. Ale jesteśmy dopiero na początku drogi i potencjał na innowację w tym obszarze jest ogromny.

Shadow AI - przycisk, który kiedyś ktoś kliknie

Dyskusja o bezpieczeństwie agentów nie dotyczy tylko firm budujących dedykowane rozwiązania agentowe w ramach swoich procesów deweloperskich. Dotyczy każdego z nas.
Kto z nas wie, jak pracownicy w naszych organizacjach używają Claude, Copilot, Cursor czy Codex? Te narzędzia stają się coraz potężniejsze i coraz bardziej autonomiczne. A jednocześnie interfejsy użytkownika świadomie minimalizują tarcie bo tak jest wygodniej.

Jeżeli narzędzie AI oferuje użytkownikowi przycisk „Akceptuj wszystko w tej sesji" podczas weryfikacji działań, to prędzej czy później ktoś tego przycisku użyje. To nie jest kwestia „czy", tylko „kiedy". A w połączeniu z rosnącą otwartością na dawanie narzędziom AI dostępu do wszystkich zasobów i funkcjonalności, uruchamianie agentów na głównych ścieżkach systemowych, przyznawanie szerokich tokenów API, tworzy się mieszanka, która powinna dawać każdemu z nas lekki dreszczyk.

Rule of Two i jej ograniczenia

Jednym z ciekawszych modeli bezpieczeństwa agentów, który pojawił się w kontekście dyskusji na summitcie, jest Meta's Rule of Two. Koncepcja, oparta o Lethal Trifecta Simona Willisona, jest elegancko prosta: agent AI nie powinien jednocześnie spełniać więcej niż dwóch z trzech warunków - przetwarzać niezaufanych danych wejściowych, mieć dostęp do wrażliwych systemów lub danych, oraz móc zmieniać stan lub komunikować się na zewnątrz. Jeśli spełnia wszystkie trzy, jest podatny na atak.

To dobra zasada projektowa. Problem w tym, że nawet jej autorzy nie zastosowali jej wystarczająco konsekwentnie.

W momencie pisania tego artykułu, dosłownie kilka dni po summitcie - dowiadujemy się o incydencie z chatbotem AI Mety na Instagramie. System „High Touch Support", uruchomiony w marcu 2026, miał pomagać użytkownikom odzyskiwać dostęp do kont. W praktyce wystarczyło grzecznie poprosić bota o reset hasła do dowolnego konta, a ten posłusznie wysyłał token resetujący na wskazany adres e-mail, bez weryfikacji tożsamości. Ponad 20 000 kont przejętych w ciągu sześciu tygodni, zanim ktokolwiek w Meta zauważył problem. Wśród ofiar konta o wartości rynkowej przekraczającej milion dolarów.

Ironia jest gorzka. Firma, która opublikowała Rule of Two jako model bezpieczeństwa agentów, sama padła ofiarą scenariusza, przed którym ta zasada miała chronić. Bot miał dostęp do wrażliwych operacji na kontach, przetwarzał niezaufane dane wejściowe i mógł wykonywać nieodwracalne akcje. Trzy z trzech.

Safety ≠ Security - ale w agentach granica się zaciera

Kolejny temat, który wyraźnie rezonował na summitcie, to rozmycie granicy między safety i security w kontekście systemów agentowych.
W tradycyjnym ujęciu podział jest stosunkowo czytelny. Safety to ochrona przed przypadkowymi szkodami powodowanymi przez sam system AI - halucynacje, błędy logiczne, nieprzewidziane zachowania. Security to ochrona systemu AI przed celowymi atakami z zewnątrz - prompt injection, nieautoryzowany dostęp, manipulacja.

W systemach agentowych ten podział staje się niezwykle trudny do utrzymania. Gdy agent podejmuje autonomiczną decyzję, która prowadzi do szkody - czy to problem safety, czy security? Czy agent „się pomylił", czy został zmanipulowany? Gdy incydent rozwija się w sekundach, a nie w godzinach, nie ma czasu na analizę, który zespół - safety czy security - powinien zareagować. Tej decyzji może się po prostu nie dać podjąć w czasie rzeczywistym.

To ma praktyczne konsekwencje dla sposobu, w jaki organizujemy zespoły, procesy reagowania na incydenty i systemy monitoringu. Na summitcie mówiono wprost: gdy agenty są aktorami, liniowy model detect-contain-eradicate-recover się łamie. SIEM, który reaguje post factum, przychodzi za późno, gdy akcje agenta są nieodwracalne.

OWASP Top 10 for LLM - eksperci kontra rzeczywistość


Zapowiadana na summitcie aktualizacja OWASP Top 10 for LLM Applications - której publikacja jest oczekiwana jeszcze w tym miesiącu - przynosi interesujący metawniosek. Badania oparte na ponad 130 źródłach z okresu styczeń 2025 - kwiecień 2026 pokazują, że opinie ekspertów dotyczące największych zagrożeń związanych z LLM są częściowo rozbieżne z obserwacjami dokonywanymi na prawdziwych incydentach. Bardziej niż w przypadku tradycyjnych systemów.

To odsłania dodatkowe, systemowe ryzyko. Wciąż próbujemy nadążyć za ciągle zmieniającym się krajobrazem AI. Nasze mentalne modele zagrożeń kształtowały się w innej epoce technologicznej i nie zawsze dobrze mapują się na rzeczywistość. Szczelina pomiędzy tym, gdzie wydaje nam się, że są nasze zabezpieczenia, a gdzie rzeczywiście się znajdują - może okazać się przepaścią.

Co z tego wynika?

Wróciłem z Londynu z przekonaniem, że jesteśmy w momencie przełomowym. Nie w sensie marketingowym - w sensie czysto operacyjnym. Systemy agentowe wchodzą do produkcji szybciej, niż jesteśmy w stanie budować dla nich zabezpieczenia. Incydenty takie jak PocketOS czy przejęcie kont na Instagramie to nie są odległe scenariusze - to rzeczy, które dzieją się teraz.

Kilka myśli na wynos:

Rewizja modeli uprawnień jest pilna. Agenty nie powinny dziedziczyć pełnych uprawnień użytkownika, który je uruchomił. Potrzebujemy oddzielnych, ograniczonych profili uprawnień dla agentów - z zasadą najmniejszego przywileju stosowaną jeszcze bardziej rygorystycznie niż w przypadku ludzi.

Monitoring musi się zmienić. Dziewięć sekund od działania do katastrofy to nie jest czas, w którym człowiek zdąży zareagować. Potrzebujemy automatycznych mechanizmów wykrywania i blokowania anomalii w zachowaniu agentów - w czasie rzeczywistym.

Shadow AI to realne zagrożenie. Nawet jeśli Twoja organizacja nie buduje rozwiązań agentowych, Twoi pracownicy prawdopodobnie już ich używają. Polityka bezpieczeństwa musi to uwzględniać.

Bezpieczeństwo AI to nie osobna dyscyplina - to cyberbezpieczeństwo. Granica między safety a security w systemach agentowych jest na tyle rozmyta, że wymaga zintegrowanego podejścia, a nie osobnych zespołów pracujących w silosach.

OWASP GenAI Security Project jest jednym z niewielu miejsc, gdzie ta wiedza się konsoliduje w sposób praktyczny i dostępny. Jeśli jeszcze nie śledzisz ich prac - warto zacząć. Tempo zmian jest takie, że za pół roku będziemy mówić o zupełnie innych problemach.

Autor

Maksym Brzęczek
Maksym Brzęczek
IT Security Systems Engineer
Dzięki za przeczytanie i poświęcony czas. Ten wpis to moje osobiste podsumowanie tego, co najmocniej wybrzmiało na summitcie, ale wiem, że perspektyw może być więcej. Jeśli macie inne doświadczenia, przykłady albo nie zgadzacie się z którymś wnioskiem, koniecznie dajcie znać w komentarzu. Chętnie podyskutuję.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może zainteresować Cię także:

CVE-2024-9150

.NET Reflection based Server Side Template Injection in WynEnterprise. Vulnerability write-up from our expert Maksym Brzęczek.

Przeczytaj teraz
Cyberprzestępcy uwielbiają tych, którzy... (bezpieczeństwo - 5 najczęstszych błędów) 

Cyberataki zdarzają się każdej minuty, a nieświadomość może nas sporo kosztować. Poznaj najczęstsze błędy, które narażają bezpieczeństwo Twoich danych. Dowiedz się, jak ich unikać i skutecznie zabezpieczyć swoją cyfrową przestrzeń.

Przeczytaj teraz
XDR vs. Antywirus

W świecie, gdzie cyberzagrożenia stają się coraz bardziej zaawansowane, tradycyjne antywirusy mogą okazać się niewystarczające. Czy XDR to przyszłość ochrony danych? Odkryj, jak nowoczesne podejście do detekcji i reagowania zmienia reguły gry w cyberbezpieczeństwie.

Przeczytaj teraz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Cyberbezpieczeństwo i ochrona danych.
Testy penetracyjne, socjotechniczne i wydajnościowe. Audyty bezpieczeństwa i szkolenia. 
Autoryzowany partner OffSec w Polsce.
© 2024 efigo.pl

Z nami bezpieczniej.
+48 570 450 695
+48 512 669 907
Efigo Sp. z o.o.
ul. Mikołaja Kopernika 8/6
40-064 Katowice

NIP: 9542760427
pl_PLPL