KI-Security: die Trust-Grenzen eines LLM-Systems
Einführung · 10 Abschnitte · ~8 Min Lesezeit · Stand
Die Angriffsfläche eines LLM-Systems
Ein LLM folgt Anweisungen aus jeder Eingabe, die in seinen Kontext gelangt — es unterscheidet nicht zuverlässig zwischen „Daten“ und „Befehl“. Im RAG-/Agenten-Setup kommt Eingabe aus mehreren Quellen: dem Nutzer, retrievten Dokumenten und Tool-Ausgaben.
- Nutzer
- Retrievte Docs
- Tool-Ausgaben
Damit verschwimmt die Trust-Grenze. Sicherheit heißt hier nicht „ein Filter“, sondern: klare Vertrauensgrenzen ziehen und an jeder Schicht verteidigen.
Prompt Injection: direkt, indirekt — und der Prompt als „öffentlich“
Direkte Injection: der Nutzer manipuliert den Prompt selbst („ignoriere deine Anweisungen …“). Indirekte Injection: die Anweisung steckt in retrievtem oder externem Inhalt — die gefährlichere Variante, weil der Angreifer nie direkt mit euch reden muss.
Zentrale Konsequenz: Die Prompt-Ebene ist keine Sicherheitsgrenze. Anweisungen lassen sich überschreiben, und der System-Prompt lässt sich oft extrahieren (System Prompt Leakage). Entwirf so, dass selbst ein vollständig überschriebener oder ausgelesener Prompt keinen Schaden anrichtet.
Excessive Agency: Least-Privilege für Tools & Agenten
Injection wird erst gefährlich, wenn das kompromittierte Modell mächtige Tools hat — DB-Zugriff, E-Mail, Shell. Der Schaden ist so groß wie die Rechte des Agenten.
Antwort: Least-Privilege. Jedes Tool nur mit minimalen Rechten, Allowlists statt Blocklists, Human-in-the-Loop für irreversible Aktionen. Ein reiner Lese-Job bekommt keine Lösch-Berechtigung.
Ausgabe: Improper Output Handling
LLM-Ausgaben sind ebenfalls untrusted. Wer Modell-Output ungefiltert in Shell, SQL, HTML oder einen Downstream-Aufruf gibt, baut die Injection-Lücke am anderen Ende wieder ein.
| Eingang (retrievt/Nutzer) | untrusted → filtern, Least-Privilege |
|---|---|
| Ausgang (ausführen/rendern) | untrusted → validieren, encodieren, Allowlist |
Datenschutz: PII & besondere Kategorien
Datenschutz ist eine Eigenschaft des Datenflusses, nicht der Nutzer: sobald personenbezogene Daten an einen (externen) Verarbeiter gehen, zählen Rechtsgrundlage und Datenminimierung — auch bei rein interner Nutzung.
Besondere Kategorien (Art. 9 DSGVO, u. a. Gesundheitsdaten) verschärfen das: explizite Rechtsgrundlage, PII vor der Übermittlung redigieren, Logging- und Aufbewahrungsdauer festlegen.
Daten- & Index-Poisoning
Retrieval erbt das Vertrauen seiner Quellen. Indexiert ihr eine nicht kuratierte, editierbare Quelle, kann ein Angreifer präparierte Inhalte einschleusen, die eure Antworten verfälschen (Data/Index Poisoning).
Secrets in Prompts & Logs
Zwei häufige Leak-Kanäle: Secrets im System-Prompt (extrahierbar) und Prompt-/Antwort-Logs, die PII und Tokens breit einsehbar speichern. Observability darf keine neue Leak-Quelle schaffen.
Resource Abuse: Kosten- & Verfügbarkeits-DoS
Ein KI-Endpoint ist eine kostenverursachende Ressource. Ohne Grenzen skaliert Missbrauch direkt in explodierende Kosten und Timeouts für legitime Nutzer (Unbounded Consumption).
Supply Chain: Modelle & Plugins
Modelle, Plugins und Abhängigkeiten sind Teil eurer Lieferkette — sie können manipuliert sein, exzessive Rechte fordern oder Daten abfließen lassen. „Open Source“ oder „viele Sterne“ ist kein Integritätsbeweis.
Defense in Depth — gleich im Check
Kein einzelner Filter ist sicher — Guardrails lassen sich umgehen. Sicherheit entsteht durch Schichten: Input-Guardrails, Least-Privilege, Output-Validierung, Datenminimierung, Quellen-Kuratierung, Limits und Monitoring. Keine Schicht vertraut der anderen blind.