OWASP opublikował nową listę najważniejszych zagrożeń dla aplikacji opartych na dużych modelach językowych. Prompt Injection nadal zajmuje pierwsze miejsce, ale największy awans zaliczyło Excessive Agency. I słusznie, bo współczesny model rzadko kończy pracę na wygenerowaniu tekstu. Czyta pocztę, odpytuje bazy danych, uruchamia kod, korzysta z MCP, wywołuje API i działa na naszych uprawnieniach. Dotychczasowa błędna odpowiedź zmieniła się w błędną akcję. Tegoroczna aktualizacja przynosi też ważną zmianę metodologiczną. Ranking po raz pierwszy zestawiono z korpusem 7714 rzeczywistych incydentów. Zespół OWASP zdołał sklasyfikować 6639 z nich, a dane z incydentów otrzymały 25 procent wagi końcowego wyniku. Pozostałe 75 procent pochodziło z głosowania praktyków.

TL;DR

• Prompt Injection utrzymał pierwsze miejsce, a Sensitive Information Disclosure drugie.
• Excessive Agency awansowało z miejsca 6. na 3. To najważniejszy ruch w całym zestawieniu.
• Unbounded Consumption przesunęło się z miejsca 10. na 6., a Misinformation z 9. na 7.
• Improper Output Handling spadło z miejsca 5. na 10., ale jego zakres objął również niebezpieczny kod generowany przez asystentów.
• System Prompt Leakage zastąpiono kategorią Hidden Context Exposure. Nowy zakres obejmuje znacznie więcej niż wyciek jednego promptu systemowego.
• Prompt Injection uwzględnia teraz wyraźnie obrazy, audio, wideo, pamięć, RAG, wyniki narzędzi i pośrednie ataki przez treści, których użytkownik nawet nie widzi.
• Systemy agentowe trzeba analizować równolegle z OWASP Top 10 for Agentic Applications.

Infografika 1. OWASP Top 10 for LLM Applications 2026 i zmiana pozycji względem edycji 2025 (wygenerowano za pośrednictwem AI).

Ranking podparty tym, co wydarzyło się naprawdę

Poprzednie edycje listy powstawały głównie na podstawie wiedzy, obserwacji i głosów społeczności. W 2026 roku zespół OWASP dołożył do tego dane z publicznych baz podatności oraz bazy szkód związanych z AI. Najciekawsze są miejsca, w których głosy praktyków rozjechały się z zapisami incydentów. Kategoria Prompt Injection została przez społeczność oceniona jako najważniejsze zagrożenie. W surowych danych po incydentach nie znalazłaby się nawet w pierwszej dziesiątce. OWASP interpretuje tę różnicę jako efekt obronny. Zespoły bezpieczeństwa poświęcają zagrożeniu prompt injection dużo uwagi, więc część ataków zostaje zatrzymana lub nigdy nie trafia do publicznych baz. Sam brak dużej liczby opisanych incydentów nie oznacza małego ryzyka. Misinformation zachowało się odwrotnie. Praktycy umieszczali ten problem dość nisko, za to dane z incydentów pokazały znacznie większy wpływ. Płynna, pewnie brzmiąca bzdura przestała być wyłącznie kiepską odpowiedzią chatbota. Może dziś uruchomić błędny proces, wygenerować podatny kod, zmienić konfigurację albo skierować człowieka do złej decyzji.

To właśnie dane przesunęły część pozycji, ale nie przejęły całego rankingu. OWASP celowo przyznał im jedną czwartą wagi. Publiczne repozytoria incydentów są niepełne, różnie opisane i mocno zależne od tego, co organizacje zdecydowały się ujawnić.

Pełna lista OWASP Top 10 for LLM Applications 2026

2026	Zagrożenie	Pozycja w 2025	Zmiana	Co to oznacza w praktyce
1	Prompt Injection	1	=	Model wykonuje polecenia ukryte w treści użytkownika, dokumentach, stronach, obrazach, pamięci lub wynikach narzędzi.
2	Sensitive Information Disclosure	2	=	Poufne dane trafiają do odpowiedzi, logów, kontekstu, innych użytkowników lub zewnętrznych usług.
3	Excessive Agency	6	↑ 3	Agent ma zbyt szerokie funkcje, uprawnienia albo autonomię i może wykonać szkodliwą akcję.
4	Supply Chain	3	↓ 1	Ryzyko obejmuje modele, biblioteki, dane, narzędzia, serwery MCP i artefakty, których pochodzenie lub integralność są niepewne.
5	Data and Model Poisoning	4	↓ 1	Atakujący wpływa na dane treningowe, fine-tuning, RAG, embeddingi albo sam model.
6	Unbounded Consumption	10	↑ 4	Brak limitów pozwala wyczerpać tokeny, GPU, czas, pamięć, limity API albo budżet.
7	Misinformation	9	↑ 2	Wiarygodnie brzmiąca nieprawda prowadzi do złej decyzji, kodu lub wywołania narzędzia.
8	Hidden Context Exposure	7	↓ 1 i nowy zakres	Poza promptem systemowym wycieka pamięć, pobrane dane, instrukcje, wewnętrzny kontekst lub informacje z narzędzi.
9	Vector and Embedding Weaknesses	8	↓ 1	Błędy izolacji, uprawnień i integralności w RAG oraz bazach wektorowych prowadzą do wycieku lub manipulacji.
10	Improper Output Handling	5	↓ 5	Wynik modelu trafia bez walidacji do przeglądarki, interpretera, bazy, API lub procesu wykonującego kod.

Źródło: OWASP Top 10 for LLM Applications 2026 oraz edycja 2025.

Excessive Agency – model dostał ręce

Awans Excessive Agency z miejsca 6. na 3. najlepiej podsumowuje zmianę całego rynku. Dwa lata temu główne pytanie brzmiało: “Co da się zmusić model, żeby powiedział?”. Teraz ważniejsze jest: “Do czego model ma dostęp i co może zrobić, kiedy się pomyli albo ktoś nim steruje?”.

OWASP wskazuje trzy typowe źródła problemu:

• nadmiar funkcji, na przykład narzędzie do odczytu dokumentów potrafi je również usuwać;
• nadmiar uprawnień, na przykład agent korzysta z konta technicznego z prawem zapisu do całej bazy;
• nadmiar autonomii, na przykład wykonuje przelew, wysyła wiadomość albo zmienia konfigurację bez zatwierdzenia.

Wyobraźmy sobie agenta wspierającego helpdesk. Agent czyta zgłoszenia, pobiera dane z CRM, przeszukuje dokumentację i może wysyłać e-maile. Atakujący umieszcza ukrytą instrukcję w zgłoszeniu lub załączniku. Model odczytuje ją jako część kontekstu, pobiera informacje z CRM i wysyła je pod wskazany adres.

Prompt Injection był wejściem do ataku. Excessive Agency zapewniło zasięg, uprawnienia i skutek. Sam filtr promptów nie naprawi architektury, w której model trzyma klucze do wszystkiego.

Prompt Injection wyszedł poza okno czatu

Hasło “ignore previous instructions” nadal żyje, ale stanowi dziś najprostszy wariant ataku. Nowa definicja obejmuje znacznie więcej powierzchni wejścia:

• treść strony WWW, wiadomości e-mail, dokumentu PDF lub zgłoszenia w systemie ticketowym;
• fragment pobrany przez RAG albo zwrócony przez zewnętrzne narzędzie;
• opis narzędzia lub odpowiedź serwera MCP;
• obraz, ścieżkę audio albo materiał wideo zawierający ukryte instrukcje;
• złośliwy wpis zapisany w pamięci agenta i uruchamiany w kolejnych sesjach;
• niewidoczne znaki Unicode, steganografię lub zakodowane polecenia.

Atakujący nie musi rozmawiać z agentem. Wystarczy, że umieści treść w miejscu, które agent kiedyś przeczyta. Publiczny formularz, issue w repozytorium, opis produktu, CV, dokument w RAG albo wiadomość w skrzynce mogą stać się kanałem dostarczenia instrukcji. OWASP mówi wprost, że współczesne modele nie mają twardej, architektonicznej granicy między instrukcją a danymi. Obie rzeczy trafiają do tego samego strumienia tokenów. Filtry i klasyfikatory pozostają warstwą pomocniczą, a najważniejszym zabezpieczeniem jest ograniczenie skutków przejęcia modelu.

Hidden Context Exposure – prompt systemowy to tylko kawałek problemu

Nazwę System Prompt Leakage zastąpiono kategorią Hidden Context Exposure. Zmiana jest sensowna, bo sekret zaszyty w promptach stanowi tylko jeden z elementów kontekstu.

W praktycznej aplikacji model może widzieć:

• instrukcje systemowe i polityki działania;
• historię rozmowy oraz pamięć długoterminową;
• dokumenty pobrane przez RAG;
• odpowiedzi narzędzi, nazwy zasobów, ścieżki i wewnętrzne identyfikatory;
• fragmenty danych innych użytkowników lub tenantów;
• informacje potrzebne do rozumowania, których aplikacja nie powinna ujawniać.

Sam prompt systemowy nie powinien zawierać sekretów. To nadal prawda, ale nowa kategoria przesuwa uwagę na cały proces składania kontekstu, jego izolację, pochodzenie i kontrolę dostępu.

Koszty i halucynacje przesuwają się w górę

Unbounded Consumption awansowało o cztery miejsca. Modele oraz agenci potrafią uruchamiać długie pętle, wielokrotnie wywoływać narzędzia, generować ogromne konteksty i zużywać płatne API. Atak może uderzać w dostępność, ale równie skutecznie może uderzyć w rachunek. Limit tokenów na pojedyncze zapytanie nie wystarczy. Potrzebne są limity całego zadania, liczby kroków agenta, czasu wykonania, równoległości, wywołań narzędzi i kosztu przypisanego do użytkownika lub procesu.

Misinformation awansowało na miejsce 7. Powód jest prosty: odpowiedzi modeli coraz częściej trafiają bezpośrednio do procesów biznesowych. Halucynacja w czacie irytuje. Halucynacja w agencie SOC może zamknąć prawdziwy alert, w agencie administracyjnym zmienić konfigurację, a w asystencie programisty wprowadzić podatność do repozytorium.

Improper Output Handling spadło na miejsce 10., ale zakres kategorii rozszerzono o niebezpieczny kod generowany masowo przez asystentów. Spadek pozycji oznacza zmianę priorytetów całej listy, a nie zgodę na przekazywanie wyników modelu prosto do eval(), powłoki, SQL, przeglądarki albo API.

OWASP GenAI Security Project

Nowy pomysł czyli OWASP GenAI Security Project wyrósł z listy zagrożeń dla aplikacji LLM, ale dziś działa jako parasol dla znacznie większego zestawu inicjatyw. Projekt obejmuje między innymi:

Infografika 2. OWASP GenAI Security Project oraz granica między LLM jako komponentem i agentem jako wykonawcą (wygenerowano za pomocą AI).

• Top 10 for LLM and GenAI, czyli ryzyka modelu jako komponentu aplikacji;
• Agentic App Security oraz Top 10 for Agentic Applications, czyli ryzyka agentów korzystających z narzędzi, pamięci, tożsamości i autonomicznych przepływów;
• Data Security, w tym bezpieczeństwo danych treningowych, RAG, fine-tuningu i przepływu informacji;
• AI Threat Intelligence and Response, między innymi przeglądy rzeczywistych exploitów i incydentów;
• AI Security Governance oraz Secure AI Adoption;
• Red Teaming and Evaluation, czyli metodykę testowania modeli i całych aplikacji;
• AI Security Solutions Landscape oraz narzędzia wspierające transparentność łańcucha dostaw, takie jak AIBOM.

Nowy dokument zawiera także mapowania do OWASP Top 10 for Agentic Applications, NIST AI RMF, NIST Generative AI Profile, MITRE ATLAS, MITRE ATT&CK, CWE, CSA AI Controls Matrix oraz OWASP AIVSS. Dzięki temu lista może być punktem wejścia do threat modelingu, testów, wymagań zakupowych i kontroli bezpieczeństwa, a nie wyłącznie slajdem na szkoleniu.

Której listy używać?

Model działający jako komponent aplikacji, który przyjmuje dane i zwraca wynik, powinien być analizowany przede wszystkim przez OWASP Top 10 for LLM Applications. Agent mający pamięć, narzędzia, tożsamość, dostęp do systemów oraz możliwość wykonywania wieloetapowych akcji wymaga dodatkowo OWASP Top 10 for Agentic Applications. Typowe wdrożenie agentowe potrzebuje obu perspektyw. Prompt Injection opisuje sposób manipulacji wejściem. Excessive Agency, Tool Misuse, Identity and Privilege Abuse, Memory Poisoning albo Unexpected Code Execution opisują to, co może wydarzyć się później.

Co wdrożyć w praktyce?

1. Zinwentaryzuj prawdziwą powierzchnię ataku

Inwentaryzacja powinna objąć źródła danych, prompty, RAG, pamięć, modele, narzędzia, serwery MCP, konta techniczne, API oraz wszystkie miejsca, do których trafia wynik modelu. Diagram samego chatbota będzie za mały.

2. Traktuj INPUT jak dane od atakującego

Zasada dotyczy tekstu, dokumentów, stron, obrazów, audio, wyników wyszukiwania i odpowiedzi narzędzi. Wewnętrzny dokument też może zawierać payload, jeżeli wcześniej dostał się tam przez formularz, zgłoszenie albo repozytorium.

3. Oddziel decyzję modelu od wykonania akcji

Model może zaproponować operację. Zaufany kod powinien ponownie sprawdzić typ akcji, argumenty, uprawnienia, zakres danych i politykę bezpieczeństwa. Poświadczenia oraz możliwość zmiany stanu powinny pozostać poza modelem.

4. Ogranicz funkcje, uprawnienia i autonomię

Każde narzędzie powinno realizować możliwie wąski cel i działać na koncie z minimalnymi uprawnieniami. Operacje uprzywilejowane, nieodwracalne albo widoczne na zewnątrz wymagają zatwierdzenia z pokazaniem dokładnej akcji, a nie wygładzonego podsumowania wygenerowanego przez ten sam model.

5. Pilnuj pamięci i RAG

Zapis do pamięci trwałej powinien być traktowany jak operacja uprzywilejowana. Potrzebne są informacje o pochodzeniu wpisu, historia zmian, możliwość wycofania, izolacja tenantów i log wskazujący prompt, który wywołał zapis.

6. Wprowadź budżety i limity

Limituj liczbę kroków, wywołań modeli i narzędzi, czas, wielkość kontekstu, współbieżność oraz koszt. Monitoruj nietypowe pętle, nagłe skoki tokenów i procesy, które kontynuują pracę mimo braku postępu.

7. Testuj cały system, nie sam prompt…

Red teaming powinien obejmować pośrednie prompt injection, obrazy i audio, pamięć między sesjami, zatrucie RAG, narzędzia, MCP, eskalację uprawnień i walidację wyniku. Testy trzeba powtarzać po zmianie modelu, promptu, narzędzia, źródła danych lub polityki. Szczególnie groźne jest połączenie trzech elementów: dostępu do niezaufanej treści, dostępu do poufnych danych oraz możliwości komunikacji na zewnątrz lub zmiany stanu. Agent posiadający cały ten zestaw daje atakującemu gotową ścieżkę od payloadu do skutku.

Podsumowanie

Bezpieczne AI to nie model, którego nie da się oszukać. To system, w którym oszukany model nadal nie ma jak wyrządzić poważnej szkody. W klasycznym chatbocie zła odpowiedź kończyła się tekstem na ekranie. W agencie ta sama pomyłka może wywołać API, wysłać dane, zmienić konfigurację albo usunąć zasób. Prawdziwą granicą bezpieczeństwa nie jest prompt. Tworzą ją uprawnienia, narzędzia, walidacja i kontrola wykonania wokół modelu.

I właśnie tam powinien dziś pracować zespół security.

~Tomek Turba