LLM-Sicherheit: So schützen Sie sich vor Prompt-Injection und versteckten Angriffen

LLMs verarbeiten alle Eingaben als eine einzige Folge von Tokens: Systemanweisungen, Nutzertexte und abgerufene Daten sind für die KI nicht unterscheidbar. Diese Eigenschaft macht sie anfällig für Prompt-Injection-Angriffe. Dabei wird böswillig platzierter Text vom Modell als Anweisung interpretiert, statt als Daten. Ein wirksamer Schutz erfordert mehr als nur Filterregeln – er basiert auf einer mehrstufigen Strategie.

Warum einfache Filter oft nutzlos sind

Die naheliegendste Reaktion auf Prompt-Injection besteht darin, verdächtige Begriffe im Nutzerprompt zu blockieren. Doch dieser Ansatz scheitert schnell:

• Blocklisten sind leicht zu umgehen: Angreifer nutzen Synonyme, Tippfehler, Leetspeak oder fremdsprachliche Formulierungen.
• Semantische Filter sind effektiver: Statt einzelne Wörter zu verbieten, sollte die Absicht hinter der Eingabe klassifiziert werden.
• Risikominimierung durch Datenmanagement: Sensible Informationen gehören nicht in den Kontext des Modells – dort sind sie potenziell auslesbar.

Ein häufiger Fehler ist die alleinige Abhängigkeit von Eingabefiltern. Selbst wenn der Nutzerprompt bereinigt wird, können versteckte Zeichen oder verschleierte Anweisungen die KI umgehen. Filter müssen daher als letzte Verteidigungslinie betrachtet werden – niemals als primäre Sicherheitsmaßnahme.

Die sieben Schichten der LLM-Verteidigung – und ihre Schwachstellen

Eine robuste Sicherheitsarchitektur kombiniert mehrere Schutzmechanismen. Jede Schicht hat jedoch ihre eigenen Grenzen:

1. Keine oder schwache Guardrails

Modelle ohne Sicherheitsvorgaben geben alles preis, was in ihrem Kontext steht. Besonders riskant wird es, wenn vertrauliche Daten – wie API-Schlüssel oder Passwörter – Teil des Systemprompts sind.

2. Eingabefilterung durch Schlüsselwortprüfung

Ein einfacher Ansatz besteht darin, verbotene Begriffe wie "Code", "Geheimnis" oder „Offenlegen" zu blockieren. Doch diese Methode ist leicht zu umgehen:

• Nutzer verwenden alternative Formulierungen oder verschleiern ihre Absichten.
• Die Filterung von Strings ignoriert die eigentliche Intention hinter der Eingabe.

Ein besserer Weg ist die Nutzung von Erlaubnislists, die nur explizit freigegebene Eingaben zulassen. Zusätzlich sollte jede Eingabe als potenziell gefährlich behandelt werden – mit Ratenbegrenzung und Protokollierung verdächtiger Anfragen.

3. Ausgabefilterung durch Mustererkennung

Hier wird die Antwort des Modells auf verbotene Begriffe oder sensible Daten überprüft. Doch auch dieser Mechanismus hat gravierende Lücken:

• Fragmentierte Geheimnisse werden nicht erkannt, wenn sie in Teilen ausgegeben werden.
• Codierte oder umgewandelte Daten (z. B. Base64 oder durch Trennzeichen getrennte Zeichenfolgen) entziehen sich der einfachen Textsuche.

Die beste Praxis ist, sensible Daten erst gar nicht in den Kontext des Modells aufzunehmen. Ausgabefilter sollten nur als letzte Sicherheitsstufe dienen – nicht als Hauptverteidigungslinie.

4. Kombinierte Eingabe- und Ausgabefilterung

Durch das Stapeln beider Filter kann die Hürde für Angreifer erhöht werden. Doch die Schwächen beider Ansätze summieren sich:

• Ein Angreifer umgeht den Eingabefilter durch Verschleierung.
• Die Ausgabefilterung scheitert an fragmentierten oder codierten Daten.

Mehr Filter bedeuten nicht automatisch mehr Sicherheit. Stattdessen sollte der Fokus auf intelligenten, semantischen Prüfmechanismen liegen.

5. Automatische Prüfung durch ein zweites LLM

Ein separates Modell analysiert die Antwort und blockiert sie, wenn es sensible Inhalte erkennt. Doch auch dieser Ansatz ist nicht narrensicher:

• Soziale Manipulation kann den Prüfer täuschen. Beispiel: Ein Angreifer behauptet, ein Code-Snippet sei veraltet und harmlos – das LLM glaubt ihm.
• Lücken in der Erkennung bleiben bestehen, wenn das Prüfer-Modell bestimmte Codierungsformen nicht versteht.

Die Kombination aus automatischer Prüfung und deterministischen Regeln ist effektiver. Zudem sollte der Zugriff des Hauptmodells auf sensible Daten stark eingeschränkt werden.

6. Manuelle Überprüfung durch Menschen

Ein menschlicher Prüfer soll verdächtige Antworten filtern. Doch dieser Ansatz hat eine fundamentale Schwäche:

• ASCII-Smuggling nutzt die Diskrepanz zwischen sichtbarem Text (was der Mensch liest) und rohem Datenstrom (was das Modell verarbeitet). Versteckte Zeichen bleiben für den Menschen unsichtbar, werden vom Modell aber interpretiert.

Sicherheit darf sich nicht auf die manuelle Überprüfung von gerendertem Text verlassen. Stattdessen muss der rohe Eingabestrom vor der Verarbeitung durch Mensch oder Maschine bereinigt werden.

Deep Dive: ASCII-Smuggling – Der unsichtbare Angriffsvektor

Ein besonders tückischer Angriff nutzt die Unterschiede zwischen Darstellung und Datenverarbeitung. Bestimmte Unicode-Zeichen sind für den Menschen unsichtbar, werden vom LLM aber als Tokens verarbeitet. Dadurch können versteckte Anweisungen oder sensible Daten eingeschleust werden.

Die wichtigsten unsichtbaren Zeichen:

• Unicode-Tags-Block (U+E0000–U+E007F): Veraltete Steuerzeichen, die in fast allen Renderern unsichtbar bleiben.
• Nullbreite-Zeichen: Dazu gehören ZWSP (U+200B), ZWNJ (U+200C), ZWJ (U+200D) und BOM/ZEICHEN (U+FEFF).
• Bidirektionale Steuerzeichen (U+202A–U+202E, U+2066–U+2069): Diese Zeichen können die logische Reihenfolge von Text verändern – bekannt aus dem „Trojan Source“-Angriff.

Warum dieser Angriff heute besonders gefährlich ist

LLMs sind in zahlreiche Anwendungen integriert, darunter E-Mail-Clients, Kalender-Apps, Dokumentenmanagementsysteme und RAG-Pipelines. Dokumentierte Vorfälle (FireTail, September 2025) zeigen das Ausmaß der Bedrohung:

• Identitätstäuschung: Ein manipulierter Kalendereintrag enthält versteckte Anweisungen, die die Organisator-Information ändern. Das LLM liest die gefälschte Identität, obwohl der Nutzer die Einladung nie angenommen hat.
• Autonome Datenexfiltration: Eine versteckte Anweisung in einer E-Mail weist einen E-Mail-Assistenten an, sensible Daten zu suchen und weiterzugeben.
• Inhaltsvergiftung: Eine Produktbewertung enthält versteckte Werbung für eine betrügerische Website. Die Zusammenfassung des LLMs gibt diesen Hinweis als vermeintliche Kundenmeinung aus.

Betroffen waren laut Tests Modelle wie Gemini, Grok und DeepSeek, während ChatGPT, Copilot und Claude die versteckten Zeichen erkannten und bereinigten.

So schützen Sie sich effektiv

Der Schlüssel liegt in der Anwendungslogik, nicht im Modell selbst:

1. Rohdaten bereinigen: Untersuchen Sie den unverarbeiteten Datenstrom, der das Modell erreicht – nicht den gerenderten Text.
2. Unicode normalisieren: Entfernen Sie Tags-Block, Nullbreite- und Steuerzeichen. Eine NFKC-Normalisierung hilft, verschiedene Darstellungen desselben Zeichens zu vereinheitlichen.
3. Erlaubnislists statt Verbotslisten: Legen Sie fest, welche Unicode-Kategorien zugelassen sind, statt nach verdächtigen Zeichen zu suchen.
4. Längenanomalien erkennen: Ein großer Unterschied zwischen der sichtbaren Zeichenanzahl und der tatsächlichen Code-Point-Anzahl deutet auf Manipulationsversuche hin.
5. Alle Eingabekanäle absichern: Betrifft nicht nur Nutzerprompts, sondern auch abgerufene Dokumente (RAG) und systemgenerierte Inhalte.
6. Angriffsversuche protokollieren: Behandeln Sie verdächtige Eingaben als sicherheitsrelevante Ereignisse und analysieren Sie sie.

Fazit: Sicherheit ist ein Prozess, kein Produkt

Prompt-Injection und versteckte Angriffe wie ASCII-Smuggling zeigen, dass LLMs nicht isoliert betrachtet werden dürfen. Die Sicherheit eines Systems hängt von der gesamten Pipeline ab – von der Datenerfassung bis zur Ausgabe.

Ein mehrschichtiger Ansatz, der Anwendungssicherheit, Datenmanagement und intelligente Filtermechanismen kombiniert, ist der einzige Weg, um diese Angriffe abzuwehren. Gleichzeitig müssen Entwickler akzeptieren, dass kein einzelner Schutzmechanismus unüberwindbar ist. Die beste Strategie besteht darin, die Angriffsfläche zu minimieren und verdächtige Aktivitäten kontinuierlich zu überwachen – bevor sie zu echten Sicherheitslücken werden.