LLMjacking: warum selbst gehostete KI-Server zur Kostenfalle werden

Du betreibst einen lokalen Chatbot für interne Dokumente, eine Agentur-Assistenz für Texte oder einen Forschungs-Endpoint an der Uni. Alles läuft, bis auf einmal die GPU dauerhaft ausgelastet ist, Anfragen hängen bleiben oder ein Cloud-Konto ungewöhnlich schnell Kosten erzeugt. Genau dieses Muster ist typisch für LLMjacking: Angreifer nutzen schlecht geschützte KI-Zugänge so, als wäre es ihr eigener Server.

Der Reiz für Betreiber ist verständlich. Selbst gehostete LLMs oder gemietete GPU-Instanzen versprechen Datenhoheit, Compliance und Kontrolle. Der Haken: Sobald ein Endpunkt offen im Netz steht oder Zugangsdaten in Repos, Logs oder Clients landen, wird aus „Kontrolle“ schnell „Kostenfalle“. Entro Labs beschreibt in einem Bericht aus 2025 einen Ablauf, bei dem kompromittierte, nicht-menschliche Identitäten (zum Beispiel API-Keys oder Service-Tokens) sehr schnell automatisiert geprüft und anschließend für teure Modellaufrufe missbraucht werden.

In diesem Artikel geht es nicht um Schuldzuweisungen. Du bekommst ein klares mentales Modell, welche Schritte Angreifer typischerweise gehen, welche Signale du früh erkennen kannst und welche Basismaßnahmen die meisten Fälle verhindern oder sehr schnell begrenzen.

LLMjacking ist weniger „Magie“ als klassischer Missbrauch von Zugängen, nur mit einem teuren Ziel: Rechenzeit für KI. In den untersuchten Fällen beginnt es häufig damit, dass sogenannte nicht-menschliche Identitäten kompromittiert werden. Gemeint sind Zugangsdaten, die nicht zu einer Person gehören, sondern zu Diensten: API-Keys, Tokens, Service-Accounts. Wenn so ein Schlüssel irgendwo öffentlich wird oder aus einer App extrahierbar ist, kann ihn praktisch jeder verwenden, der ihn findet.

Was passiert dann? Laut Entro Labs (2025) folgt oft ein klarer Ablauf: Erst wird automatisiert geprüft, ob die Zugangsdaten funktionieren. Danach wird erkundet, welche Modelle verfügbar sind und welche Aktionen erlaubt sind. In ihrem Bericht werden dafür beispielhaft Aufrufe genannt, die wie „Modellverfügbarkeit abfragen“, „Modelle auflisten“ oder „Modelle invokieren“ wirken. Zusätzlich werden – als Teil der Erkundung – auch Kosten- und Nutzungsinformationen abgefragt, um den „Wert“ eines kompromittierten Kontos einzuschätzen.

Sinngemäß nach Entro Labs (2025): Nach einem Leak zählt oft nicht „ob“, sondern wie schnell automatisierte Scanner den Schlüssel testen, Fähigkeiten abklopfen und mit echten Modellaufrufen beginnen.

Der springende Punkt für dich als Betreiber: LLMjacking ist nicht nur ein Sicherheitsproblem, sondern ein Betriebsproblem. Selbst wenn keine Daten abfließen, kann allein die unberechtigte Nutzung eine Rechnung auslösen, Limits aufbrauchen oder deinen Dienst für legitime Nutzer ausbremsen. Entro Labs berichtet außerdem von sehr kurzen Zeitfenstern zwischen Leak und erstem Zugriff und nennt als Beispielwerte eine durchschnittliche Zeit bis zum ersten Zugriff von 17 Minuten sowie einen schnellsten beobachteten Zugriff nach 9 Minuten. Im selben Bericht wird ein mögliches Kostenrisiko bis zu etwa 46.000 US-Dollar pro Tag als drastisches Beispiel für anhaltenden Missbrauch genannt.

Viele Teams hosten LLMs selbst, weil sie bestimmte Daten nicht an externe Dienste geben wollen oder weil sie die Kontrolle über Modelle, Prompts und Protokollierung brauchen. Das ist nachvollziehbar. Gleichzeitig verschiebt Selbsthosting die Sicherheitsverantwortung stark zu dir: Netzwerkgrenzen, Zugangskontrolle, Updates, Protokollierung und Kostenbremsen sind dann nicht mehr „Default“, sondern Aufgaben, die du aktiv lösen musst.

Ein häufiger Denkfehler ist: „Der Server ist doch nur für uns.“ In der Praxis reichen schon kleine Änderungen im Setup, um die Angriffsfläche zu öffnen: ein Endpoint, der versehentlich öffentlich erreichbar ist, ein Reverse Proxy ohne Authentifizierung, ein Test-Key, der in einem Git-Repository landet, oder ein Token, der in Client-Code eingebettet wird. Genau dieser Aspekt wird durch LM-Scout (2025) unterstrichen. Die Studie analysiert die Sicherheit von Sprachmodell-Integrationen in Android-Apps und zeigt, wie schnell Zugangsdaten oder Aufrufmuster in Clients sichtbar werden können. Sie berichtet über eine Untersuchung von 2.950 Apps und beschreibt, dass sich aus statischer und dynamischer Analyse automatisiert Skripte ableiten lassen, die Modellaufrufe reproduzieren. Für Betreiber ist die Lehre simpel: Alles, was im Client steckt, ist potenziell extrahierbar.

Selbst wenn du nicht „Mobile“ machst, ist das Prinzip gleich: Ein Agentur-Tool, ein internes Dashboard oder ein Uni-Demo-Frontend kann unbeabsichtigt zum Schlüsselhalter werden. Und je mehr Teams parallel experimentieren, desto mehr „kleine“ Zugangsdaten existieren. Entro Labs (2025) beschreibt zusätzlich, dass Angreifer bei der Erkundung nicht zwingend die offensichtlichsten Identitätsabfragen nutzen, sondern lieber leise und gezielt prüfen, was möglich ist. Das macht reine „Standard-Alarme“ weniger zuverlässig.

Hinzu kommt die Kostenmechanik: KI-Workloads sind spiky. Ein normaler Webserver fällt bei Mehrlast vielleicht nur durch höhere CPU auf. Ein KI-Server kann hingegen plötzlich sehr teuer werden, weil Modellaufrufe direkt in abrechenbare Nutzung übersetzen oder weil GPU-Zeit und Stromverbrauch hoch sind. LLMjacking nutzt genau diese Asymmetrie: Ein Angreifer muss nur einen funktionierenden Zugang finden, um den teuersten Teil deiner Infrastruktur zu bewegen.

Das Ziel ist, LLMjacking nicht erst zu bemerken, wenn die Rechnung kommt. Dafür brauchst du Signale, die früh auftreten und sich gut automatisieren lassen. Entro Labs (2025) beschreibt, dass Angreifer oft mit Erkundung beginnen, bevor sie dauerhaft invokieren. Praktisch heißt das: Nicht nur „Invoke“-Aufrufe sind interessant, sondern auch „Listen/Verfügbarkeit“-Muster und Kosten-/Nutzungsabfragen, die in einem normalen Betrieb seltener und planbarer sind.

Ein zweites Warnsignal ist die Form des Traffics. Automatisierte Zugriffe wirken oft anders als dein echter Nutzerverkehr: ungewohnte User-Agents, viele Anfragen in kurzer Zeit, ungewöhnliche Verteilung über IPs oder Regionen, und Prompts, die nicht zu deinem Produkt passen. Entro Labs nennt als Beispiel, dass automatisierte Zugriffe häufig mit SDK-typischen User-Agents wie botocore/* oder python-requests auftauchen können, während bei „wertvollen“ Tokens auch manuelle Zugriffe mit Browser-User-Agents beobachtet wurden. Für dich bedeutet das: User-Agent allein ist kein Beweis, aber in Kombination mit anderen Signalen ein guter Trigger.

Drittens gibt es betriebliche Symptome: GPU-Auslastung passt nicht zur Anzahl realer Nutzer, die Latenz steigt, Warteschlangen wachsen, oder du siehst viele sehr lange Prompts beziehungsweise auffällig hohe Prompt-Volumina. Auch ohne exakte Token-Metrik kannst du Annäherungen nutzen: Request-Body-Größe, durchschnittliche Antwortlänge, Anzahl Requests pro Schlüssel und pro Minute. Je näher deine Messpunkte an „pro Schlüssel“ oder „pro Service-Account“ sind, desto leichter erkennst du Missbrauch.

Wichtig ist die Einordnung: Nicht jede Auffälligkeit ist ein Angriff. USENIX Security (2024) zeigt in einem anderen, aber verwandten Feld – Prompt Injection –, dass Schutzmechanismen oft Trade-offs haben und dass reine Erkennung schnell entweder zu Fehlalarmen oder zu Lücken führen kann. Übertragen auf LLMjacking heißt das: Setze nicht nur auf einen Alarm, sondern auf ein Bündel aus Kostenbremsen, Zugangskontrolle und Monitoring. Dann ist ein einzelner Fehlalarm verkraftbar, aber ein echter Angriff bleibt selten unbemerkt.

Diese Checkliste zielt auf das, was in der Praxis am häufigsten schiefgeht: offene Endpunkte, schwache Identitäten, fehlende Limits, fehlende Sichtbarkeit und unsaubere Secret-Verwaltung. Du musst nicht alles auf einmal perfekt machen, aber jede Stufe reduziert den Schaden deutlich.

• Keine offenen Endpunkte: Stelle sicher, dass dein KI-Server nicht „aus Versehen“ öffentlich erreichbar ist. Prüfe Bindings, Firewall-Regeln, Reverse-Proxies und Test-Deployments. Ein interner Service gehört hinter VPN, Zero-Trust-Zugänge oder mindestens eine strikt begrenzte Netzwerkzone.
• Starke Authentifizierung: Verwende kurzlebige Tokens statt langlebiger Keys, wo es geht. Trenne Service-Accounts pro Anwendung und Zweck. Entro Labs (2025) betont die Rolle kompromittierter nicht-menschlicher Identitäten als Startpunkt. Je kleiner der Radius eines Tokens ist, desto weniger kann ein Angreifer damit tun.
• Rate-Limits und Quotas: Setze harte Grenzen pro Schlüssel: Requests pro Minute, parallele Anfragen, maximale Prompt-/Antwortgröße. Ergänze Tages- oder Monatsbudgets, die automatisch blocken oder in einen „Sicherheitsmodus“ schalten. Damit wird LLMjacking von der Kostenfalle zu einem begrenzten Störfall.
• Monitoring für GPU, Traffic und Prompt-Volumen: Logge mindestens: welcher Schlüssel, welche Route, welche Modell- oder Job-Art, Zeitpunkt, IP, User-Agent, Payload-Größe. Achte auf Muster wie Modell-Erkundung, Kosten-/Nutzungsabfragen und unerwartete Invoke-Sequenzen, wie sie Entro Labs (2025) beschreibt. Ergänze Kostenalarme, die bei ungewöhnlicher Steigerung früh triggern.
• Secrets sauber verwalten und Updates einplanen: Verhindere, dass Keys im Client landen. LM-Scout (2025) zeigt am Beispiel von App-Integrationen, wie leicht sich Client-Secrets extrahieren lassen. Nutze Secret-Stores, Rotation und klare Prozesse für Entzug/Neuausstellung. Halte Model-Server, Proxy und Abhängigkeiten aktuell, damit du nicht zusätzlich durch bekannte Schwachstellen verwundbar wirst.

Wenn du nur einen Punkt sofort umsetzt, nimm Quotas plus Kostenalarme. Das verhindert nicht jeden Zugriff, aber es begrenzt den Schaden zuverlässig und gibt dir Zeit, die Ursache zu finden.

LLMjacking ist im Alltag vor allem deshalb gefährlich, weil es schnell, leise und teuer sein kann. Die Berichte von Entro Labs (2025) zeigen, dass kompromittierte Service-Zugänge in Minuten getestet und anschließend für Modellaufrufe genutzt werden können. Gleichzeitig erinnert LM-Scout (2025) daran, wie leicht sich Zugangsdaten oder Aufrufmuster aus Clients und Integrationen herauslösen lassen, wenn Schutz nur „gefühlt“ vorhanden ist. Die gute Nachricht ist: Du musst kein Spezialteam aufbauen, um die meisten Risiken zu senken. Wenn Endpunkte nicht offen sind, Identitäten klein geschnitten werden, Quotas hart greifen und Monitoring wirklich pro Schlüssel arbeitet, wird aus der Kostenfalle ein kontrollierbarer Vorfall. Das macht selbst gehostete KI-Server wieder planbar und schützt auch deine Nutzer vor Ausfällen.