Unbounded Consumption bei LLMs: Last und Kosten begrenzen
OWASP LLM10: Unbounded Consumption
Unbounded Consumption bezeichnet in der OWASP-Liste eine KI-Anwendung, die Anfragen ohne wirksame Obergrenze entgegennimmt. Der Punkt fasst zusammen, was die Fassung 2023/24 der Liste als Angriff auf die Verfügbarkeit beschrieben hat, und nimmt zwei Dinge dazu: die Belastung der Rechnung und das Abschöpfen des Modells über die eigene Schnittstelle. Der Schutz liegt in Grenzen, die vor dem Betrieb gesetzt werden, weil sie danach eine Abwägung gegen laufende Nutzer sind.
Warum die Liste jetzt vom Verbrauch spricht
In der Fassung 2023/24 stand an dieser Stelle der OWASP-Liste zu LLM-Anwendungen noch „Model Denial of Service“. Der Name benannte einen Angriff mit klarem Ziel: das System soll stehen. Seit der Fassung 2025 heißt er „Unbounded Consumption“ und beschreibt einen Zustand der Anwendung. Der alte Punkt LLM10 „Model Theft“ ist darin aufgegangen, weil die Nachbildung eines Modells über die Schnittstelle technisch dasselbe tut wie ein Lastangriff, nur mit einem anderen Zweck.
Diese Umstellung ändert, wonach eine Prüfung sucht. Wer nach einem Angriff sucht, sucht nach Auffälligkeiten im Verkehr. Wer nach unbegrenztem Verbrauch sucht, fragt nach der Obergrenze und stellt fest, dass keine gesetzt ist. Der zweite Befund steht auch dann fest, wenn nie jemand angegriffen hat, und er lässt sich ohne Vorfall beheben.
Die Anfrage, die das System ausbremst
Ein Sprachmodell rechnet pro Anfrage sehr unterschiedlich lange. Eine kurze Frage nach einer Telefonnummer und die Bitte, ein vollständiges Vertragswerk zusammenzufassen, sehen aus der Sicht einer Webanwendung gleich aus, beanspruchen den Rechner aber in ganz anderer Größenordnung. Genau diese Spreizung nutzt der Angriff aus: Eine Handvoll gezielt aufwendiger Eingaben reicht, wo ein klassischer Lastangriff sehr viel mehr Aufrufe braucht.
OWASP nennt dafür drei Formen. Bei der ersten, dem Variable-Length Input Flood, schickt ein Angreifer Eingaben stark unterschiedlicher Länge, damit die Verarbeitung ins Stocken gerät. Bei der zweiten, den ressourcenintensiven Anfragen, ist jede einzelne Eingabe so gebaut, dass das Modell möglichst lange daran rechnet. Bei der dritten, dem Continuous Input Overflow, wird mehr Text geschickt, als in das Kontextfenster des Modells passt, also in den Bereich, den es gleichzeitig verarbeiten kann.
Der Überlauf des Kontextfensters ist der Fall, der nicht nur beim Angriff auftritt. Ein Assistent, der Dokumente aus der eigenen Ablage nachlädt, füllt sein Kontextfenster mit jedem weiteren Treffer. Wo die Anwendung nicht sagt, wie viel sie höchstens nachlädt, entscheidet die Größe der gefundenen Dokumente über die Laufzeit, und ein einziges falsch abgelegtes Handbuch macht aus einer Auskunft eine Rechenaufgabe.
Wenn die Rechnung das Ziel ist
Denial of Wallet ist die Form, die bei zugekauften Modellen zuerst auffällt. Das Ziel ist nicht der Ausfall, das Ziel ist die Abrechnung. Wer ein Modell nach verbrauchten Token bezahlt, bezahlt jede Anfrage, die sein System annimmt, auch die eines Angreifers. Das System bleibt dabei verfügbar und schnell, die Betriebsüberwachung meldet also nichts. Der Schaden steht am Monatsende in der Rechnung.
Für einen Mittelbetrieb ist das die Form mit der geringsten Einstiegshürde, weil ein Chatbot auf der eigenen Website meist ohne Anmeldung erreichbar ist. Was eine solche Anwendung an Absicherung braucht, gehört deshalb schon in die Anforderungen an einen KI-Chatbot im Unternehmen und nicht in eine spätere Ausbaustufe.
Eigene Hardware verschiebt die Frage, statt sie zu beantworten. Wer das Modell im eigenen Haus betreibt, hat seine Kosten vorab bezahlt, und ein Lastangriff trifft dann die Antwortzeiten der eigenen Belegschaft statt das Budget. Wie sich diese Rechnung im Einzelfall aufstellt, zeigt unsere Seite zum lokalen LLM-Setup mit ihrer Kostenmatrix. Eine Obergrenze je Nutzer braucht auch der eigene Server.
Das Modell selbst als Beute
Model Extraction geht den umgekehrten Weg: Nicht die Anwendung soll leiden, das Modell soll herauskommen. Ein Angreifer fragt die Schnittstelle über Wochen systematisch ab und trainiert mit den gesammelten Antworten ein eigenes Modell nach, das sich ähnlich verhält. OWASP führt daneben die funktionale Nachbildung, bei der die gesammelten Antworten als Trainingsmaterial für das Finetuning eines frei verfügbaren Modells dienen.
Interessant ist das dort, wo in der Anpassung Arbeit steckt: bei einem Modell, das mit eigenen Daten nachtrainiert wurde, oder bei einem aufwendig entwickelten System Prompt. Wer eine solche Anwendung öffentlich erreichbar macht, gibt sie in kleinen Portionen mit heraus.
Dazu kommt ein technisches Detail, das leicht übersehen wird. Viele Schnittstellen liefern auf Wunsch die Wahrscheinlichkeiten der ausgegebenen Token mit (Logprobs). Für die Fehlersuche ist das nützlich, für einen Angreifer ist es der kürzeste Weg zum Modellverhalten. In einer öffentlich erreichbaren Anwendung hat dieser Parameter nichts verloren.
Wo im Betrieb die Fläche liegt
Die erste und größte Fläche liegt dort, wo eine Anwendung ohne Anmeldung erreichbar ist und pro Anfrage frei formulierten Text entgegennimmt. Das trifft den Chatbot auf der Website, das Kontaktformular mit automatischer Vorsortierung und die Dokumentenanalyse, die Kunden selbst starten dürfen.
Eine zweite Fläche entsteht im Inneren, und sie braucht keinen Angreifer. Ein Agent, der Werkzeuge aufrufen darf, kann sich in einer Schleife selbst beschäftigen, weil er auf ein Ergebnis wartet, das nicht kommt. Was ein solches System darf und wo ein Mensch vor der Ausführung dazwischentritt, behandelt unsere Seite zu Excessive Agency. Für die Kostenseite gilt dabei dieselbe Regel wie für die Rechte: eine Obergrenze je Lauf, nicht je Aufruf.
Die dritte Fläche liegt in der Eingabe selbst. Eine Prompt Injection kann ein Modell anweisen, möglichst lange Ausgaben zu erzeugen oder einen Arbeitsschritt zu wiederholen. Der Verbrauch ist dann die Folge der Übernahme und nicht ihr Zweck, die Rechnung fällt trotzdem an.
Grenzen, die vor dem ersten Nutzer stehen
Die Eingabe begrenzen. Eine Obergrenze für Zeichen und für die Größe hochgeladener Dateien ist der billigste Schutz überhaupt und fällt einmal bei der Einrichtung an. Sie wirkt gegen die überlange Einzeleingabe und gegen den Überlauf des Kontextfensters; gegen die Masse kurzer Anfragen hilft erst der nächste Punkt.
Anfragen je Nutzer deckeln. Rate Limiting begrenzt, wie viele Anfragen aus einer Quelle in einem Zeitraum durchgehen. Ohne Anmeldung greift es nur über die IP-Adresse, und das ist wenig; für alles, was Geld kostet, ist eine Anmeldung deshalb die wirksamere Maßnahme.
Jede Anfrage abbrechen können. Ein Zeitlimit je Anfrage und eine Obergrenze für die erzeugten Token verhindern, dass eine einzelne Aufgabe unbegrenzt weiterläuft. Die Obergrenze für die Ausgabe ist in den gängigen Schnittstellen ein Parameter, das Zeitlimit setzt der aufrufende Dienst.
Die Kosten überwachen wie die Verfügbarkeit. Ein Alarm auf den Tagesverbrauch findet den Denial of Wallet, den kein Ausfallmonitoring sieht. Der Schwellenwert ergibt sich aus dem Normalbetrieb der ersten Wochen.
Bei Überlast kontrolliert abbauen. Eine Anwendung, die unter Last in eine Warteschlange schaltet oder auf ein kleineres Modell ausweicht, bleibt bedienbar. Das ist eine Entwurfsentscheidung und keine Einstellung.
Die Schnittstelle nicht mehr preisgeben lassen als nötig. Logprobs und verwandte Parameter bleiben im öffentlichen Betrieb abgeschaltet, und ein angepasstes Modell gehört hinter eine Anmeldung mit nachvollziehbarer Nutzung.
Fazit
Der neue Name benennt die Ursache: Eine Anwendung, die keine Grenze kennt, wird irgendwann bis an ihre Grenze benutzt, und der Anlass dafür muss kein Angriff sein. Ein fehlerhaftes Skript auf Kundenseite erzeugt dieselbe Rechnung wie ein Angreifer, nur ohne Absicht. Wer die Grenzen aus dem vorigen Abschnitt festlegt, bevor die Anwendung online geht, hat den Großteil erledigt; welche weiteren Punkte der Liste die eigene Anwendung betreffen, zeigt unser Überblick zur Sicherheit von KI-Systemen.