Welche Sicherheitsrisiken haben LLM-Anwendungen und wie schützt man sie?
Direkte Antwort
Die häufigsten Sicherheitsrisiken bei LLM-Anwendungen entsprechen weitgehend der OWASP-Top-10-Liste für LLM-Anwendungen: Prompt Injection (LLM01, manipulierte Eingaben verändern das Modellverhalten), unsichere Ausführung von Tool-Aufrufen ohne ausreichende Validierung (Excessive Agency, LLM08), und ungewollte Preisgabe sensibler Daten über Kontext oder Antwort (Sensitive Information Disclosure, LLM02). Der wirksamste Schutz kombiniert Eingabevalidierung, Prinzip der geringsten Berechtigung für Tool-Zugriffe und explizite Trennung von vertrauenswürdigen und nicht vertrauenswürdigen Eingabequellen — keine dieser Maßnahmen macht Prompt Injection vollständig unmöglich, sie reduzieren nur die Angriffsfläche und die Auswirkung eines erfolgreichen Angriffs.
"Bei klassischer Software ist Eingabevalidierung eine Frage der Datenformate. Bei einem LLM kann jede Eingabe potenziell die Anweisungen des Systems selbst überschreiben.
LLM-Anwendungen bringen eine neue Klasse von Sicherheitsrisiken mit, die sich mit klassischem Secure-Coding-Wissen allein nicht vollständig abdecken lassen, weil die Eingabe selbst das Verhalten des Systems verändern kann.
Prompt Injection als grundlegend neues Risiko
Anders als bei klassischen Injection-Angriffen (SQL, XSS) lässt sich Prompt Injection nicht durch einfaches Escapen von Sonderzeichen verhindern, weil die Grenze zwischen "Anweisung" und "Daten" für ein Sprachmodell nicht immer eindeutig ist.
Ein wirksamer Schutzansatz ist die klare Trennung von System-Prompt und Nutzereingabe in der API-Struktur, ergänzt um Erkennungsmechanismen für verdächtige Eingabemuster und, wo möglich, ein separates Prüfmodell, das eingehende Anfragen vor der Verarbeitung klassifiziert.
Unsichere Tool-Ausführung als praktisches Risiko in Agenten-Systemen
Wenn ein LLM-Agent Zugriff auf Tools mit realen Auswirkungen hat (Datenbankzugriff, Dateisystem, externe APIs), kann eine erfolgreiche Prompt Injection dazu führen, dass diese Tools mit schädlichen Parametern aufgerufen werden.
Das Prinzip der geringsten Berechtigung ist hier entscheidend — jedes Tool sollte nur die minimal notwendigen Rechte haben, und folgenreiche Aktionen (Löschen, Zahlungen, externe Kommunikation) sollten eine zusätzliche Bestätigung außerhalb des reinen Modellverhaltens erfordern.
Datenlecks über Kontext und Antwort
Ein LLM kann sensible Informationen aus dem bereitgestellten Kontext (etwa RAG-Dokumenten) unbeabsichtigt in einer Antwort preisgeben, wenn Zugriffskontrollen nicht bereits auf Ebene der Dokumentenauswahl greifen, sondern erst nachträglich versucht wird, die Antwort zu filtern.
Zugriffsrechte sollten deshalb bereits beim Retrieval durchgesetzt werden — ein Nutzer sollte nie Dokumente in den Kontext bekommen, auf die er ohnehin keinen Zugriff haben dürfte, statt sich allein auf nachträgliche Ausgabefilterung zu verlassen.
Wann passt es — wann nicht?
Passt gut
- ✓Der Agent hat Zugriff auf Tools mit realen Auswirkungen oder verarbeitet Dokumente mit unterschiedlichen Zugriffsebenen
Passt nicht
- ✗Das System ist rein informativ ohne Tool-Zugriff und ohne zugriffsbeschränkte Dokumente