Das Nadelöhr, das niemand auf dem Schirm hat
Wenn Unternehmen über „KI-Risiken" sprechen, meinen sie fast immer das Modell. Halluzinationen. Prompt Injection. Ein Agent, der aus seiner Sandbox ausbricht. Die Schlagzeilen der letzten Wochen haben genau diese Angst befeuert — und dabei übersehen, wo das eigentliche Problem liegt.
Unter dem Modell liegt eine Schicht, die fast niemand beachtet: der Proxy. Die Bibliothek, die Ihre Prompts entgegennimmt, an OpenAI, Anthropic oder Google weiterreicht und die Antwort zurückspielt. Genau diese Schicht hat jetzt jemand angegriffen.
LiteLLM ist der De-facto-Standard dieser Schicht. Eine Python-Bibliothek, die eine einheitliche Schnittstelle zu über 100 LLM-Providern bietet — Auth, Rate-Limiting, Kosten-Tracking, Fallbacks, Load-Balancing. Alles an einer Stelle. Zehntausende Entwickler haben sie in ihre Produktions-Stacks eingebaut, weil sie schlicht nützlich ist. Genau das macht sie zum perfekten Ziel.
Der größte Hebel für einen Angreifer ist nicht das teuerste Modell — es ist die unsichtbare Komponente, durch die alle Daten fließen.
Was passiert ist
Ein manipuliertes Paket in der LiteLLM-Lieferkette wurde über den Trivy-Scanner von Aqua Security entdeckt — und hat nach ersten Auswertungen mehr als 2.500 Unternehmen getroffen. Die genaue Zahl dürfte höher liegen, denn nicht jedes betroffene Unternehmen scannt seine Abhängigkeiten überhaupt.
Warum das so gefährlich ist, liegt in der Architektur des Angriffs. Ein LLM-Proxy sitzt an der engsten Stelle Ihres gesamten KI-Stacks:
- Jeder Prompt läuft durch ihn — inklusive Kundendaten, internen Dokumenten, Quellcode, Angeboten, Personaldaten.
- Jeder API-Key liegt in seiner Konfiguration — die Zugangsschlüssel zu allen angeschlossenen Modell-Anbietern.
- Jede Antwort kommt durch ihn zurück — die sensiblen Ergebnisse Ihrer Geschäftslogik.
Wer diesen Proxy kompromittiert, muss kein Modell hacken. Er muss nur zuhören. Und er bekommt alles mit: was Ihre Mitarbeiter fragen, welche Daten sie einspeisen, welche Antworten zurückkommen. Für ein Unternehmen unter der DSGVO ist das nicht ein technischer Vorfall — das ist ein Datenschutz-GAU.
Ein bekanntes Muster — nur jetzt mit KI
Wer glaubt, das sei ein Ausreißer, hat die letzten Jahre nicht aufgepasst. Das Muster ist erschreckend vertraut:
- xz-utils (2024): Eine Backdoor in einem Kompressions-Tool, das in praktisch jedem Linux-System steckt. Jahrelang unbemerkt eingeschleust.
- event-stream (2018): Ein winziges npm-Paket, das von Millionen Projekten genutzt wurde — bis ein Angreifer die Wartung übernahm und Schadcode injizierte.
- ua-parser-js (2021): Drei kompromittierte Versionen, die Krypto-Miner installierten. Milliarden Downloads.
- 3CX (2023): Ein Supply-Chain-Angriff auf eine Telefonie-Software, der Zehntausende Unternehmen traf.
Der gemeinsame Nenner: eine winzige, tief verschachtelte Abhängigkeit, der alle vertrauen und die niemand prüft. Der LiteLLM-Vorfall fügt diesem Muster eine neue Dimension hinzu — denn im KI-Zeitalter ist die kompromittierte Abhängigkeit nicht mehr irgendein Tool. Sie ist der Flaschenhals für Ihre vertraulichsten Daten.
Der entscheidende Unterschied
Ein kompromittierter Logger liest Log-Zeilen. Ein kompromittierter KI-Proxy liest Ihre Prompts — und ein Prompt enthält oft mehr vertrauliche Information als eine ganze Datenbank: Namen, Verträge, Strategien, Preise, unveröffentlichte Produkte.
Was das für den deutschen Mittelstand bedeutet
Der Mittelstand hat dieses Problem nicht als abstraktes Sicherheitsthema — sondern als konkretes Compliance-Problem. Drei DSGVO-Punkte werden bei einem solchen Vorfall sofort relevant:
- Art. 32 DSGVO (Sicherheit der Verarbeitung): Wer personenbezogene Daten durch eine ungeprüfte, kompromittierte Bibliothek schleust, hat den Stand der Technik nicht gewahrt. Das ist kein „Pech gehabt" — das ist ein Verstoß, den die Aufsichtsbehörde sanktioniert.
- Art. 33 DSGVO (Meldepflicht): Ein Prompt-Leak ist ein meldepflichtiger Datenschutzvorfall. Innerhalb von 72 Stunden. Mit allen Konsequenzen für Kundenvertrauen und Reputation.
- Art. 28 DSGVO (Auftragsverarbeitung): Wer Ihre Daten verarbeitet, muss vertraglich gebunden sein. Eine Bibliothek aus einem Paket-Register ist das sicher nicht.
Und genau hier liegt das Problem: Der Mittelstand adoptiert KI gerade in großem Tempo — oft über Cloud-APIs, geroutet durch Proxy-Bibliotheken, die niemand auditierte. Die eine Zeile Code, die das Modell anbindet, kann Jahre an Compliance-Arbeit in einer Sekunde zunichtemachen.
Die Antwort ist nicht ein besserer Scanner
Trivy hat diesen Vorfall entdeckt. SBOMs sind wichtig. Scanner sind notwendig — aber sie sind nicht hinreichend. Sie erkennen nur, was schon bekannt ist. Der nächste Angriff wird eine Schwachstelle nutzen, die noch in keiner Datenbank steht.
Die strukturelle Antwort ist eine andere: die Angriffsfläche verkleinern. Jede zusätzliche Bibliothek, jeder zusätzliche Proxy, jeder zusätzliche Hop zwischen Ihren Daten und dem Modell ist eine zusätzliche Tür, die offen steht. Weniger Schichten bedeuten weniger Einfallstore.
Konkret heißt das:
- Das Modell nah an die Daten holen. Wer auf eigener Hardware rechnet, braucht keinen öffentlichen Proxy, der Prompts durch das Internet schickt.
- Den Abhängigkeitsbaum minimieren. Eine schlanke, dokumentierte, auditierte Pipeline — statt eines Paket-Bergs aus Dutzenden ungeprüfter Bibliotheken.
- Die Lieferkette kontrollieren. Vom Container-Image bis zum Modell-Hash. Wer weiß, woraus sein Stack besteht, kann ihn auch absichern.
Das ist kein akademischer Ratschlag. Es ist die Haltung, mit der nAIce seit Tag eins baut: eigene Hardware, reduzierter Stack, vollständige Nachvollziehbarkeit der Lieferkette. Nicht weil es schick ist — sondern weil ein kompromittierter Proxy der schnellste Weg ist, das Vertrauen zu verlieren, für das man Jahre gearbeitet hat.
Was Sie jetzt tun sollten
Vier konkrete Schritte, die heute anfangen können — ohne dass Sie ein Security-Team einstellen müssen:
- Inventarisieren: Welche KI-Bibliotheken, Proxies und Gateways stecken in Ihrem Stack? Wer pflegt sie? Seit wann? Diese Liste existiert in den meisten Unternehmen schlicht nicht.
- SBOM erzwingen: Für jeden KI-Baustein — inklusive Modell-Version und Hash. Wer die Lieferkette nicht dokumentiert, kann sie nicht verteidigen.
- Least Privilege anwenden: Muss Ihr Proxy wirklich jeden Prompt sehen? Kann die KI lokal laufen statt in der Cloud? Je weniger Stellen Daten durchlaufen, desto weniger Stellen können leaken.
- Den Anbieter fragen: Routet Ihr KI-Partner Ihre Daten durch Drittanbieter-Bibliotheken, die Sie nicht sehen können? Wenn die Antwort „weiß ich nicht" lautet, ist das Ihre Antwort.
Die Kernfrage für jede Geschäftsführung
Nicht: „Wie gut ist unser KI-Modell?" Sondern: „Durch wie viele unsichtbare Hände laufen unsere Daten, bevor sie beim Modell ankommen — und wer prüft diese Hände?"
Fazit: Die falsche Schicht verteidigt
Der LiteLLM-Vorfall ist ein Warnschuss. Er zeigt, dass die Angreifer der KI-Ära nicht das Modell ins Visier nehmen — sie nehmen die Glue-Schicht ins Visier, den unsichtbaren Klebstoff zwischen Unternehmen und Modell. Wer „KI-Sicherheit" mit „Modell-Sicherheit" übersetzt, verteidigt die falsche Schicht.
Der deutsche Mittelstand hat einen Vorteil, den er nutzen sollte: Er steht noch am Anfang. Die Abhängigkeitsbäume sind noch nicht zementiert. Die Architektur ist noch nicht auf drei Cloud-Anbieter und sieben Proxy-Bibliotheken verteilt. Wer jetzt auf eine schlanke, selbstgehostete, auditierbare Architektur setzt, baut sich einen strukturellen Vorsprung, den später niemand mehr aufholen kann — weil der Umbau dann teurer ist als der Neubau.
Die gute Nachricht: Der Angriff wurde entdeckt. Die schlechte: Er war kein Ausreißer, sondern ein Muster. Die eigentliche Frage ist nicht, ob der nächste kommt — sondern ob Ihre Lieferkette ihm standhält.
Weiterführend: Warum die KI-Vertrauenskrise 2026 selbstgehosteten Agenten in die Karten spielt, lesen Sie in unserem Artikel „Warum die KI-Vertrauenskrise 2026 nAIce's Stunde schlägt" — und warum DSGVO-konforme KI-Agenten eigene Hardware voraussetzen, im Praxisleitfaden für deutsche KMU.