OWASP Top 10 LLM 2025 — ryzyka i ochrona systemów AI

OWASP Top 10 for LLM Applications 2025 porządkuje najważniejsze klasy ryzyka związane z aplikacjami korzystającymi z dużych modeli językowych. Lista nie dotyczy wyłącznie samego modelu. Obejmuje cały produkt: dane, RAG, system prompt, integracje, narzędzia agenta, łańcuch dostaw i sposób prezentowania odpowiedzi użytkownikowi. To właśnie na styku tych elementów powstają najpoważniejsze podatności.

Poniżej omawiamy wszystkie dziesięć kategorii z edycji 2025, ale nie jako słownik pojęć. Każde ryzyko przekładamy na scenariusz ataku, kontrolę techniczną i test, który można wykonać przed wdrożeniem. Punktem odniesienia jest oficjalny projekt OWASP GenAI Security Project.

OWASP Top 10 LLM 2025 — lista ryzyk

Aktualna lista obejmuje:

LLM01: Prompt Injection;
LLM02: Sensitive Information Disclosure;
LLM03: Supply Chain;
LLM04: Data and Model Poisoning;
LLM05: Improper Output Handling;
LLM06: Excessive Agency;
LLM07: System Prompt Leakage;
LLM08: Vector and Embedding Weaknesses;
LLM09: Misinformation;
LLM10: Unbounded Consumption.

Numer kategorii nie jest oceną konkretnej aplikacji ani gotowym modelem priorytetów. Zespół powinien połączyć listę z analizą aktywów, przepływów danych, uprawnień oraz skutków biznesowych. Pomaga w tym modelowanie zagrożeń wykonane zanim agent otrzyma dostęp do produkcyjnych systemów.

LLM01: Prompt Injection

Prompt injection polega na wpłynięciu na zachowanie modelu przez instrukcję, której aplikacja nie powinna traktować jako zaufanej. Atak może być bezpośredni, gdy użytkownik wpisuje polecenie w czacie, albo pośredni, gdy instrukcja jest ukryta w stronie WWW, dokumencie, wiadomości e-mail czy rekordzie pobranym przez RAG.

Najgroźniejszy wariant nie kończy się na ujawnieniu promptu. Jeżeli model może uruchamiać narzędzia, atakujący próbuje skłonić go do pobrania danych, zmiany konfiguracji albo wysłania informacji do zewnętrznej usługi. Filtr oparty wyłącznie na wykrywaniu fraz typu „ignore previous instructions” nie rozwiązuje problemu: tę samą intencję można wyrazić na wiele sposobów i w różnych językach.

Skuteczne zabezpieczenia to rozdzielenie danych od instrukcji, minimalne uprawnienia narzędzi, jawna zgoda użytkownika na operacje o skutkach ubocznych, walidacja parametrów po stronie kodu i izolacja treści zewnętrznej. Test powinien objąć bezpośrednie prompty, pliki, HTML, wyniki wyszukiwania oraz wieloetapowe próby, w których pozornie niewinna treść staje się instrukcją dopiero po połączeniu kontekstu.

LLM02: Sensitive Information Disclosure

Model może ujawnić dane osobowe, tajemnice przedsiębiorstwa, fragmenty dokumentów, klucze API albo informacje pochodzące z historii rozmów. Przyczyną bywa zbyt szeroki kontekst, błędna autoryzacja w RAG, logowanie pełnych promptów lub zwracanie treści z narzędzia bez filtrowania.

Kontrola dostępu musi działać przed pobraniem danych, a nie dopiero w odpowiedzi modelu. Każdy fragment indeksu wektorowego powinien zachowywać informacje o właścicielu, organizacji i poziomie poufności. Retrieval powinien filtrować dokumenty zgodnie z tożsamością użytkownika. Dodatkowo warto klasyfikować dane przed wysłaniem do dostawcy modelu, maskować sekrety i ustalić retencję logów. Szczegółowy proces opisujemy w poradniku o ochronie PII i prywatności w OpenAI.

Test polega między innymi na próbach dostępu między tenantami, odtwarzaniu cudzych fragmentów za pomocą podobnych pytań, prowokowaniu pełnego cytowania kontekstu oraz sprawdzaniu logów, telemetryki i systemów śledzenia błędów.

LLM03: Supply Chain

Aplikacja AI zależy od modeli, adapterów, datasetów, bibliotek, promptów, rozszerzeń, serwerów MCP i usług zewnętrznych. Kompromitacja jednego elementu może wpłynąć na wszystkie wdrożenia. Ryzykiem są także niesprawdzone modele z publicznego repozytorium, aktualizacja bez kontroli integralności albo pakiet o nazwie podobnej do popularnej zależności.

Organizacja powinna prowadzić inwentaryzację komponentów, przypinać wersje i skróty artefaktów, weryfikować podpisy, skanować zależności oraz mieć proces zatwierdzania modeli i źródeł danych. Pomocny jest SBOM z CycloneDX lub SPDX, choć dla systemu AI trzeba uzupełnić go o model, dataset, konfigurację i zależności runtime. Więcej scenariuszy omawiamy w analizie ataków na łańcuch dostaw oprogramowania.

Test kontrolny powinien sprawdzić, czy wdrożenie da się odtworzyć z zatwierdzonych artefaktów, czy pipeline blokuje niepodpisane komponenty i czy organizacja potrafi szybko ustalić, gdzie użyto podatnej wersji.

LLM04: Data and Model Poisoning

Poisoning oznacza celowe zanieczyszczenie danych treningowych, dostrajających, ewaluacyjnych albo bazy wiedzy RAG. Atakujący może wprowadzić fałszywe fakty, backdoor aktywowany określoną frazą lub treść ustawiającą jego produkt jako preferowany. W systemie uczącym się z ocen użytkowników nawet pozornie zwykły feedback może stać się kanałem wpływu.

Zabezpieczenia obejmują kontrolę pochodzenia danych, separację ról publikującego i zatwierdzającego, moderację zmian, wersjonowanie kolekcji oraz wykrywanie anomalii. Dane od użytkowników nie powinny automatycznie trafiać do zbioru uczącego. Dla krytycznych źródeł warto stosować podpisy, zasady quorum i porównanie odpowiedzi z niezależnym źródłem.

W testach należy spróbować dodać dokument z instrukcją, podmienić metadane, wykorzystać konflikt źródeł i sprawdzić, czy po usunięciu złośliwego rekordu indeks rzeczywiście zostaje przebudowany.

LLM05: Improper Output Handling

Odpowiedź modelu jest niezaufanym wejściem. Jeżeli aplikacja wstawia ją do HTML, zapytania SQL, polecenia systemowego, szablonu lub wywołania API bez walidacji, możliwe są klasyczne podatności: XSS, injection, SSRF, path traversal czy zdalne wykonanie kodu. Model nie jest sanitizerem i nie powinien sam zatwierdzać własnego wyniku.

Każdy konsument odpowiedzi musi stosować kontrolę odpowiednią dla kontekstu: kodowanie HTML, parametryzowane zapytania, allowlisty domen i argumentów, parser schematu oraz izolowane środowisko wykonawcze. Dla structured outputs trzeba walidować nie tylko składnię JSON, lecz także semantykę, zakresy, właściciela zasobu i dopuszczalność operacji.

Testuj odpowiedzi zawierające znaczniki, polecenia, adresy wewnętrzne, nietypowe kodowania i dane przekraczające oczekiwany rozmiar. Potem śledź je aż do końcowego systemu, bo luka często pojawia się dwa komponenty dalej.

LLM06: Excessive Agency

Excessive agency powstaje, gdy agent ma więcej narzędzi, uprawnień lub autonomii, niż potrzebuje do zadania. Przykładem jest asystent poczty, który może czytać wszystkie skrzynki, wysyłać wiadomości, zarządzać regułami i pobierać pliki, choć funkcja wymaga tylko przygotowania szkicu.

Należy ograniczyć zakres tokenów, udostępniać wyłącznie potrzebne narzędzia, oddzielać odczyt od zapisu i wymagać potwierdzenia dla nieodwracalnych działań. Parametry operacji powinien zatwierdzać deterministyczny kod. Krytyczne akcje potrzebują dodatkowej autoryzacji, limitu wartości lub zasady czterech oczu.

Test czerwonego zespołu powinien sprawdzić, czy agent potrafi rozszerzyć cel, użyć narzędzia poza kontekstem, wykonać serię pojedynczo dozwolonych działań o groźnym skutku łącznym albo ominąć ekran potwierdzenia. Zobacz także nasz przewodnik o agentach AI i automatyzacji.

LLM07: System Prompt Leakage

System prompt może zawierać reguły, opis architektury, nazwy narzędzi lub wewnętrzne wskazówki. Nie powinien jednak przechowywać sekretów ani być jedyną kontrolą autoryzacji. Model może ujawnić jego fragmenty wprost, przez transformację, streszczenie lub zachowanie wynikające z ukrytych instrukcji.

Traktuj prompt jak konfigurację, której poufność może zostać naruszona. Klucze i poświadczenia przechowuj poza nim, a decyzje bezpieczeństwa egzekwuj w kodzie. Ograniczaj informacje techniczne do minimum potrzebnego modelowi i testuj próby odtworzenia promptu w różnych formatach. Celem nie jest magiczne „ukrycie” tekstu, lecz brak katastrofalnych skutków po jego poznaniu.

LLM08: Vector and Embedding Weaknesses

RAG wprowadza nowe granice zaufania: proces indeksowania, metadane, wektorową bazę danych, mechanizm podobieństwa i kontekst przekazany modelowi. Błędne filtrowanie tenantów może ujawnić dokument innego klienta. Złośliwy plik może uzyskać wysoką pozycję dla wielu zapytań, a ukryta instrukcja w pobranym fragmencie może przejąć zachowanie agenta.

Wymagane są autoryzacja na poziomie dokumentu i fragmentu, walidacja źródeł, limity liczby rekordów, izolacja kolekcji, kontrola dostępu do endpointów indeksowania i cytowanie źródeł. Warto mierzyć także jakość retrieval: czy właściwy dokument pojawia się w top-k i czy nieuprawniony nigdy nie trafia do kontekstu.

Testy powinny objąć kolizje nazw, dokumenty o bardzo podobnej treści, nietypowe znaki, masowe indeksowanie, poisoning oraz usunięcie uprawnień po wcześniejszym zbudowaniu indeksu.

LLM09: Misinformation

Model może podać przekonującą, lecz fałszywą odpowiedź, stworzyć nieistniejące źródło albo pomieszać dane z kilku dokumentów. Problem staje się podatnością biznesową, gdy wynik automatycznie wpływa na decyzję medyczną, finansową, prawną czy operacyjną.

Ogranicz zakres odpowiedzi, pokazuj źródła, mierz groundedness, stosuj progi pewności i kieruj przypadki wysokiego ryzyka do człowieka. RAG nie gwarantuje prawdy: trzeba weryfikować zarówno retrieval, jak i zgodność odpowiedzi z pobranym materiałem. Dla procesów krytycznych model powinien przygotowywać propozycję, nie podejmować samodzielnej decyzji.

Ewaluacja potrzebuje reprezentatywnego złotego zbioru, pytań bez odpowiedzi i przypadków z konfliktującymi źródłami. Ciągły monitoring i guardraile AI są konieczne, ponieważ zachowanie może zmienić się po aktualizacji modelu lub danych.

LLM10: Unbounded Consumption

Atakujący może wymuszać kosztowne zapytania, długie konteksty, rekurencyjne pętle agenta, masowe generowanie obrazów albo wielokrotne wywołania narzędzi. Skutkiem jest rachunek, niedostępność usługi lub zużycie wspólnego limitu dostawcy. Klasyczny rate limiting per IP nie wystarcza w aplikacji wieloetapowej.

Ustal budżet tokenów, czasu, iteracji, wywołań narzędzi i kosztu dla użytkownika, organizacji oraz pojedynczego zadania. Dodaj globalny bezpiecznik, kolejki, timeouty, cache i limity współbieżności. Agent powinien kończyć pętlę po określonej liczbie kroków, nawet jeśli model twierdzi, że potrzebuje kolejnego.

Testuj długie konteksty, pliki kompresujące się do ogromnej treści, równoległe żądania, powtarzane retry, pętle narzędzi oraz różnice kosztu między modelami. Alert powinien reagować na tempo zmian, a nie dopiero na przekroczony miesięczny rachunek.

Jak użyć OWASP Top 10 LLM w projekcie

Lista daje najlepszy efekt, gdy staje się częścią cyklu wytwarzania:

podczas projektowania zespół tworzy diagram przepływu danych, listę narzędzi i granice zaufania;
przed implementacją definiuje wymagania dla każdej istotnej kategorii;
w CI uruchamia testy schematów, uprawnień, filtrów i budżetów;
przed produkcją wykonuje test bezpieczeństwa AI i LLM;
po wdrożeniu monitoruje model, retrieval, narzędzia, koszty i incydenty;
każda zmiana modelu, promptu, źródła danych lub narzędzia uruchamia ocenę regresji.

Praktycznym artefaktem jest macierz: kategoria OWASP, scenariusz biznesowy, aktywo, kontrola, właściciel, test i dowód. Sam status „mamy filtr” jest niewystarczający. Dowodem może być polityka IAM, test integracyjny, konfiguracja limitu, log zatwierdzenia lub raport z ćwiczenia red team.

Checklista przed wdrożeniem aplikacji LLM

Przed uruchomieniem odpowiedz „tak” co najmniej na poniższe pytania:

Czy dane i instrukcje są rozdzielone, a treść zewnętrzna oznaczona jako niezaufana?
Czy RAG filtruje każdy fragment zgodnie z tożsamością i tenantem?
Czy system prompt nie zawiera sekretów ani reguł autoryzacji?
Czy wynik modelu jest walidowany w kontekście końcowego odbiorcy?
Czy narzędzia mają minimalne uprawnienia i osobne zakresy zapisu?
Czy operacje wysokiego ryzyka wymagają świadomego potwierdzenia?
Czy komponenty, modele i źródła danych mają kontrolowane pochodzenie?
Czy obowiązują limity tokenów, kosztu, czasu, iteracji i współbieżności?
Czy logi umożliwiają odtworzenie decyzji bez przechowywania nadmiarowych danych?
Czy zestaw ewaluacyjny obejmuje ataki, regresje i pytania bez poprawnej odpowiedzi?

OWASP Top 10 LLM to początek, nie certyfikat

Zgodność z listą nie oznacza automatycznie, że aplikacja jest bezpieczna. OWASP Top 10 LLM to model świadomości ryzyka, a nie pełna norma certyfikacyjna ani gotowy zakres pentestu. System może przejść podstawowe próby prompt injection i jednocześnie mieć krytyczny błąd autoryzacji w API lub źle chroniony panel administracyjny.

Najlepsze rezultaty daje połączenie klasycznego pentestu aplikacji i API, testów warstwy AI, przeglądu uprawnień oraz ewaluacji biznesowej. Jeżeli potrzebujesz niezależnie sprawdzić produkt przed produkcją, opisz nam architekturę i zakres — przygotujemy scenariusze odpowiadające danym, modelom i narzędziom używanym przez Twoją aplikację.