Warum Prompt Injection nicht nur Eingabevalidierung ist

Das Missverständnis: "Einfach die Eingabe validieren"

Wer aus der Anwendungssicherheit kommt, fragt oft, ob Prompt Injection nicht einfach fehlende Eingabevalidierung ist: Prompt prüfen, gefährliche Teile entfernen, Problem gelöst. Die Frage ist berechtigt, und die Antwort lautet: teilweise, aber anders als erwartet.

Klassische Eingabevalidierung prüft, ob ein Wert einer erwarteten Syntax, einem Typ, einer Länge, einem Enum, einem Wertebereich, einem Dateiformat oder einem Protokollvertrag entspricht. Prompt Injection betrifft dagegen, wie bedeutungstragende natürlichsprachliche oder multimodale Inhalte im Modellkontext interpretiert werden, auch Inhalte, die für ihren fachlichen Zweck völlig gültig sind.

Der Artikel baut auf Anweisungen und Anweisungshierarchien, Vertrauensgrenzen und Modellkontext und RAG und Retrieval auf.

Was klassische Eingabevalidierung gut kann

Eingabevalidierung ist die richtige deterministische Kontrolle überall dort, wo die Anwendung die erwartete Form eines Werts kennt: Kennungen, Typen, Längen, Enums, Zahlenbereiche, Datumswerte, Dateiformate, Zielformate, Tool-Parameter, Schemas und Protokollnachrichten.

Sie weist fehlerhafte Daten früh ab, senkt Parser- und Verarbeitungsrisiken und liefert späteren Kontrollen saubere, typisierte Werte. Nichts in diesem Artikel spricht dafür, sie abzuschaffen.

Warum natürliche Sprache anders ist

Ein Support-Ticket, eine E-Mail oder ein Dokument kann ein strukturiertes Datei- oder Nachrichtenformat haben. Seine natürlichsprachlichen Inhaltsfelder bieten aber keine parsergestützte semantische Grenze zwischen Geschäftsdaten und Anweisungen an das Modell. Dieselben Wörter können Zitat, Beschreibung, Bitte oder etwas sein, das ein Modell als Vorgabe behandelt, je nach Kontext.

Ein Validator kann bestätigen, dass der Text eine Zeichenkette mit zulässiger Länge und Kodierung ist. Er kann nicht deterministisch bestimmen, wie ein Modell diesen Text interpretiert, sobald er modellsichtbar wird.

Gültige Geschäftsinhalte können ein Modell beeinflussen

Prompt Injection kann über völlig gültige Inhalte ankommen: Nutzernachricht, Support-Ticket, E-Mail, Dokument, Wiki-Seite, Webseite, Suchergebnis, Tool-Ausgabe, OCR-Text oder abgerufenen Chunk. Siehe Direkte Prompt Injection und Indirekte Prompt Injection.

Derselbe Text kann legitime Geschäftsdaten sein und trotzdem anweisungsähnliche Bedeutung enthalten. Ihn abzulehnen kann die Fachfunktion brechen; gültige Geschäftsinhalte erhalten dadurch nicht automatisch Anweisungsautorität oder Anwendungsberechtigung; fachliche/Quellautorität wird getrennt über Provenienz und Source-of-Truth-Regeln entschieden.

Syntax, Semantik und Autorität

Syntaktisch gültig, schemakonform, wohlgeformt, sicher kodiert oder von einem Parser akzeptiert zu sein, begründet weder Quellvertrauen noch Anweisungsautorität, Nutzerautorisierung, Datenflusserlaubnis oder Aktionsautorisierung.

Warum Stichwortsperren und "Bereinigung" unvollständig sind

Freie Sprache zu bereinigen ist nicht dasselbe, wie ihre Bedeutung zu neutralisieren. Das Entfernen von Zeichen, Trennzeichen oder Stichwörtern kann legitime Daten beschädigen und trotzdem Umschreibungen, andere Sprachen, indirekte Formulierungen, multimodale Inhalte und spätere Transformationen wie Zusammenfassung oder OCR verfehlen.

Inhaltsprüfung ist nützlich, aber probabilistisch

Eingabe- und Inhaltsprüfung und Erkennung von Prompt Injection können die Exposition senken, verdächtige Inhalte in eingeschränkte Abläufe lenken und Evidenz erzeugen. Klassifikatoren für natürliche Sprache haben falsch positive und falsch negative Ergebnisse.

Ein Detektor, der Inhalte markiert, erteilt oder verweigert selbst keine Berechtigung, und ein Detektor, der nichts findet, darf ebenfalls keine Berechtigung erteilen. Die Berechtigungsentscheidung bleibt bei Autorisierung und Flussrichtlinien.

Wo Allowlists gut funktionieren

Allowlists sind am stärksten, wo die Domäne tatsächlich endlich und strukturiert ist: Enum-Auswahl, Ressourcen-IDs, Operationsnamen, freigegebene Tool-Namen, Zielklassen und begrenzte Zahlenwerte.

Beliebige natürliche Sprache lässt sich nicht per Allowlist erfassen, ohne ihre Fachfunktion zu verlieren. Freitext bleibt variabler Inhalt; Entscheidungen fallen an den strukturierten Werten drumherum.

Strukturierte Tool-Argumente und Schemas

Ein Tool-Schema oder JSON-Schema prüft die Form: Pflichtfelder, Typen, Formate, Enums. Es entscheidet nicht, ob die angeforderte Aktion erlaubt ist, ob ein Dokument maßgeblich ist oder ob ein Ziel zulässig ist.

Zuerst werden die vorgeschlagenen Argumente validiert, dann geht die aufgelöste, typisierte Aktion an die Agentenautorisierung und die Flussrichtlinien.

Die Analogie zur klassischen Injection: nützlich und begrenzt

Klassische Injection und Prompt Injection haben gemeinsam, dass auf irgendeiner Ebene Daten und Steuerung verwechselt werden. Diese Intuition hilft.

SQL-Parametrisierung funktioniert, weil SQL eine formale Grammatik hat: Die Anwendung legt die Abfragestruktur fest und übergibt Werte getrennt, und der Datenbankparser setzt die Trennung deterministisch durch. Natürlichsprachlicher Modellkontext bietet in der Regel keine ebenso deterministische, parsergestützte Trennung zwischen "Anweisung" und "Daten".

Trennzeichen, Labels und Spotlighting: Robustheit, keine Durchsetzung

Trennzeichen, XML-artige Tags, Labels und Spotlighting / Datenmarkierung können einem Modell helfen, Daten von Anweisungen zu unterscheiden, und die Robustheit verbessern.

Sie werden aber weiterhin vom Modell interpretiert. Sie sind keine deterministischen Vertrauensgrenzen und ersetzen keine Kontrollen außerhalb des Modells.

Provenienz und Source-of-Truth-Regeln

Datenprovenienz hält fest, woher Inhalte stammen und was mit ihnen geschah. Source-of-Truth-Regeln legen fest, welche Quelle für einen bestimmten Zweck maßgeblich ist.

Beides folgt nicht aus Gültigkeit. Ein gültiges, relevantes Dokument kann trotzdem die falsche Autorität sein. Provenienz- und Autoritätsmetadaten bleiben anwendungseigen und außerhalb bearbeitbarer Inhalte.

Autorisierung und Least Privilege

Autorisierung fragt, ob dieser Principal diese Aktion auf dieser Ressource mit diesen Parametern im aktuellen Zustand ausführen darf. Sie ist deterministisch und stützt sich auf anwendungseigene Identität, Mandant und ACLs, nie auf Behauptungen im Text.

Least Privilege begrenzt den Schaden, wenn eine Beeinflussung gelingt. Das Risiko von Prompt Injection hängt von Inhaltseinfluss, Modelleinfluss, erreichbaren Daten und Fähigkeiten sowie davon ab, ob deterministische Anwendungskontrollen die Wirkung verhindern.

Informationsflusskontrolle und Zielrichtlinien

Informationsflusskontrolle fragt, ob Daten von einer Quelle oder Klassifizierung zu einer Senke oder einem Ziel fließen dürfen. Eine wohlgeformte Adresse oder URL kann trotzdem ein verbotenes Ziel sein.

Ausgabevalidierung und senkenspezifische Kodierung

Ausgabevalidierung prüft, ob eine vorgeschlagene Ausgabe dem Vertrag der Anwendung oder Senke entspricht: Struktur, Format, zulässige Werte.

Senkenspezifisches Kodieren, Escaping und Parametrisieren sind ein eigener Schritt. Richtig an ihrer Senke eingesetzt, verhindern sie Klassen wie SQL-, HTML- oder Command-Injection. Sie machen aus nicht vertrauenswürdiger Sprache keine vertrauenswürdigen Anweisungen, und Modellausgabe bleibt variable Daten, auch wenn die Eingabe die Validierung bestanden und das Modell seine Anweisungen befolgt hat.

Die Kontrollen im Vergleich

Synthetische Beispiele

Mehrschichtiges Kontrollmuster

Diese Checkliste ist Architekturempfehlung, keine aus einem Standard zitierte Anforderung.

Häufige Missverständnisse

Quellen und Praxis

Die OWASP Cheat Sheets werden nur für klassische Anwendungssicherheit und senkenspezifische Kontrollen zitiert, nicht als Leitfaden zu Prompt Injection. Kontrollvergleich und Checkliste sind Architekturempfehlungen.

Häufige Fragen