OWASP Top 10 for LLM Applications 2026 – pełny przegląd nowej listy ryzyk AI

4 sierpnia 2026 roku OWASP GenAI Security Project opublikował nową edycję OWASP Top 10 for LLM Applications – listy dziesięciu najkrytyczniejszych ryzyk bezpieczeństwa dla aplikacji opartych na dużych modelach językowych. To pierwsza aktualizacja, w której ranking oparto zarówno na głosach setek ekspertów AI security, jak i na analizie tysięcy rzeczywistych incydentów.

W tym artykule przechodzimy przez wszystkie dziesięć kategorii ryzyka z nowej listy oraz omawiamy, co ta aktualizacja oznacza w praktyce dla CISO, CTO i zespołów budujących aplikacje LLM.

Co to jest OWASP Top 10 for LLM?

OWASP Top 10 for LLM Applications to lista dziesięciu najkrytyczniejszych kategorii ryzyka bezpieczeństwa dla aplikacji zbudowanych na dużych modelach językowych, tworzona przez społeczność ekspertów AI security w ramach OWASP GenAI Security Project. Dokument powstaje na bazie pracy setek praktyków cyberbezpieczeństwa, którzy analizują realne incydenty, publikacje badawcze i doświadczenia z wdrożeń produkcyjnych systemów opartych na LLM.

Lista działa podobnie jak klasyczny OWASP Top 10 dla aplikacji webowych, tylko przeniesiony na specyfikę modeli językowych. Obejmuje ryzyka wynikające z tego, jak:

• LLM przetwarza dane wejściowe,
• korzysta z narzędzi i pamięci,
• jego wyniki trafiają do dalszych systemów.

Dla zespołów budujących chatboty, asystentów, agentów AI czy integracje RAG stanowi punkt odniesienia przy ocenie ryzyka, projektowaniu zabezpieczeń i przygotowywaniu testów bezpieczeństwa.

Dokument jest aktualizowany cyklicznie – dotychczasowe edycje to 2023 (wersja 1.0 i 1.1), 2025 oraz najnowsza, edycja 2026, opublikowana 4 sierpnia 2026 roku. Każda aktualizacja odzwierciedla zmieniający się sposób wykorzystania LLM w praktyce, od prostych chatbotów po autonomiczne agenty z dostępem do firmowych systemów.

Poza samą listą LLM Top 10, OWASP GenAI Security Project prowadzi też pokrewne projekty, takie jak OWASP Top 10 for Agentic Applications, które adresują ryzyka specyficzne dla systemów agentowych.

Co zmieniło się w OWASP Top 10 for LLM 2026?

Najważniejsza zmiana w OWASP Top 10 for LLM 2026 to metodologia – po raz pierwszy ranking oparto nie tylko na głosach ekspertów, ale też na analizie 7714 rzeczywistych incydentów bezpieczeństwa AI, z których 6639 sklasyfikowano i wykorzystano do oceny. Wynik końcowy każdej kategorii to połączenie dwóch źródeł:

• 75% wagi stanowi głos praktyków,
• 25% dane z incydentów.

Każda wcześniejsza wersja tej listy powstawała na bazie osądu. […] W tym roku zrobiliśmy coś, czego projekt nigdy wcześniej nie zrobił – zweryfikowaliśmy głosy społeczności wobec zapisu tego, co faktycznie poszło źle.

Tłum. własne na podstawie „Letter from the Project Leads”, OWASP Top 10 for LLM Applications 2026, s. 5

Ta metodologia ujawniła rozbieżności między tym, czego boją się praktycy, a tym, co faktycznie widać w danych incydentowych:

• Prompt Injection utrzymało 1. miejsce dzięki głosom ekspertów, mimo że w surowych danych incydentowych wypadłoby całkowicie poza pierwszą dziesiątkę. OWASP interpretuje to jako efekt obronny – zespoły security skutecznie blokują ataki, zanim trafią do publicznych baz.
• Misinformation poszło w odwrotną stronę: głosy stawiały je nisko, dane incydentowe wysoko. Lista finalnie umieściła je pośrodku, uznając samą rozbieżność za sygnał ostrzegawczy.

Zmienił się też układ całej dziesiątki. Excessive Agency awansowało z 6. na 3. miejsce – najbardziej doniosły ruch w rankingu, odzwierciedlający przejście od pytania „co model powie” do „co model może zrobić, jeśli się pomyli”. Unbounded Consumption wzrosło o cztery pozycje, z 10. na 6. Najbardziej spadło Improper Output Handling – z 5. na 10. miejsce.

Jedna kategoria zmieniła nazwę: dawne System Prompt Leakage (edycja 2025) zostało przemianowane na Hidden Context Exposure, obejmując szerszy zakres wycieku – nie tylko sam system prompt, ale cały kontekst dostępny modelowi (pamięć, dokumenty RAG, schematy narzędzi).

Pełna lista 10 kategorii ryzyk OWASP LLM Top 10 2026

OWASP Top 10 for LLM Applications 2026 obejmuje dziesięć kategorii ryzyka, ułożonych według połączonej oceny głosów ekspertów i analizy rzeczywistych incydentów. Każda kategoria opisuje inny mechanizm, przez który aplikacja oparta na dużym modelu językowym może zostać skompromitowana, wykorzystana do wycieku danych albo doprowadzona do szkodliwego działania.

Pełna lista w kolejności rankingu 2026 OWASP LLM Top 10:

• LLM01: Prompt Injection – manipulacja modelem przez dane wejściowe, które zmieniają jego zachowanie w sposób niezamierzony przez twórcę aplikacji.
• LLM02: Sensitive Information Disclosure – ujawnienie poufnych, regulowanych lub prywatnych danych przez nieautoryzowany kanał wyjściowy.
• LLM03: Excessive Agency – nadmierne funkcje, uprawnienia lub autonomia przyznane agentowi LLM, które pozwalają na szkodliwe działania po błędzie lub manipulacji modelu.
• LLM04: Supply Chain – podatności w modelach, adapterach, danych treningowych, narzędziach i platformach wdrożeniowych, wynikające z niepewnego pochodzenia lub integralności komponentów.
• LLM05: Data and Model Poisoning – manipulacja danymi lub artefaktami modelu w celu wprowadzenia szkodliwych zachowań, uprzedzeń lub podatności.
• LLM06: Unbounded Consumption – niekontrolowane wnioskowania, które prowadzą do zakłócenia dostępności usługi, nieproporcjonalnych kosztów finansowych lub kradzieży modelu.
• LLM07: Misinformation – generowanie nieprawidłowych, niekompletnych lub wprowadzających w błąd informacji, które wpływają na decyzje ludzi lub działania systemów.
• LLM08: Hidden Context Exposure – nieautoryzowane wydobycie lub odtworzenie niewidocznych dla użytkownika instrukcji systemowych i kontekstu operacyjnego modelu.
• LLM09: Vector and Embedding Weaknesses – słabości w mechanizmach wyszukiwania podobieństwa i geometrii wektorów, wykorzystywane niezależnie od instrukcji podawanych modelowi.
• LLM10: Improper Output Handling – niedostateczna walidacja i sanityzacja wyników generowanych przez model przed ich przekazaniem do systemów i procesów niżej w łańcuchu przetwarzania.

LLM01: Prompt Injection

Prompt injection to podatność, w której dane wejściowe do modelu językowego – niezależnie od tego, czy pochodzą od użytkownika, z pobranej treści, z wyniku działania narzędzia, czy z obrazu lub audio – zmieniają zachowanie modelu w sposób niezamierzony przez twórcę aplikacji. Źródło problemu leży w architekturze: LLM nie rozróżnia „instrukcji” od „danych”, bo dla modelu to po prostu jeden ciąg tokenów. Nie istnieje więc odpowiednik zapytań parametryzowanych, znany z klasycznych baz danych.

Atak może przyjść z trzech różnych poziomów zaufania:

1. Bezpośrednia iniekcja to świadomie spreparowany prompt użytkownika.
2. Iniekcja pośrednia jest bardziej niebezpieczna – złośliwa instrukcja trafia do modelu przez treść, którą sam nigdy nie widział: stronę WWW, dokument PDF, e-mail, wynik zwrócony przez narzędzie czy nawet opis serwera MCP.
3. Najbardziej podstępny wariant wykorzystuje zaufane źródła: atakujący umieszcza tekst w publicznym zgłoszeniu na GitHubie albo w formularzu kontaktowym, licząc, że kiedyś trafi go asystent programisty lub agent działający na uprawnieniach ofiary.

Głośny przykład prompt injection z 2025 roku: badacze z Aim Security wykazali, że spreparowany e-mail mógł wywołać w Microsoft 365 Copilot eksfiltrację danych organizacji bez żadnej interakcji użytkownika, obchodząc przy tym zarówno klasyfikator prompt injection, jak i filtr przekierowań

Obecne LLM pozostają podatne z definicji. Dlatego kluczowe są działania:

• ograniczanie roli i uprawnień modelu w system prompcie (jako warstwa pomocnicza, nie jedyna),
• walidacja wyjścia modelu w kodzie aplikacji, według sztywnego schematu, zanim trafi do systemów niżej w łańcuchu,
• wymaganie potwierdzenia człowieka przed każdą nieodwracalną lub uprawnioną akcją.

LLM02: Sensitive Information Disclosure

Sensitive Information Disclosure to sytuacja, w której system oparty na LLM ujawnia dane poufne, regulowane lub zastrzeżone przez kanał, na który podmiot danych, administrator albo właściciel systemu nie wydał zgody. Kanałem wycieku nie jest tylko finalna odpowiedź modelu — to ważne zastrzeżenie, o którym łatwo zapomnieć. Argumenty wywołań narzędzi, ślady rozumowania, pobrane fragmenty dokumentów, logi, telemetria i nawet obserwowalne właściwości wnioskowania (czas odpowiedzi, długość tokenów) – wszystko to podlega tym samym zasadom klasyfikacji i redakcji, co treść odpowiedzi.

Ryzyko powstaje na czterech etapach cyklu życia modelu:

• etap treningu – model zapamiętuje fragmenty danych treningowych i odtwarza je dosłownie lub w formie odtwarzalnej,
• etap wnioskowania – model ujawnia żywy kontekst: system prompt, fragmenty RAG, pamięć innej sesji,
• etap pipeline’u – fine-tuning, destylacja i generowanie danych syntetycznych przenoszą poufne dane do pochodnych artefaktów,
• etap obserwacji – atakujący wnioskuje fakty z mierzalnych z zewnątrz właściwości (długość tokenów, prawdopodobieństwa logów, trafienia w cache), bez odebrania samej treści.

Podstawą obrony jest minimalizacja kontekstu przekazywanego do modelu, autoryzacja na poziomie dokumentu i fragmentu (nie całej bazy), oraz traktowanie śladów rozumowania jako danych wyjściowych pierwszej kategorii, nigdy jako pozostałości do debugowania.

LLM03: Excessive Agency

Excessive Agency to podatność, która pozwala na wykonanie szkodliwych działań w odpowiedzi na nieoczekiwane, niejednoznaczne lub zmanipulowane wyniki modelu językowego – niezależnie od tego, co wywołało błąd. Wyzwalaczem może być zwykła halucynacja, słabo zaprojektowany prompt, prompt injection, albo w systemach wieloagentowych – skompromitowany agent działający wcześniej w tym samym łańcuchu.

OWASP wskazuje trzy źródłowe przyczyny problemu:

• nadmierna funkcjonalność – narzędzie do odczytu dokumentów ma też prawo je usuwać, mimo że aplikacja tego nie potrzebuje,
• nadmierne uprawnienia – agent korzysta z konta technicznego, które ma prawo zapisu do całej bazy, choć wystarczyłby odczyt,
• nadmierna autonomia – system wykonuje przelewy, wysyła wiadomości albo zmienia konfiguracje bez zatwierdzenia człowieka.

To właśnie ta kategoria odnotowała najbardziej doniosły ruch w rankingu 2026 – z 6. na 3. miejsce. OWASP tłumaczy to przesunięciem nacisku: z pytania „co model powie” na „co model może zrobić, jeśli się pomyli”.

Bo na przykład wyobraźmy sobie osobistego asystenta e-mailowego, który ma dostęp do skrzynki wyłącznie w celu podsumowywania wiadomości. Problem zaczyna się wtedy, gdy narzędzie wybrane przez developera do tego zadania oferuje przy okazji funkcję wysyłania e-maili, choć aplikacja tego nigdy nie potrzebowała. Wystarczy jeden złośliwie spreparowany e-mail przychodzący, żeby nakłonić model do przeszukania skrzynki w poszukiwaniu danych wrażliwych i przesłania ich na adres atakującego.

Ograniczanie tego ryzyka wymaga projektowania architektury, nie łatania modelu:

• minimalizacja liczby i zakresu narzędzi dostępnych agentowi,
• wykonywanie akcji w kontekście uprawnień konkretnego użytkownika, nie generycznej, wysoko uprzywilejowanej tożsamości,
• wymóg zatwierdzenia przez człowieka dla akcji nieodwracalnych lub o wysokim wpływie,
• pełna mediacja – autoryzacja wdrożona w logice aplikacji, nie oparta na tym, czy model „zdecyduje”, że dana akcja jest dozwolona.

LLM04: Supply Chain

Supply Chain w kontekście LLM obejmuje podatności wpływające na integralność danych treningowych, modeli, adapterów, pipeline’ów konwersji i platform wdrożeniowych – od zatrutych zbiorów danych po podmienione artefakty modelu. W przeciwieństwie do klasycznych podatności w kodzie, tutaj ryzyko dotyczy też komponentów specyficznych dla uczenia maszynowego: modeli pretrenowanych od zewnętrznych dostawców, zbiorów danych, oraz lekkich adapterów typu LoRA, coraz częściej współdzielonych na platformach jak Hugging Face.

Skala problemu widoczna jest w kilku realnych incydentach. W grudniu 2022 roku złośliwy pakiet torchtriton podszył się na PyPI pod zależność PyTorch-nightly i wykradał dane z maszyn deweloperskich. Podobny mechanizm stał za PoisonGPT – dowodem koncepcji, w którym model z chirurgicznie zmienionymi parametrami rozpowszechniał dezinformację, jednocześnie przechodząc standardowe testy benchmarkowe.

Do tego dochodzi ryzyko, o którym rzadziej się mówi: serwisy konwertujące i mergujące modele. Badacze z HiddenLayer wykazali, jak można przejąć bota konwertującego format Safetensors na Hugging Face, wstrzykując złośliwe zmiany podczas samej transformacji modelu.

Podstawowe działania ograniczające ryzyko:

• dokładna weryfikacja dostawców danych i modeli, w tym regulaminów i polityk prywatności,
• prowadzenie aktualnego, podpisanego rejestru komponentów (SBOM rozszerzony o modele i zbiory danych – AIBOM),
• korzystanie z modeli wyłącznie ze zweryfikowanych źródeł, z kryptograficznym podpisem i sprawdzalną historią (np. OpenSSF Model Signing, Sigstore),
• traktowanie serwisów konwersji i mergowania modeli jako punktów wysokiego ryzyka, wymagających monitoringu na równi z produkcyjnym środowiskiem.

Budowanie bezpiecznego cyklu życia aplikacji LLM od samego początku, zamiast łatania go po fakcie, to temat, którym zajmujemy się w ramach konsultacji SSDLC.

LLM05: Data and Model Poisoning

Data and Model Poisoning to klasa ataków, w których napastnik – albo niebezpieczny proces – manipuluje danymi lub artefaktami modelu, wprowadzając szkodliwe zachowania, uprzedzenia lub podatności do wykorzystania. To nie jest zwykły błąd w kodzie, który da się załatać jedną poprawką. Zatrucie celuje w sam proces uczenia się modelu, więc naprawa często wymaga rewalidacji danych, ponownego treningu albo przebudowy całego pipeline’u.

Zatrucie może wystąpić na każdym etapie cyklu życia modelu – od pretreningu, przez fine-tuning, aż po tworzenie embeddingów wykorzystywanych w RAG. Najbardziej niepokojąca statystyka z raportu: już 250 zatrutych dokumentów wystarcza, by skompromitować modele w zakresie od 600 milionów do 13 miliardów parametrów, niezależnie od rozmiaru całego zbioru danych treningowych. To pokazuje, że skala ataku nie musi być proporcjonalna do rozmiaru modelu.

Na przykład w edycji 2026 przytoczono przykład, gdy modyfikacja szablonu czatu modelu (np. w pliku GGUF czy konfiguracji tokenizera) z instrukcjami aktywowanymi wyzwalaczem sprawiła, że po dystrybucji przez publiczne repozytorium, model zachowywał się normalnie przy typowych zapytaniach, ale po aktywacji wyzwalacza dokładność faktograficzna spadała z 90% do 15%, a skuteczność wstrzykiwania złośliwych adresów URL przekraczała 80% – zjawisko zweryfikowane na 18 modelach i 4 środowiskach wykonawczych.

Ochrona wymaga podejścia wielowarstwowego:

• śledzenie pochodzenia zbiorów danych i modeli (SBOM/ML-BOM), z wymuszonym podpisywaniem i weryfikacją integralności,
• ścisła walidacja wszystkich napływających danych, ze szczególną uwagą na zewnętrznych dostawców,
• izolowanie instrukcji systemowych od danych zewnętrznych w systemach RAG,
• ciągły red teaming modeli z użyciem promptów adwersarialnych i testów wykrywających ukryte wyzwalacze – nie zakładając, że standardowe dostosowanie bezpieczeństwa usuwa backdoory.

LLM06: Unbounded Consumption

Unbounded Consumption to sytuacja, w której aplikacja LLM dopuszcza nadmierne i niekontrolowane wnioskowania, pozwalając atakującym zakłócić dostępność usługi, wygenerować nieproporcjonalne koszty finansowe albo wykraść własność intelektualną poprzez klonowanie modelu. Wysokie wymagania obliczeniowe LLM, szczególnie w modelach rozliczanych za token w środowisku chmurowym, tworzą naturalną asymetrię kosztów – atakujący może wywołać nieproporcjonalnie drogie obliczenia, płacąc przy tym niemal nic.

Problem pogłębiają modele z rozszerzonym „myśleniem” (extended-thinking, reasoning), architektury agentowe z protokołami takimi jak MCP, oraz wejścia multimodalne, które potrafią zamienić pojedynczy obraz czy plik audio w tysiące tokenów kosztu. Same limity zapytań na sekundę już nie wystarczają – potrzebne są kontrole świadome liczby tokenów, sztywne limity budżetowe i „bezpieczniki” na poziomie agenta.

Dobrze pokazuje to scenariusz z otwartej sesji agentowej: gdy atakujący albo nawet zwyczajny użytkownik utrzymuje długą rozmowę, stopniowo dopisując treść, każda kolejna tura przetwarza cały narastający kontekst od nowa. Koszt pojedynczego zapytania rośnie z około 0,001 dolara przy pierwszej turze do około 0,50 dolara przy setnej. Żadne pojedyncze zapytanie nie przekracza limitu, bo każde z osobna zostaje w budżecie, ale suma po wielu równoczesnych lub długo trwających sesjach sięga setek dolarów.

Kluczowe działania ograniczające ryzyko:

• limity liczone w tokenach na minutę i dziennie, nie tylko w zapytaniach na sekundę, z szacowaniem kosztu przed wykonaniem inferencji,
• nieprzekraczalne sztywne limity budżetowe na poziomie klucza API, użytkownika i konta, które zatrzymują wnioskowanie, a nie tylko wysyłają alert,
• bezpieczniki agentowe (circuit breakers) – limity kroków, głębokości rekursji i czasu wykonania dla każdego uruchomienia agenta,
• aktualizowanie i utwardzanie frameworków serwujących model (wyłączenie niebezpiecznej deserializacji, ograniczenie przepustowości specjalnych tokenów).

LLM07: Misinformation

Misinformation występuje, gdy LLM lub aplikacja oparta na LLM generuje informacje nieprawidłowe, niekompletne lub wprowadzające w błąd, które wydają się wystarczająco wiarygodne, by wpłynąć na decyzję człowieka, przebieg zautomatyzowanego procesu albo działanie agenta.

W klasycznym chatbocie halucynacja kończy się niedokładnym tekstem na ekranie. W systemie agentowym ta sama pomyłka potrafi zamknąć prawdziwy alert bezpieczeństwa, zmienić konfigurację albo wprowadzić podatność do repozytorium kodu. To właśnie ta zmiana kontekstu – z czatu do autonomicznego działania – stała za awansem tej kategorii o dwa miejsca w rankingu 2026.

Ograniczanie tego ryzyka wymaga oddzielenia generowania od wykonania:

• wymaganie uzasadnienia w wiarygodnych, aktualnych źródłach przed podjęciem jakiejkolwiek akcji na podstawie wyniku modelu,
• wzorzec „sprawdź przed działaniem” (claim-check-act) – rozdzielenie fazy generowania od fazy weryfikacji i wykonania,
• walidacja argumentów wywołań narzędzi względem aktualnego stanu systemu, nie tylko względem tego, co „powiedział” model,
• ograniczanie zasięgu szkody przez najmniejsze uprawnienia, sandboxing i limity szybkości działania.

LLM08: Hidden Context Exposure

Hidden Context Exposure to nieautoryzowane wydobycie, wywnioskowanie lub odtworzenie niewidocznych dla użytkownika instrukcji systemowych i kontekstu operacyjnego umieszczonego w oknie kontekstowym modelu. Ta kategoria zastąpiła w edycji 2026 dawne „System Prompt Leakage”, a sam zakres został poszerzony: nie chodzi już wyłącznie o wyciek samego system promptu, ale o cały „niewidoczny” materiał, który aplikacja składa do okna kontekstowego modelu – zasady systemowe, treść z RAG, schematy dostępnych narzędzi, dyrektywy i reguły formatowania.

Fundamentalne założenie projektowe jest taki, że każdy ukryty kontekst należy traktować jako potencjalnie dostępny dla atakującego. Nie powinien on być jedynym mechanizmem kontroli bezpieczeństwa, a już zwłaszcza nie powinien zawierać sekretów – kluczy API, tokenów, connection stringów.

Nie każdy taki wyciek waży tyle samo. Jeśli z kontekstu wyciekną same reguły formatowania odpowiedzi, szkoda jest głównie teoretyczna. Zupełnie inaczej wygląda sytuacja, gdy w system prompcie ktoś zostawił klucz API albo token dostępowy – tu wyciek otwiera drogę do przejęcia konta czy zdalnego wykonania kodu w połączonym systemie. Warto więc rozróżniać:

• wyciek informacyjny (bez sekretów, bez logiki bezpieczeństwa),
• średni (reguły wewnętrzne czy kryteria filtrowania, które ułatwiają atak, ale nie otwierają krytycznych decyzji),
• wysoki (osadzone dane uwierzytelniające albo poleganie na tajności kontekstu jako mechanizmie autoryzacji),
• krytyczny (gdy wyciek prowadzi do zdalnego wykonania kodu, masowej eksfiltracji danych albo eskalacji uprawnień).

Weźmy taki przykład: atakujący, prowadząc z modelem zwykłą rozmowę, stopniowo wydobywa listę dostępnych narzędzi i schematy ich parametrów. Żadne dane uwierzytelniające nie wyciekają, żadna polityka nie zostaje jawnie złamana, ale atakujący zyskuje konkretne cele do kolejnych ataków typu prompt injection oraz punkt wyjścia do dalszego łączenia akcji.

Podstawowe zasady ograniczania ryzyka:

• nigdy nie umieszczać danych wrażliwych w ukrytym kontekście – zakładać, że wszystko dostępne modelowi może stać się dostępne użytkownikowi,
• wymuszanie kontroli behawioralnych przez deterministyczne, zewnętrzne mechanizmy, nie przez instrukcje w system prompcie,
• oddzielenie autoryzacji i separacji uprawnień od modelu – te kontrole muszą działać niezależnie i w sposób audytowalny.

LLM09: Vector and Embedding Weaknesses

Vector and Embedding Weaknesses to ryzyka, które pojawiają się w każdej aplikacji LLM zamieniającej tekst, obrazy, kod czy audio na liczby, a potem szukającej wśród nich podobieństw, by zdecydować, co model dostanie do przetworzenia. RAG jest tu najbardziej oczywistym przypadkiem, ale ta sama mechanika stoi też za pamięcią agentów opartą na wektorach, semantycznymi cache’ami i systemami do wykrywania duplikatów.

To zupełnie inny rodzaj problemu niż prompt injection. Atakujący nie musi przemycić żadnej złośliwej instrukcji – wystarczy, że zrozumie geometrię przestrzeni embeddingów i wykorzysta samą mechanikę wyszukiwania podobieństwa. Zatrucie sprawia, że system podaje błędne informacje. Inwersja sprawia, że system je ujawnia. Atak na wyszukiwanie sprawia, że system milczy, choć zna odpowiedź.

Osobna historia to retrieval jamming – atakujący wstrzykuje dokument-„bloker”, który nie zawiera żadnych złośliwych instrukcji. Wystarczy, że jest tak skonstruowany, by system wyszukiwania uznał go za najlepszą odpowiedź na konkretne zapytanie, i zablokował dostęp do informacji, którą baza faktycznie posiada.

Jak sobie z tym radzić?

• zakres dostępu ustalać już na poziomie zapytania do indeksu, nie jako filtr nałożony po fakcie,
• normalizować treść przed zapisem embeddingu (usuwać znaki zero-width, biały tekst na białym tle) i pilnować, skąd pochodzi każdy wektor,
• rozdzielać dane o różnym poziomie zaufania na osobne indeksy, nie tylko tagi klasyfikacyjne w jednej bazie,
• nigdy nie zwracać surowych wyników podobieństwa klientowi.

LLM10: Improper Output Handling

Improper Output Handling dotyczy niedostatecznej walidacji i sanityzacji tego, co model wygenerował, zanim ten wynik trafi do innych systemów i procesów. Skoro treść generowana przez LLM może być kontrolowana przez atakującego poprzez prompt, przekazanie jej dalej bez sprawdzenia działa podobnie jak danie użytkownikowi bezpośredniego dostępu do funkcjonalności aplikacji. Skutki bywają dotkliwe – XSS i CSRF w przeglądarce, SSRF, eskalacja uprawnień czy zdalne wykonanie kodu na backendzie.

To kategoria, która spadła w rankingu 2026 najbardziej ze wszystkich – z 5. na 10. miejsce. Nie oznacza to jednak, że ryzyko zmalało, tylko jej zakres wzrósł: obejmuje teraz również niebezpieczny kod generowany masowo przez asystentów programistycznych, a także sekwencje ANSI i inne znaki kontrolne, które w terminalu czy IDE mogą podszywać wizualnie treść albo porwać schowek.

Na przykład aplikacja pozwala użytkownikom formułować zapytania SQL przez czatowy interfejs zasilany LLM. Ktoś prosi model o zapytanie usuwające wszystkie tabele. Jeśli wygenerowane zapytanie nie zostanie zweryfikowane przed wykonaniem, cała baza danych po prostu przepada. Podobny mechanizm stoi za atakami, w których czat automatycznie renderuje obrazy Markdown albo podglądy linków z odpowiedzi modelu – atakujący, który kontroluje część kontekstu, wykorzystuje nazwę hosta czy parametry zapytania w adresie URL do wyprowadzenia treści rozmowy poza aplikację.

Dobre praktyki:

• traktowanie modelu jak każdego innego niezaufanego użytkownika i stosowanie tej samej walidacji wejścia na jego odpowiedzi, jaką stosuje się dla danych od ludzi,
• kodowanie kontekstowe wyjścia w zależności od miejsca użycia (HTML dla treści webowej, JavaScript dla kontekstów skryptowych w przeglądarce),
• zapytania parametryzowane dla każdej operacji bazodanowej korzystającej z wyniku modelu,
• wyłączenie automatycznego renderowania obrazów Markdown, podglądów linków i innych elementów, które mogą wywołać żądania wychodzące bez zgody użytkownika.

Mapowanie na NIST, MITRE ATLAS i inne frameworki bezpieczeństwa AI

Każda z dziesięciu kategorii OWASP Top 10 for LLM 2026 ma przypisane odniesienia do dziewięciu zewnętrznych standardów i taksonomii bezpieczeństwa AI:

• OWASP Top 10 for Agentic Applications (ASI),
• OWASP GenAI Data Security (DSGAI),
• MITRE ATLAS,
• MITRE ATT&CK,
• CWE,
• NIST AI 600-1,
• NIST AI RMF,
• CSA AI Controls Matrix (AICM)
• OWASP AIVSS.

Mapowania oznaczono dwoma symbolami – ● dla głównej linii obrony lub opisu ryzyka, ○ dla elementu wspierającego, który dopełnia obraz, ale nie stanowi jego centrum.

Kilka konkretnych mapowań pokazuje, jak to działa w praktyce.

• Prompt Injection łączy się głównie z ASI01: Agent Goal Hijack (przejęte instrukcje systemowe przekierowują cele agenta) i ASI02: Tool Misuse & Exploitation (wstrzyknięte dane wywołują nieautoryzowane wywołania narzędzi).
• MITRE ATLAS obejmuje aż pięć taktyk adwersarza: AML.TA0004 Initial Access, AML.TA0005 Execution, AML.TA0006 Persistence, AML.TA0007 Defense Evasion (atakujący maskują wstrzyknięcie niewidocznym Unicode, kodowaniem Base64 czy ROT13, żeby ominąć filtry bezpieczeństwa) i AML.TA0010 Exfiltration.
• Excessive Agency z kolei krzyżuje się z aż siedmioma elementami ASI, co samo w sobie tłumaczy, dlaczego ta kategoria wymaga podejścia całościowego, obejmującego zarówno LLM Top 10, jak i OWASP Top 10 for Agentic Applications.

Dla organizacji układających politykę zgodności ta warstwa mapowań ma praktyczne znaczenie – pozwala jednym audytem czy jedną oceną ryzyka pokryć wymogi wynikające z NIST AI RMF, bo ten framework OWASP mapuje bezpośrednio do każdej z dziesięciu kategorii. NIST AI RMF, ISO/IEC 42001 i unijny AI Act w praktyce się przenikają, więc warto rozpatrywać je razem przy budowaniu programu zgodności – trzeba jednak pamiętać, że formalne mapowanie w tym dokumencie OWASP obejmuje NIST AI RMF, nie ISO 42001 ani sam AI Act, więc zgodność z tymi dwoma ostatnimi wymaga osobnej oceny.

Co nowa lista OWASP oznacza w praktyce dla CISO, CTO i zespołów technicznych

Największa zmiana w edycji 2026 dotyczy samego pytania, jakie zadaje sobie zespół bezpieczeństwa. Do niedawna priorytetem było sprawdzenie, co model powie – dziś kluczowe jest ustalenie, co model może zrobić, jeśli się pomyli. Coraz więcej organizacji łączy LLM z realnymi narzędziami, kontami i budżetami, więc pomyłka modelu przestaje być kwestią złego tekstu, a staje się kwestią realnej akcji.

Oznacza to konkretną zmianę w sposobie budowania architektury dla CISO, CSO, CTO i zespołów technicznych. Autorzy listy ujmują to bezpośrednio w liście od liderów projektu – nie da się zbudować modelu, którego nie da się oszukać, więc trzeba zbudować system, w którym oszukany model wciąż nie ma możliwości wyrządzić poważnej szkody.

Przestańcie próbować zbudować model, którego nie da się oszukać. Zbudujcie wokół niego system tak, by gdy model zostanie oszukany – a to się stanie – nic ważnego się nie zepsuło.

Tłum. własne na podstawie „Letter from the Project Leads”, OWASP Top 10 for LLM Applications 2026, s. 5

To oznacza, że trzeba inwestować mniej energii w „uszczelnianie” samego promptu, a więcej w ograniczanie uprawnień, walidację wyjścia i wymóg zatwierdzenia człowieka dla akcji nieodwracalnych.

Oto kilka obszarów praktycznych dla zespołów technicznych i architektów AI:

• każde wdrożenie agenta LLM zaczyna się od inwentarza narzędzi, uprawnień i danych, do których ma dostęp.
• audyt bezpieczeństwa aplikacji LLM musi obejmować cały łańcuch: model, dane treningowe, RAG, pamięć, narzędzia, serwery MCP i konta techniczne, a nie tylko sam prompt,
• zespoły compliance mogą wykorzystać mapowania z sekcji wyżej, żeby jedną oceną ryzyka pokryć wymogi NIST AI RMF – a przy okazji, dzięki temu, że te frameworki się przenikają, ułatwić sobie ocenę zgodności z AI Act i ISO/IEC 42001, choć te dwa wymagają już osobnej weryfikacji,
• red teaming systemów LLM powinien testować atakujących, którzy znają wdrożone zabezpieczenia – w materiale źródłowym statyczne testy ataków wykazują skuteczność bliską zeru, podczas gdy testy adaptacyjne przekraczają 90% skuteczności wobec większości sprawdzonych zabezpieczeń

Zanim wdrożysz kolejnego agenta AI w organizacji, warto przejść przez tę krótką checklistę, zbierającą najważniejsze mitygacje z całej listy:

• ograniczone do minimum narzędzia, uprawnienia i autonomia agenta (LLM03),
• walidacja wyjścia modelu w kodzie aplikacji, według sztywnego schematu, przed przekazaniem dalej (LLM01, LLM10),
• autoryzacja i separacja uprawnień wymuszone niezależnie od modelu, nigdy przez instrukcje w system prompcie (LLM08),
• sztywne, nieprzekraczalne limity budżetowe i bezpieczniki na poziomie agenta (LLM06),
• podpisany, aktualny rejestr modeli, adapterów i zbiorów danych (LLM04, LLM05),
• wymóg zatwierdzenia człowieka dla akcji nieodwracalnych lub o wysokim wpływie (LLM03, LLM07),
• zakres dostępu do indeksu wektorowego ustalony na poziomie zapytania, nie jako filtr po fakcie (LLM09),
• red teaming z pełną wiedzą o wdrożonych zabezpieczeniach, nie tylko testy statyczne (LLM01).

Najczęstsze pytania o OWASP Top 10 for LLM 2026

Czym różni się OWASP Top 10 for LLM 2026 od poprzedniej edycji?
Największa różnica to metodologia – ranking po raz pierwszy oparto na analizie 7714 rzeczywistych incydentów bezpieczeństwa AI, a nie wyłącznie na głosach ekspertów. Zmieniła się też kolejność kategorii: Excessive Agency awansowało z 6. na 3. miejsce, Unbounded Consumption z 10. na 6., a System Prompt Leakage zostało przemianowane na szerszą kategorię Hidden Context Exposure.

Czy ta lista dotyczy tylko dużych firm budujących własne modele AI?
Nie, dotyczy każdej organizacji korzystającej z LLM w produkcie czy procesach wewnętrznych – niezależnie od tego, czy trenuje własny model, czy integruje API zewnętrznego dostawcy z chatbotem obsługi klienta lub agentem wewnętrznym. Ryzyka takie jak Excessive Agency czy Improper Output Handling wynikają z architektury aplikacji wokół modelu, nie z samego treningu.

Jak zacząć wdrażanie zabezpieczeń z OWASP Top 10 for LLM w mojej organizacji?
Dobrym punktem startowym jest inwentaryzacja: jakie narzędzia, dane i uprawnienia ma dostęp każdy model i agent działający w organizacji, oraz gdzie znajdują się największe luki względem checklisty z tego artykułu. W Secawa pomagamy w tym poprzez konsultacje SSDLC, które obejmują bezpieczne projektowanie cyklu rozwoju aplikacji LLM i agentowych od samego początku.

Czy testy penetracyjne obejmują ryzyka z tej listy?
Tak, o ile są zaprojektowane pod specyfikę aplikacji LLM, a nie tylko klasyczną infrastrukturę webową – dobry test penetracyjny sprawdza między innymi odporność na prompt injection, nadmiarowe uprawnienia agentów i walidację wyjścia modelu przed przekazaniem go dalej. Nasze testy penetracyjne uwzględniają te scenariusze przy aplikacjach wykorzystujących AI. Jeśli wolisz zacząć od podstaw teoretycznych, zanim zamówisz test, o AI w kontekście cyberbezpieczeństwa rozmawialiśmy podczas naszego cyklu webinarów AI vs Cybersecurity – nagrania są dostępne bezpłatnie.

Źródła wykorzystane do stworzenia artykulu:

https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026