Alle bauen mit KI. Fast niemand schützt sie.

Das Muster ist dasselbe, das wir schon 2008 bei Web-Apps und 2014 bei Mobile erlebt haben. Eine neue Fähigkeit kommt, Teams liefern so schnell wie möglich, um den Vorteil zu nutzen, und das Sicherheitsmodell hinkt mehrere Quartale hinterher. Diesmal ist die Verzögerung schlimmer, weil „das Modell“ selbst ein bewegliches Ziel ist und der Orchestrierungscode, der es umschließt, sich jede Woche ändert.

Dies ist ein Rundgang durch die tatsächlichen Vorfälle, die wir in den letzten zwölf Monaten in produktiven KI-Deployments gesehen haben, geordnet nach Angriffsfläche. Es geht nicht darum, Sie vom Ausliefern von KI-Features abzuschrecken. Es geht darum, die Fläche so sichtbar zu machen, dass Sie sie verteidigen können.

1. Die Orchestrierungsschicht ist die eigentliche Angriffsfläche

Die meisten „KI-Anwendungen“ bestehen zu 5 % aus Modell und zu 95 % aus Klebstoff: API-Aufrufe an ein gehostetes Modell, eine Prompt-Vorlage, ein Retrieval-Schritt gegen eine Vektordatenbank, etwas Nachbearbeitung der Ausgabe und eine gestreamte Antwort zurück an den Nutzer. Jede Zeile dieses Klebstoffs ist reguläres Python oder TypeScript, und jede klassische Schwachstelle gilt weiterhin.

Wir sehen immer wieder dieselben fünf Probleme:

• Fest eincodierte Inferenz-Schlüssel. OPENAI_API_KEY in ein öffentliches Repository committed oder in einen Slack-Kanal eingefügt, der mit einer Drittanbieter-Automatisierung integriert ist. Nach dem Leak kann ein Angreifer Inferenz auf Ihre Kosten ausführen und (schlimmer noch) den Inhalt jedes festgehaltenen Kontexts lesen.
• Server-Side Request Forgery aus Tool-Use-Schleifen. Wenn Ihr Modell URLs aufrufen kann („hole den neuesten Artikel von diesem Link“) und Sie diese URLs nicht per Allowlist einschränken, ruft das Modell bei entsprechender Aufforderung gerne http://169.254.169.254/latest/meta-data/ ab.
• Vektordatenbank dem öffentlichen Internet ausgesetzt. Qdrant, Pinecone, Weaviate: alles hervorragend, alles routinemäßig ohne Authentifizierung deployed, weil „es hinter der API liegt“. Wir haben unauthentifizierte Indizes gefunden, die komplette Kundensupport-Archive enthalten.
• Streaming-Antwort-Logs mit personenbezogenen Daten. Wenn das Modell Nutzereingaben wiedergibt und Ihr Observability-Stack die Antwort wörtlich protokolliert, speichern Sie jetzt personenbezogene Daten in Datadog. Ohne AVV. Wahrscheinlich ohne Einwilligung.
• Veraltete Versionen von transformers oder langchain. Beide haben 2025 CVEs veröffentlicht, die Remote Code Execution über manipulierte Modelldateien ermöglichten. Beide sind routinemäßig auf „was main war, als wir angefangen haben“ gepinnt.

2. Prompt Injection ist das neue SQL Injection

Die Einordnung ist exakt dieselbe: Nicht vertrauenswürdige Eingaben werden in eine sensible Operation eingefügt, und das zugrunde liegende System kann „Anweisungen vom Entwickler“ nicht von „Anweisungen vom Nutzer“ unterscheiden. Der Fix ist derselbe: Trennung der Kanäle, Parametrisierung und niemals darauf vertrauen, dass das Modell seine eigene Policy durchsetzt.

„Wir gingen davon aus, dass unser System-Prompt den Kontakt mit dem Nutzer übersteht. Er überstand etwa vier Minuten nach dem Launch.“ Engineering-Post-Mortem, Fintech-Kunde, März 2026

Konkrete Fixes, die funktionieren:

1. Nutzen Sie die Rollentrennung des Modellanbieters korrekt. System-Prompts gehören in das Feld system, niemals in user eingefügt. Vom Kunden gelieferte Eingaben werden immer zitiert, als nicht vertrauenswürdig markiert und begrenzt.
2. Schränken Sie Tool-Nutzung mit expliziten Allowlists ein. Wenn das Modell Funktionen aufrufen kann, deklarieren Sie die Menge, validieren Sie jedes Argument und lassen Sie das Modell niemals entscheiden, welchen Endpunkt es anspricht.
3. Fügen Sie einen Guardrail-Pass hinzu. Ein kleiner Klassifikator zwischen der Modellausgabe und dem Nutzer, der offensichtliche Leaks filtert (personenbezogene Daten, Zugangsdaten, System-Prompt-Fragmente). Er ist unvollkommen; er fängt die meisten Fälle ab.
4. Rate-Limiting für Prompt-Länge und Tool-Call-Tiefe. Die meisten Jailbreaks nutzen lange, rekursive Prompts. Eine einfache Obergrenze schlägt 80 % davon.

3. Supply Chain: Wenn das Modell selbst zur Schwachstelle wird

Vortrainierte Modellgewichte, verteilt als .bin- oder .safetensors-Dateien, sind Code. Der Deserialisierungsschritt in PyTorch kann beliebiges Python ausführen. Hugging Face weist darauf hin, aber Mitte 2025 gab es mindestens vier öffentliche Vorfälle, in denen ein beliebtes Community-Modell eine manipulierte Gewichtsdatei enthielt, die beim Laden einen Cryptominer herunterlud.

Die Abhilfe ist identisch mit dem, was wir für npm-Pakete tun:

• Versionen pinnen. Niemals „latest“.
• Prüfsummen gegen eine vertrauenswürdige Quelle verifizieren.
• Den Loader sandboxen. Wenn Sie ein Modell in Produktion laden, sollte der ladende Prozess keine Zugangsdaten zu Ihrem Datenspeicher haben.
• Advisory-Feeds für die Model-Hubs abonnieren, die Sie nutzen.

4. Der Compliance-Aspekt, über den kaum jemand spricht

DSGVO Artikel 22 regelt automatisierte Entscheidungsfindung. Der EU AI Act betrifft Hochrisiko-Systeme. NIS2 betrifft Betriebstechnik. Die meisten Teams, die KI-Features ausliefern, haben nicht abgebildet, welche Regelwerke auf sie zutreffen.

Eine kurze Heuristik: Wenn Ihre KI-Ausgabe den Zugang eines Kunden zu einem Service, einen Preis, den er zahlt, oder eine Entscheidung über ihn wesentlich beeinflusst, fallen Sie wahrscheinlich unter mindestens eines davon. Der Dokumentationsaufwand für „hier nutzen wir KI“ ist nicht länger null.

5. Was Sie diese Woche tun sollten

1. Durchsuchen Sie Ihre Repos nach fest eincodierten Inferenz-Schlüsseln. Es ist mindestens einer dabei.
2. Prüfen Sie, welche Modellbibliotheken Sie tatsächlich nutzen, und pinnen Sie sie. requirements.txt mit ==, nicht >=.
3. Stellen Sie jede Vektordatenbank hinter Ihre VPC. Hat sie eine öffentliche IP, sollte sie das nicht.
4. Notieren Sie, welche KI-Features unter welche Regelung fallen. Selbst eine einseitige Tabelle ist mehr, als die meisten Teams haben.
5. Behandeln Sie Ihren Prompt wie Code. Versionieren Sie ihn, testen Sie ihn und gehen Sie davon aus, dass er geleakt wird.

KI ist nicht magisch gefährlich, aber sie ist konventionell gefährlich auf Arten, die Teams noch nicht verinnerlicht haben. Die Abwehrmaßnahmen sind dieselben langweiligen, die bei der vorherigen Welle funktioniert haben: Inventar, Patchen, Trennung von Privilegien, Secret Hygiene. Wenn Sie diese vier Dinge konsequent tun, gehören Sie zum oberen Quartil.