Homoglyph
Ein Homoglyph ist ein Zeichen, das einem anderen Zeichen optisch stark ähnelt, aber einen anderen Unicode-Codepunkt besitzt. Dadurch können zwei Zeichenfolgen für Menschen gleich wirken, technisch aber verschieden sein. Bei LLM-Anwendungen betrifft das vor allem exakte Vergleiche, Signaturen, Sperrlisten, Protokolleinträge und Prüfungen, die Zeichenketten ohne Unicode-Sicherheitsanalyse kontextabhängig bewerten.1
Einordnung
Unicode unterscheidet bei verwechselbaren Zeichen unter anderem Single-Script-, Mixed-Script- und Whole-Script-Confusables. Der Standard begründet Schutzmechanismen damit, dass Maschinen unterschiedliche Sequenzen eindeutig unterscheiden, Menschen visuell ähnliche Bezeichner jedoch leicht verwechseln können.1 Für Prompt Injection ist das eine Randbedingung von Eingabe- und Inhaltsprüfung: Eine rein lexikalische Regel kann eine Abweichung übersehen, obwohl ein Leser die Zeichenfolge als gleich wahrnimmt. Der Begriff ist enger als Obfuskation, denn nicht jede Verschleierung beruht auf visueller Ähnlichkeit. Er ist auch von Tokenisierung zu trennen: Tokenisierung erklärt nicht, ob eine Anwendung homographe Zeichen gleich, verschieden oder verdächtig behandelt.
Dokumentiertes Beispiel
Die dokumentierte Grundlage ist kein einzelner LLM-Vorfall, sondern der Unicode-Standard selbst. UTS #39 spezifiziert Verfahren zur Confusable Detection und zur Erkennung gemischter Schriftsysteme; er beschreibt zudem eingeschränkte Zeichenprofile für Sicherheitskontexte.1 OWASP führt Unicode-Smuggling und verwandte Verschleierungen als Prompt-Injection-Muster, bei denen Sicherheitsprüfungen und nachfolgende Verarbeitung auseinanderlaufen können.2 Daraus folgt jedoch keine belastbare Pauschalaussage, dass jedes Sprachmodell Homoglyphen semantisch gleich interpretiert oder jeder Austausch einen Filter umgeht. Das Verhalten hängt von Modell, Tokenizer, Normalisierung und Anwendungslogik ab. Ein fachlich sauberer Test prüft daher die konkrete Kette, statt eine universelle Modellwirkung zu behaupten.
Bedeutung für die Abwehr
Sinnvoll ist eine zweistufige Kontrolle: Zunächst wird Text in einer dokumentierten Unicode-Normalform verarbeitet; anschließend werden für sicherheitsrelevante Felder gemischte Schriftsysteme, Confusable-Skelette oder nicht erlaubte Zeichenprofile bewertet.1 Eine Warnung ist oft angemessener als automatisches Ersetzen, weil legitime mehrsprachige Namen und Zitate vorkommen können. Bei eng begrenzten Eingabefeldern, etwa Befehlswörtern, Identifikatoren oder Policy-Labels, darf die zulässige Zeichenauswahl dagegen deutlich strenger sein. Für unstrukturierte Nutzdaten sollten die ursprüngliche Zeichenfolge, die Normalisierung und der Befund getrennt protokolliert werden. Ergänzend müssen Guardrails und Freigaben nicht von einer einzelnen Worterkennung abhängen: OWASP empfiehlt gestaffelte Kontrollen, klare Trennung von Daten und Instruktionen sowie minimale Berechtigungen.2
Quellen
- Unicode Consortium, „UTS #39: Unicode Security Mechanisms“, Version 17.0.0, 4. September 2025, https://www.unicode.org/reports/tr39/ ↩
- OWASP Cheat Sheet Series, „LLM Prompt Injection Prevention Cheat Sheet“, laufend aktualisiert, abgerufen am 20. August 2026, https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html ↩