LLM-Sicherheit

Warum LLM-Sicherheit eine eigenständige Disziplin ist

Große Sprachmodelle bringen Sicherheitseigenschaften mit, die in der konventionellen Anwendungssicherheit nicht auftreten:

• Prompt als Angriffsfläche: Die natürlichsprachliche Eingabe an ein LLM ist zugleich der primäre Angriffsvektor. Böswillige Eingaben können Modelle dazu bringen, Trainingsdaten preiszugeben, schädliche Inhalte zu erzeugen, Anweisungen zu umgehen oder Informationen zu exfiltrieren — ohne irgendeine Schwachstelle auf Code-Ebene auszunutzen.
• Opake Schlussfolgerung: Anders als eine deterministische API schlussfolgert ein LLM über seine Eingabe auf Weisen, die sich allein aus der Ausgabe nicht vollständig prüfen lassen. Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen; derselbe Angriff kann in einer Sitzung gelingen und in einer anderen scheitern.
• Indirekte Eingabequellen: Anwendungen, die externe Inhalte abrufen — Webseiten, Dokumente, E-Mails — und sie einem LLM übergeben, schaffen einen Pfad, über den adversariale Inhalte das Verhalten des Modells beeinflussen, selbst wenn das Modell selbst nicht das direkte Ziel des Angriffs ist.
• Multi-Tenant-Exposition: Organisationen, die LLMs auf gemeinsam genutzter Infrastruktur betreiben, können Prompt-Injection-Angriffen, Daten-Kreuzkontamination oder Leakage zur Inferenzzeit über Nutzersitzungen hinweg ausgesetzt sein.

Die Kern-Bedrohungskategorien in der LLM-Sicherheit

Prompt Injection

Prompt Injection ist die führende LLM-Sicherheitsbedrohung und steht in den OWASP LLM Top 10 an erster Stelle. Ein Angreifer bettet böswillige Anweisungen in Inhalte ein, die das Modell verarbeitet — ein Dokument, eine E-Mail oder eine abgerufene Webseite —, wodurch das Modell diesen Anweisungen statt seiner ursprünglichen Aufgabe folgt. Direkte Prompt Injection kommt vom Nutzer; indirekte Prompt Injection ist in externe Inhalte eingebettet, die das Modell autonom abruft.

Extraktion von Trainingsdaten

LLMs können dazu gebracht werden, memorierte Trainingsdaten zu reproduzieren, darunter personenbezogene Daten, urheberrechtlich geschützter Text oder vertrauliche Inhalte aus dem Trainingskorpus. Extraktionsangriffe nutzen sorgfältig gestaltete Prompts, die darauf ausgelegt sind, memoriertes Material zutage zu fördern, und sind besonders relevant für Modelle, die auf proprietären oder regulierten Datensätzen feinabgestimmt wurden.

Unsichere Ausgabeverarbeitung

LLMs, die mit nachgelagerten Systemen integriert sind — Code-Interpreter, Webbrowser, Datenbankschnittstellen —, können Ausgaben erzeugen, die ohne ordnungsgemäße Validierung als Code oder Abfragen ausgeführt werden. LLM-generierte Inhalte, die unbereinigt einen Browser erreichen, können Cross-Site-Scripting (XSS) auslösen; Inhalte, die ohne Validierung an eine Datenbankschnittstelle übergeben werden, können Injection-Angriffe ermöglichen.

Datenlecks über das Kontextfenster

In Retrieval-Augmented-Generation-(RAG-)Systemen und mehrstufigen Konversationen können sensible Dokumente im Kontextfenster des Modells verbleiben und versehentlich in späteren Antworten zutage treten. Ohne Sitzungsisolierung und Kontextgrenzen-Kontrollen können die sensiblen Daten eines Nutzers in der Sitzung eines anderen auftauchen.

Modellinversion und Membership Inference

Modellinversionsangriffe versuchen, sensible Eigenschaften von Trainingsdaten aus Modell-Ausgaben zu rekonstruieren. Membership-Inference-Angriffe bestimmen, ob eine bestimmte Datenprobe im Training enthalten war. Beide sind relevant für Organisationen, die Modelle auf internen oder regulierten Datensätzen feinabstimmen.

LLM-Sicherheit vs. AI-Agenten-Sicherheit

LLM-Sicherheit und AI-Agenten-Sicherheit sind verwandte, aber eigenständige Disziplinen:

Agentisches AI-Risiko baut auf der LLM-Sicherheit auf: Ein Agent, der anfällig für Prompt Injection ist und realen Tool-Zugriff hat, ist eine Bedrohung von deutlich höherem Schweregrad als ein LLM, das Fragen isoliert beantwortet.

Wie LLM-Sicherheitskontrollen funktionieren

LLM-Sicherheitskontrollen wirken auf mehreren Ebenen des Anwendungsstacks:

Eingabekontrollen

• Prompt-Bereinigung: Nutzereingaben und abgerufene Inhalte auf bekannte Prompt-Injection-Muster prüfen, bevor sie an das Modell weitergeleitet werden.
• Schutz des System-Prompts: Den System-Prompt als Sicherheitsgrenze behandeln; ihn nicht in Fehlermeldungen offenlegen und nicht zulassen, dass Nutzereingaben ihn übersteuern.
• Durchsetzung des Eingabeschemas: Eingaben, wo möglich, auf erwartete Formate beschränken, um die Angriffsfläche für adversariale Manipulation zu verringern.

Ausgabekontrollen

• Scannen auf PII und sensible Daten: Modell-Ausgaben scannen, bevor sie an Nutzer zurückgegeben oder an nachgelagerte Systeme übergeben werden.
• Validierung des Ausgabeschemas: Wo Modelle strukturierte Ausgaben (JSON, Code) erzeugen, vor der Ausführung gegen ein striktes Schema validieren.
• Durchsetzung der Inhaltsrichtlinie: Ausgaben auf der Infrastrukturebene auf Richtlinienverstöße filtern, unabhängig vom Safety-Training des Modells.

Zugriffskontrollen

• Datenzugriff nach Least Privilege: Die Daten, die ein Modell in RAG-Konfigurationen abrufen kann, auf das für den Autorisierungsbereich des aktuellen Nutzers erforderliche Minimum beschränken.
• Sitzungsisolierung: Sicherstellen, dass Konversationskontext und abgerufene Dokumente nicht über Nutzersitzungen hinweg fortbestehen.
• Beschränkung von Anmeldedaten: Für Modelle mit Tool-Zugriff sitzungsgebundene Anmeldedaten statt langlebiger Dienstkonto-Schlüssel ausgeben.

Audit und Observability

• Ein manipulationssicheres Protokoll jeder LLM-Interaktion führen: die Eingabe, das verwendete Modell, die Ausgabe und alle angewandten Richtlinienentscheidungen.
• Für RAG-Systeme abgerufene Dokumente neben der Abfrage protokollieren, sodass der Kontext jeder Antwort für die Compliance-Prüfung rekonstruiert werden kann.