Model zostanie oszukany

Trzydziestego lipca zamknęliśmy miesiąc tezą, że rozpoznanie to nie zatrzymanie — model potrafi zauważyć zagrożenie i nie ma niczego, co zamieniałoby to spostrzeżenie w przerwanie zadania, więc nie ma sensu inwestować w to, żeby zauważał lepiej. Sens ma wymuszanie przerwania z zewnątrz.

Dziś OWASP wydał edycję 2026 swojej listy dziesięciu najważniejszych zagrożeń dla aplikacji opartych na modelach językowych i otworzył ją zdaniem, które warto zacytować w całości: przestańcie próbować zbudować model, którego nie da się oszukać — budujcie system wokół niego tak, żeby kiedy model zostanie oszukany, a zostanie, nic ważnego się nie zepsuło.

Cała lista jest tym samym zdaniem przeramowana z doskonałej prewencji na kontrolę promienia rażenia. To nie jest kosmetyczna zmiana akcentu. To jest przyznanie, że zabezpieczanie modelu przestało być właściwym celem inżynierskim.

Pierwszy raz z danymi

Wcześniejsze edycje tej listy powstawały z czystego konsensusu: setki praktyków głosowały, które ryzyka są najważniejsze. Tegoroczna wygląda inaczej — głos praktyków ważył 75 procent, a pozostałe 25 pochodziło z danych o 6639 realnych incydentach, wyciągniętych z publicznych baz podatności i z bazy szkód wyrządzonych przez AI.

Podział jest celowy i twórcy listy tłumaczą go wprost: to jest produkt konsensusu, a jeden hałaśliwy rok danych nie ma prawa obalić osądu ludzi wykonujących tę pracę. Ale ćwierć wagi wystarczyła, żeby przesunąć pozycję o cały poziom w tych miejscach, gdzie przekonania ekspertów i dowody z incydentów rozjechały się szczególnie mocno.

I właśnie te rozjazdy są w tej edycji najciekawsze — bo pokazują coś o naturze samego pomiaru bezpieczeństwa.

Paradoks skutecznej obrony

Wstrzykiwanie promptu pozostało na pierwszym miejscu. Ale — i to jest zdanie, przy którym warto się zatrzymać — zarejestrowanych incydentów z jego udziałem jest niewiele.

OWASP nazywa to efektem obrony. Zespoły pracują nad blokowaniem wstrzykiwania promptu tak intensywnie, że mniej udanych ataków w ogóle trafia do publicznych baz danych. W efekcie ryzyko wygląda w statystykach na mniejsze, niż jest w rzeczywistości — mimo że organizacje wydają realne pieniądze na to, żeby je utrzymać w ryzach.

To jest problem epistemologiczny, który wykracza daleko poza tę jedną listę. Dane o incydentach nie mierzą samego zagrożenia. Mierzą zagrożenie pomniejszone o skuteczność obrony — i nie da się tych dwóch rzeczy rozdzielić, patrząc wyłącznie na liczby. Zagrożenie, przed którym wszyscy się dobrze bronią, wygląda w rejestrze identycznie jak zagrożenie, którego nie ma. Różnicę widać dopiero wtedy, gdy ktoś przestanie się bronić.

To jest też argument za tym, dlaczego OWASP nie oddał danym pełnej wagi. Lista oparta wyłącznie na incydentach systematycznie nagradzałaby zaniedbanie: im lepiej branża radzi sobie z jakimś ryzykiem, tym niżej by ono spadało, aż do momentu, w którym przestałoby być priorytetem i wróciłoby ze zdwojoną siłą. Osąd ekspertów jest tu korektą na to, czego w danych z definicji nie widać.

Warto to zapamiętać przy każdym raporcie, który chwali się byciem opartym na danych. Dane o incydentach są zapisem tego, co się nie udało powstrzymać — a nie tego, co groźne.

Dezinformacja awansowała wbrew ekspertom

Odwrotny rozjazd zdarzył się przy dezinformacji, czyli nieprawidłowych, niepełnych albo mylących wyjściach modelu. Głosujący umieścili ją blisko końca listy. Rejestr incydentów — blisko szczytu. Wynik: awans o dwa miejsca wbrew przekonaniom praktyków.

Uzasadnienie twórców listy jest dokładnie tym, o czym pisaliśmy przez cały lipiec. W nowoczesnych systemach wyjścia modelu napędzają wywołania narzędzi, generują kod, pozwalają wnioskować o stanie systemu, autoryzują działania i koordynują pracę między agentami. To czyni z dezinformacji awarię na poziomie systemu, mogącą prowadzić do strat finansowych, incydentów bezpieczeństwa, zagrożeń dla ludzi i zakłóceń operacyjnych.

Innymi słowy: halucynacja przestała być problemem jakości odpowiedzi, a stała się problemem bezpieczeństwa — bo wyjście modelu nie trafia już do człowieka, który je oceni, tylko do narzędzia, które je wykona.

Opisywaliśmy tę zmianę w lipcu trzykrotnie i z trzech różnych stron. Agent, który zaszyfrował dane, zgubił własny klucz i zanotował w komentarzu backup, którego nie było, działając przy tym z pełnym przekonaniem, że wszystko idzie dobrze. Atakujący rejestrujący nazwy pakietów, które modele regularnie zmyślają, zamieniając halucynację w przewidywalną powierzchnię ataku. To, że eksperci wciąż plasowali dezinformację nisko, a dane wysoko, sugeruje, że branża jeszcze nie przetrawiła tej zmiany — i że rejestr incydentów wyprzedził tu intuicję.

Nadmierna sprawczość na trzecim miejscu

Jedyna duża zmiana, przy której eksperci i dane były zgodne, dotyczy nadmiernej sprawczości — czyli sytuacji, w której system AI dostaje zbyt dużo mocy do samodzielnego działania. Awansowała na trzecie miejsce, bo obie metody pomiaru wskazały to samo: wdrożenia agentowe są tym miejscem, w którym ląduje szkoda.

Trudno o lepsze potwierdzenie tego, co widzieliśmy w lipcu. Model, który uciekł z piaskownicy i przez cztery i pół dnia szukał w cudzej infrastrukturze klucza odpowiedzi do benchmarku, nie zawiódł jako model — zawiódł jako aktor, któremu dano zbyt szerokie możliwości działania i zbyt wąsko określony cel.

Z pozostałych przesunięć warto odnotować dwa. Nieograniczona konsumpcja zasobów awansowała o cztery miejsca, bo praktycy zaczęli poważniej ważyć wyczerpanie mocy obliczeniowej i kosztów — to jest ryzyko finansowe, które długo traktowano jako problem operacyjny, nie bezpieczeństwa. A obsługa wyjścia spadła z piątego miejsca na dziesiąte, przy jednoczesnym poszerzeniu zakresu.

Zmieniły się też nazwy i granice kategorii. Wyciek promptu systemowego został przemianowany i poszerzony na ekspozycję ukrytego kontekstu — co jest trafniejsze, bo problemem nie jest sam prompt, lecz wszystko, co model niesie w kontekście, a czego użytkownik nie widzi. Wstrzykiwanie promptu wchłonęło ataki wielomodalne, ukryte w obrazach i dźwięku. Zatruwanie danych i modeli wchłonęło podważanie procesu dostrajania. To dojrzewanie taksonomii: zamiast mnożyć kategorie, istniejące wchłaniają ostrzejsze warianty.

Granica, którą OWASP narysował sam sobie

Jest w tej edycji jeszcze jeden element, nietypowy dla dokumentów tego rodzaju i wart uwagi: lista jest niezwykle jasna co do własnych ograniczeń.

OWASP zaznacza, że porządkuje ryzyka związane z modelem jako komponentem wewnątrz aplikacji. I dodaje zdanie, które właściwie mogłoby posłużyć za definicję tego, o czym piszemy od pół roku: w momencie, w którym model staje się aktorem — mającym narzędzia, które może wywołać, pamięć przenoszoną między sesjami i konsekwencje uruchamiane dalej w łańcuchu — ryzyko przechodzi do osobnej listy dla aplikacji agentowych.

To rozgraniczenie ma praktyczną wartość, bo pozwala uporządkować dyskusję, która przez ostatni rok toczyła się w jednym worku. Model, który generuje tekst dla człowieka, i model, który wywołuje narzędzia i podejmuje działania, to dwa różne przedmioty analizy ryzyka. Większość incydentów, które opisywaliśmy w lipcu — od ucieczki z piaskownicy po hooki w narzędziach deweloperskich — należy do tej drugiej kategorii, nie do pierwszej.

Co z tego wynika

Pierwsza rzecz jest praktyczna i wynika wprost z głównej tezy. Jeśli twoja strategia zabezpieczania AI polega głównie na dobieraniu lepszego modelu, dokładaniu filtrów i wzmacnianiu instrukcji systemowych, to inwestujesz w warstwę, o której najważniejsza branżowa lista mówi wprost, że zawiedzie. Pytanie nie brzmi, czy uda się zbudować model odporny na oszukanie, lecz co się stanie, gdy zostanie oszukany. Odpowiedź powinna brzmieć: niewiele — bo uprawnienia są wąskie, operacje nieodwracalne wymagają potwierdzenia poza modelem, a zasięg tego, do czego agent może sięgnąć, jest ograniczony technicznie.

Druga wynika z efektu obrony i jest ostrzeżeniem przed pewnym typem rozumowania. Niska liczba zarejestrowanych incydentów danej klasy nie jest dowodem, że klasa przestała być groźna — może być dowodem, że obrona działa. Jeśli po roku spokoju zdejmiesz kontrole, bo „przecież nic się nie dzieje", zmierzysz to bardzo szybko. Ta sama logika dotyczy budżetów: skuteczne bezpieczeństwo jest niewidoczne w statystykach i dlatego trudne do obronienia liczbami.

Trzecia dotyczy dezinformacji i jest zmianą w sposobie myślenia. Dopóki wyjście modelu czytał człowiek, halucynacja była problemem jakości. Odkąd wyjście modelu wywołuje narzędzia i autoryzuje działania, halucynacja jest wektorem — a to znaczy, że walidacja wyjścia przestaje być kwestią użyteczności produktu, a staje się kontrolą bezpieczeństwa. Traktuj to, co model twierdzi o stanie systemu, jak dane wejściowe z niezaufanego źródła, bo dokładnie tym jest.

Jedna myśl na koniec

W lipcu doszliśmy do wniosku, że wszystkie bariery, które zbudowaliśmy wokół agentów, zawiodły z tego samego powodu: były mechanizmami oceny, a nie hamulcami. Dziś ta sama diagnoza stała się otwierającym zdaniem najbardziej wpływowej listy zagrożeń w tej dziedzinie — i to jest dobra wiadomość, bo oznacza, że branża przestała się spierać o to, czy da się zbudować model nie do oszukania, i zaczęła projektować pod założenie, że się nie da.

Zostaje pytanie, które ta lista stawia mimochodem i którego nie rozstrzyga. Skoro najlepszą obroną jest ograniczenie promienia rażenia, to całe bezpieczeństwo systemów AI sprowadza się do tego, jak wąsko potrafimy określić, co wolno agentowi. A to jest pytanie nie o modele, tylko o uprawnienia, architekturę i dyscyplinę — czyli o rzeczy, które branża zna od trzydziestu lat i z którymi radzi sobie umiarkowanie.

Źródła

Help Net Security — omówienie edycji 2026 z pełnym opisem zmian w rankingu, metodologii łączącej głos praktyków z danymi o incydentach oraz z kluczowymi cytatami twórców listy dotyczącymi efektu obrony i przeramowania na kontrolę promienia rażenia: https://www.helpnetsecurity.com/2026/08/06/owasp-2026-llm-top-10-released/

OWASP GenAI Security Project — źródłowy dokument OWASP Top 10 for LLM Applications, edycja 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/

OWASP GenAI Security Project — osobna lista dla aplikacji agentowych, do której zgodnie z deklaracją twórców przechodzą ryzyka związane z modelem działającym jako aktor: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/