Ein KI-System absichern heißt die Architektur absichern — nicht nur das Modell
Die meisten Diskussionen über KI-Sicherheit drehen sich um das Modell: Jailbreaks, Prompt Injection, Halluzinationen. Dieser Raum hat meinen Blick verschoben — auf etwas Größeres und für Unternehmen Wichtigeres: Ein produktives KI-System ist kein Modell, sondern eine Architektur aus vielen Komponenten. Und jede Komponente ist eine potenzielle Schwachstelle, die klassische Sicherheitswerkzeuge gar nicht im Blick haben.
1. Der entscheidende Unterschied: von strukturiert zu unstrukturiert
Eine klassische Web-App ist berechenbar: Eingaben fließen von der Oberfläche über die API in die Datenbank und zurück. Sicherheitsteams wissen genau, wo sie Kontrollen platzieren. Kommt eine KI-Komponente dazu, ändert sich das Bild grundlegend:
- Eingabe: früher strukturierte Formulare/Parameter → jetzt freie natürliche Sprache
- Verarbeitung: früher deterministischer Code → jetzt probabilistische Modell-Inferenz
- Datenzugriff: früher direkte DB-Abfragen → jetzt modellvermittelter Abruf (RAG)
- Ausgabe: früher Template-Antworten → jetzt generierte natürliche Sprache
Der Sprung von strukturierter zu unstrukturierter Eingabe ist die folgenreichste Änderung. Ein klassisches Eingabefeld erwartet ein Datum, eine Zahl, eine Auswahl. Ein KI-System akzeptiert jeden beliebigen Text. Das allein entwertet die meisten bestehenden Eingabe-Validierungs-Strategien.
2. Die „Chatbox-Iceberg": neun Komponenten, fünf Vertrauensgrenzen
Der Nutzer sieht nur eine Chatbox. Der Sicherheitsarchitekt sieht das Fundament darunter: User Interface, API-Gateway, Orchestrierungsschicht, Prompt-Konstruktion, das LLM, einen Tool-Layer, Output-Processing, Logging/Monitoring und einen Vektorspeicher (RAG). Neun Komponenten — und dazwischen fünf Vertrauensgrenzen, an denen Daten von einem Sicherheitskontext in den nächsten übergehen. Jede ist eine Angriffsfläche:
- User → System: nicht vertrauenswürdige natürliche Sprache betritt das System
- System → LLM: der zusammengebaute Prompt (System-Anweisung + Eingabe + Kontext) geht ans Modell
- LLM → Tools: Modell-Output löst DB-Abfragen, API-Calls oder Dateioperationen aus
- System → externe Daten: abgerufene Dokumente (Vektorspeicher/extern) fließen in den Prompt
- System → User: die generierte Antwort wird ausgeliefert
Die Kernfrage eines Audits lautet damit nicht „ist das Modell sicher?", sondern: Welche dieser Grenzen haben Kontrollen — und welche sind ungeschützt?
3. Die fünf systemischen Bedrohungen — je Grenze eine
Genau an diesen Grenzen setzen fünf Bedrohungsklassen aus den OWASP LLM Top 10 (2025) an:
- Unbounded Consumption (LLM10) — unbegrenzte Anfragen → Kosten-/Ressourcen-Missbrauch (Grenze User→System)
- System Prompt Leakage (LLM07) — der System-Prompt (samt Geheimnissen) wird ausgeplaudert
- Improper Output Handling (LLM05) — ungeprüfter Modell-Output richtet im Backend Schaden an (z. B. SQL-Injection an der Grenze LLM→Tools)
- Excessive Agency (LLM06) — das Modell darf zu viel (zu weitreichende Tool-/Aktionsrechte)
- Sensitive Information Disclosure (LLM02) — sensible Daten lecken (z. B. ungefilterte Logs)
Das gemeinsame Vokabular dafür liefern drei Frameworks, die zusammengehören: OWASP LLM Top 10 (die Risiken), MITRE ATLAS (die Angreifer-Techniken) und NIST AI RMF (die organisatorische Antwort).
4. Wie das in echt aussieht: ein über-privilegierter Assistent
Im praktischen Teil habe ich einen KI-Assistenten „interviewt" — und er hat freiwillig
offengelegt, wie gefährlich seine Konfiguration war: voller db_admin-Zugriff
(inklusive DROP/DELETE) auf die Produktionsdatenbank, automatisches Mergen von
Pull Requests ohne menschliche Freigabe, Lese-/Schreibzugriff auf alle
Slack-Channels, und Logging aller Gespräche ohne PII-Filterung.
Das ist Excessive Agency und Sensitive Information Disclosure zum Anfassen. Wie ein gekaperter Assistent so etwas in einem realen Angriff ausnutzt, habe ich im Fall West Tech durchgespielt — dort wurde genau so eine Architektur zum Einfallstor.
5. Die Verteidigung: vier Prinzipien
Die gute Nachricht: Man kann diese Systeme absichern — aber nicht mit einem einzelnen Werkzeug, sondern mit Prinzipien an jeder Grenze:
- Defense-in-Depth — Kontrollen an jeder Vertrauensgrenze, nicht nur am Eingang
- Least Privilege je Komponente — jede Komponente bekommt nur die minimal nötigen Rechte (der Tool-Layer braucht keinen
db_admin!) - Input- und Output-Validierung an jedem Übergang — Modell-Output wie Benutzereingabe behandeln
- MLSecOps-Monitoring — durchgängige Überwachung des gesamten Systems
Mein Fazit
Zwei Erkenntnisse nehme ich mit. Erstens: Sicherheit muss von Anfang an mitgebaut werden (Security by Design) — sie nachträglich aufzusetzen, wenn die Architektur schon steht, ist viel teurer und lückenhaft. Zweitens: Rechte und Tool-Zugriffe nur so weit vergeben, wie sie wirklich gebraucht werden — Least Privilege ist der wirksamste einzelne Hebel, weil er den Schaden begrenzt, wenn (nicht falls) das Modell manipuliert wird.
Die übergeordnete Wahrheit: Klassische Anwendungssicherheit ist notwendig, aber nicht ausreichend. Firewalls, WAFs und Input-Sanitization fangen die neuen Komponenten — LLM, Tool-Layer, Prompt-Konstruktion, Vektorspeicher — nicht ab. Ein KI-System abzusichern heißt, die Architektur abzusichern, nicht nur das Modell. Genau dort setze ich mit meinen Audits an.