Nieograniczone zużycie zasobów (OWASP LLM10) - gdy atak na model to atak na portfel

W skrócie: LLM10 Unbounded Consumption zamyka listę OWASP dla aplikacji LLM - i jest szersza niż klasyczny Denial of Service, z którego częściowo wyrasta. Obok przestoju usługi dochodzi ryzyko czysto finansowe: Denial of Wallet, czyli wygenerowanie realnego rachunku u dostawcy modelu przez zalew kosztownych zapytań. Dochodzi też ryzyko dla własności intelektualnej - ekstrakcja modelu przez masowe, systematyczne odpytywanie API.

Tym wpisem seria o liście OWASP Top 10 for LLM Applications 2025 jest kompletna - wszystkie dziesięć kategorii ma już swój osobny, dogłębny wpis.

To dziesiąty wpis z serii o liście OWASP dla aplikacji LLM, po halucynacjach, łańcuchu dostaw modeli, ujawnianiu danych wrażliwych, wstrzykiwaniu promptu, wycieku promptu systemowego, bezpieczeństwie RAG, nadmiernej sprawczości agentów, niezaufanych odpowiedziach modelu i zatruwaniu danych.

Więcej niż stary Denial of Service

Klasyczny DoS kończy się jednym skutkiem - usługa przestaje odpowiadać. Unbounded Consumption to pojęcie szersze, bo modele językowe mają specyfikę, jakiej klasyczne aplikacje nie miały: koszt każdego zapytania liczony w tokenach, rozliczany bezpośrednio pieniędzmi, często w modelu pay-per-use u zewnętrznego dostawcy. OWASP definiuje tę kategorię jako sytuację, w której aplikacja LLM pozwala na nadmierne, niekontrolowane wnioskowanie modelu, co prowadzi do odmowy usługi, strat finansowych, kradzieży modelu i degradacji jakości usługi. To cztery różne skutki jednego źródłowego problemu: braku twardych limitów.

Denial of Wallet - nowy rodzaj ryzyka biznesowego

Tradycyjny atak DoS kosztuje ofiarę przestój. Denial of Wallet kosztuje ją pieniądze - i to bez konieczności zatrzymywania usługi. W architekturze, gdzie firma płaci dostawcy modelu za każdy token wejściowy i wyjściowy, atakujący nie musi przeciążyć infrastruktury, żeby wyrządzić szkodę. Wystarczy wygenerować dużą liczbę kosztownych zapytań - długich, złożonych, wymagających wielu kroków wnioskowania - żeby rachunek na koniec miesiąca okazał się nieproporcjonalnie wysoki względem normalnego ruchu. Usługa przy tym może działać bez zarzutu, więc standardowy monitoring dostępności niczego nie wykryje. Jedyny sygnał to koszt, który czasem widać dopiero na fakturze.

Ekstrakcja modelu - kradzież przez odpytywanie

Drugi istotny scenariusz z tej kategorii nie dotyczy kosztu, tylko własności intelektualnej. Atakujący wysyła do API starannie dobrane zapytania na dużą skalę i zbiera odpowiedzi, żeby odtworzyć zachowanie modelu w formie własnego, "cienia" (shadow model). Pokrewna technika - replikacja funkcjonalna - polega na generowaniu przez API syntetycznych danych treningowych, które posłużą do wytrenowania zupełnie innego modelu o podobnych możliwościach. To obchodzi klasyczne zabezpieczenia przed ekstrakcją, bo formalnie nikt nie "kopiuje" niczego - tylko korzysta z publicznego interfejsu w sposób, do którego nie został zaproszony.

Pozostałe scenariusze z listy OWASP

Scenariusz	Mechanizm
Zapytania o nieograniczonej długości wejścia	Bardzo długi prompt zużywa nieproporcjonalnie dużo pamięci i mocy obliczeniowej względem typowego zapytania
Zalew żądań	Duża liczba równoczesnych zapytań przeciąża pojemność API, klasyczny wzorzec DoS przeniesiony na warstwę modelu
Celowo kosztowne zapytania	Polecenia wymuszające maksymalne, wieloetapowe wnioskowanie, zaprojektowane tak, żeby zużyć jak najwięcej zasobów na jedno żądanie
Ataki poboczne (side-channel)	Wykorzystanie filtrowania wejścia do wnioskowania o wagach i architekturze modelu bez bezpośredniego dostępu do nich

Dlaczego limit globalny nie wystarczy

Częsty błąd to ustawienie jednego, zbiorczego limitu na całą aplikację i uznanie tematu za zamknięty. Taki limit chroni przed skrajnym, oczywistym zalewem żądań, ale nie chroni przed sytuacją, w której pojedynczy klient albo pojedynczy klucz API systematycznie generuje nieproporcjonalny koszt, nie przekraczając przy tym progu, który zablokowałby całą usługę dla wszystkich. W architekturze wielodostępnej (multi-tenant), gdzie jedną instalacją modelu dzieli wielu klientów, globalny limit bez rozbicia na poszczególnych użytkowników oznacza, że jeden nietypowy klient może pogorszyć koszt i wydajność dla wszystkich pozostałych, zanim ktokolwiek to zauważy.

Co robić

Waliduj i ogranicz rozmiar wejścia. Twardy limit długości promptu i kontekstu, nie tylko miękka rekomendacja w dokumentacji API.
Wprowadź limitowanie żądań i kwoty per użytkownik. Rate limiting i kontrola dostępu oparta na rolach (RBAC), tak żeby jeden klucz API nie mógł wygenerować nieograniczonego kosztu.
Chroń zasoby na poziomie infrastruktury. Timeouty, throttling, dynamiczna alokacja zasobów i sandboxing dla zapytań o nietypowym profilu.
Monitoruj i wykrywaj anomalie. Logowanie wzorców zużycia i alerty przy nietypowym wzroście liczby lub kosztu zapytań, zanim pojawi się on na fakturze.
Stosuj techniki utrudniające ekstrakcję. Watermarking odpowiedzi, celowo stopniowana degradacja jakości przy podejrzanym wzorcu ruchu, filtrowanie tokenów wywołujących nietypowe zachowania modelu.
Prowadź inwentarz i automatyzację MLOps. Scentralizowany rejestr modeli i wdrożeń pozwala szybciej zauważyć, które środowisko generuje nietypowy koszt.

Co sprawdzamy w teście

Przy testach penetracyjnych aplikacji LLM w kontekście LLM10 weryfikujemy między innymi:

Czy istnieje twardy limit długości wejścia i czy da się go obejść (np. przez wiele krótszych zapytań zamiast jednego długiego).
Czy rate limiting i kwoty są egzekwowane per użytkownik lub token API, nie tylko globalnie dla całej usługi.
Czy da się wygenerować nieproporcjonalnie kosztowne zapytanie (długi łańcuch rozumowania, maksymalna liczba kroków) bez ograniczeń.
Czy monitoring kosztów wykrywa nietypowy wzorzec zużycia w czasie zbliżonym do rzeczywistego, nie dopiero na fakturze.
Czy API udostępnia wystarczająco dużo informacji (komunikaty błędów, czasy odpowiedzi), żeby ułatwić atak ekstrakcji modelu.

Czego to nie załatwi

Rate limiting i limity długości wejścia nie zatrzymają atakującego zdeterminowanego, żeby rozłożyć atak na wiele kont, adresów IP albo kluczy API - obrona musi uwzględniać wzorce zachowania w czasie, nie tylko pojedyncze żądanie. Pełne zabezpieczenie przed Denial of Wallet wymaga myślenia o modelu jako o zasobie kosztowym od samego początku projektowania architektury, nie jako o dodatku wprowadzanym po fakcie, gdy pierwsza nietypowa faktura już przyjdzie.

Na tym kończymy przegląd pełnej listy OWASP Top 10 for LLM Applications 2025. Jeśli budujecie lub utrzymujecie produkt oparty na modelu językowym, każdy z dziesięciu wpisów tej serii opisuje jedną konkretną kategorię ryzyka wraz z tym, co faktycznie sprawdzamy w teście penetracyjnym.