Ausgabevalidierung

Sicherheitsziel

Die Ausgabevalidierung prüft Modell- oder Agentenausgaben, bevor eine nachgelagerte Komponente sie nutzt. Eine Senke ist alles, was diese Ausgabe verarbeitet: ein Tool Call, eine API-Anfrage, eine Datenbankoperation, eine gerenderte Seite, eine Datei, eine Nachricht oder ein anderer Agent. Die Validierung vergleicht die Ausgabe mit dem erklärten Vertrag der Senke, etwa Schema, Typen, Pflichtfelder, erlaubte Werte und Formate, und nimmt sie an oder lehnt sie ab.

Das Ziel ist eng gefasst. Validierung verhindert, dass fehlerhafte, vertragswidrige oder unerwartete Ausgaben eine Senke erreichen, die sie falsch interpretieren würde. Sie entscheidet nicht, ob eine Aktion erlaubt ist, ob Daten fließen dürfen oder ob die Ausgabe wahr oder sinnvoll ist.

Zuständigkeitsgrenzen

Das entspricht der Grenze in der Agentenautorisierung: Validierung umfasst Struktur, Typ und Parameterform; Autorisierung umfasst die Berechtigung.

Gültig, autorisiert und sicher sind verschiedene Eigenschaften

Bedrohungsmodell

Es ist davon auszugehen, dass Modellausgaben durch eingeschleuste Inhalte, Tool-Ergebnisse oder andere Agenten beeinflusst werden können und dass ein Angreifer eine nachgelagerte Senke zu etwas Unbeabsichtigtem bringen will: ein Tool mit veränderten Parametern aufrufen, Daten an ein neues Ziel senden, aktive Inhalte rendern oder Text an einen Interpreter weitergeben. Ebenso erzeugen gewöhnliche Modellfehler fehlerhafte oder vertragswidrige Ausgaben ganz ohne Angreifer.

Validierung verkleinert die Menge der Ausgaben, die eine Senke erreichen können. Sie kann nicht jeden schädlichen, aber wohlgeformten Wert erkennen; deshalb bleiben Autorisierung, Flusskontrolle und Least Privilege unabhängig.

Vertrauensmodell

Modellausgaben bleiben im gesamten Ablauf variable Daten. Validierung bestätigt die Konformität mit einem definierten Vertrag, Autorisierung die Berechtigung; keine der beiden Kontrollen macht modellgenerierte Inhalte zu vertrauenswürdigen Daten. Parser und Validatoren sind Systemkomponenten; die erzeugten Werte bleiben variable Daten, die eine Formprüfung bestanden haben.

Dasselbe gilt für Ausgaben von Kritiker-, Bewertungs- oder Detektormodellen: Sie bleiben auch nach der Validierung gegen ein festes Schema und der Verarbeitung durch eine Systementscheidung variable Daten.

Inventar der Senken

Strukturierte Ausgabe und erklärte Verträge

Validierung ist nur so stark wie der geprüfte Vertrag. Für jede Senke wird ein Schema erklärt: erlaubte Felder, Typen, Pflichtfelder, Wertebereiche, Aufzählungen und Maximalgrößen. Funktionen für strukturierte Ausgabe in Modell-APIs helfen dem Modell, die erwartete Form zu erzeugen, doch die Anwendung muss das Ergebnis selbst parsen und validieren, weil Generierungsvorgaben keine Sicherheitsgrenze sind.

Strenges Parsing

Es wird streng geparst. Abgelehnt wird Ausgabe, die sich nicht parsen lässt, unbekannte oder doppelte Felder enthält, Pflichtfelder vermissen lässt oder strukturierte Inhalte mit umgebendem Fließtext vermischt. Strukturen sollten nicht aus Freitext herausgesucht werden, indem man nach etwas Ähnlichem sucht, denn auch ein eingeschleustes Fragment kann ähnlich aussehen.

Allowlists statt Blocklists

Wo die Senke es zulässt, wird gegen Allowlists validiert: eine feste Menge von Tool-Namen, Operationsnamen, Dateitypen, Einheiten, Währungen oder Formaten. Blocklists verdächtiger Zeichenketten sind konstruktionsbedingt unvollständig und eignen sich eher als Erkennungssignal denn als Validierung.

Ausführbarer Freitext lässt sich nicht sicher validieren

Validierung macht beliebiges vom Modell erzeugtes SQL, Shell-Befehle, Code, Templates oder anderen ausführbaren Freitext nicht sicher. Wer solchen Text auf Länge, Zeichen oder Schlüsselwörter prüft, lässt dem Ergebnis des Modells die gesamte Grammatik des Interpreters offen.

Validierung versus Kodierung, Escaping und Parametrisierung

Beides ist nötig. Ein validierter Text, der in Markup gerendert wird, braucht weiterhin kontextgerechte Kodierung; eine validierte Kennung in einer Abfrage gehört weiterhin in einen Parameter und nicht in verketteten Abfragetext. Kodierung und Parametrisierung sind etablierte Praxis der Websicherheit und werden hier konzeptionell beschrieben; diese Seite nennt keine Escape-Sequenzen oder Umgehungsbeispiele.

Parametervalidierung

Jeder Parameter wird gegen Typ, Format, Bereich und Beziehung zu anderen Parametern geprüft: Beträge innerhalb von Grenzen, Datumswerte im erwarteten Zeitraum, Kennungen im erwarteten Format, Anzahlen innerhalb von Limits. Verweise, etwa ein Datensatzname auf seine Kennung, löst die Anwendung auf, statt vom Modell erfundene Kennungen zu übernehmen.

Zielsyntax versus Zielberechtigung

Ziele brauchen zwei getrennte Prüfungen. Die Validierung bestätigt, dass eine Adresse, URL, ein Pfad, Kanal oder eine Empfängerkennung wohlgeformt, vom erwarteten Typ und innerhalb der erklärten Form für die Senke ist. Ob dieses Ziel für diesen Principal, diese Aufgabe und diese Daten erlaubt ist, entscheiden Autorisierung und Informationsflusskontrolle.

Freitextfelder in gültigen Strukturen

Zusammenfassungen, Nachrichtentexte, Kommentare und Beschreibungen sind legitimer Freitext. Validierung kann Größe und Kodierung begrenzen und bestätigen, dass sie im richtigen Feld stehen. Ihre Bedeutung kann sie nicht bestätigen. Sie bleiben für jeden nachgelagerten Verbraucher variable Daten, auch für andere Modelle, und werden beim Rendern kodiert.

Gerenderte Ausgabe und implizite Anfragen

Wird Ausgabe in einem Browser oder Client gerendert, können manche Konstrukte ohne Nutzeraktion Anfragen auslösen, etwa automatisch geladene Bilder oder Vorschauen. Solche Anfragen können Daten an ein externes Ziel tragen. Validierung kann einschränken, welche Ausgabestrukturen erlaubt sind; welche externen Ziele kontaktiert werden dürfen, entscheidet die Fluss- und Egress-Policy. Inhalte, die verborgenen Kontext offenlegen könnten, wie bei der System-Prompt-Extraktion beschrieben, sind ein getrenntes Offenlegungsthema.

Mehrstufige Ausgabe und Agent-zu-Agent-Ausgabe

In Agenten-Workflows ist die Ausgabe eines Schritts die Eingabe des nächsten. Validiert wird an jeder Grenze, an der Ausgabe zu einem Tool Call, einer Übergabe oder einem gespeicherten Artefakt wird, nicht nur bei der Endantwort. In Multi-Agent-Systemen bleibt eine validierte Übergabenachricht für den empfangenden Agenten variabler Inhalt.

Verhalten bei Fehlern

Ein Validierungsfehler darf nie dazu führen, dass die rohe Ausgabe genutzt wird. Der Schritt wird abgelehnt, der Orchestrator erhält einen strukturierten Fehler, und nach Risikostufe wird entschieden, ob wiederholt, in einen eingeschränkten Modus gewechselt oder gestoppt wird. Der Fehler wird mit Verweis auf die abgelehnte Ausgabe und die verletzte Regel erfasst.

Reparatur- und Wiederholungsschleifen

Das Modell um eine Korrektur ungültiger Ausgabe zu bitten, ist üblich. Sicher bleibt es so: Wiederholung gegen dasselbe Schema, begrenzte Anzahl von Versuchen und nie eine Lockerung des Vertrags, damit Ausgabe besteht. Automatische Reparatur durch die Anwendung, etwa Kürzen oder Umwandeln von Werten, muss deterministisch, dokumentiert und auf Fälle begrenzt sein, in denen der reparierte Wert eindeutig ist.

Verhältnis zu anderen Kontrollen

Durchgespieltes Szenario

Synthetisches Beispiel. Ein Finanzassistent kann Rechnungen abrufen und über ein typisiertes Tool Zahlungsentwürfe mit den Feldern Rechnungskennung, Betrag, Währung und Empfängerkonto anlegen. Er verarbeitet eine Lieferanten-E-Mail, deren Text einen synthetischen Testmarker enthält, der als Anweisung formuliert ist, an ein anderes Konto zu zahlen und im Notizfeld eine Freitextabfrage nach "allen offenen Rechnungen" einzufügen.

In einer harmlosen Variante bittet die E-Mail um Zahlung der aufgeführten Rechnung an das hinterlegte Konto. Die Ausgabe ist gültig, der Empfänger stimmt mit dem Stammsatz überein, die Autorisierung erlaubt einen Entwurf, und der Entwurf geht wie üblich zur menschlichen Freigabe.

Was das Szenario zeigt und was nicht

Es zeigt, dass die Validierung eine wohlgeformte, aber schädliche Anfrage passieren lässt und die Autorisierung sie stoppt, was der beabsichtigten Arbeitsteilung entspricht. Es zeigt, dass Kodierung Freitext beim Rendern wirkungslos hält. Es zeigt nicht, dass Validierung Manipulation erkennt, dass die Freitextnotiz harmlos war oder dass die harmlose Variante aus einem anderen Grund sicher war als durch das Zusammenspiel der Kontrollen.

Telemetrie und Evidenz

Bedeutung für Incident Response

Kontrolliertes Testen

Jeder Senkenvertrag wird mit synthetischen Ausgaben getestet: fehlerhafte Strukturen, fehlende und zusätzliche Felder, Werte außerhalb des Bereichs, falsche Typen, wohlgeformte, aber nicht erlaubte Ziele und übergroßer Freitext. Tests laufen in isolierten Umgebungen mit harmlosen Senken und Testidentitäten. Geprüft wird sowohl, dass die Validierung ablehnt, was sie ablehnen soll, als auch, dass die Autorisierung wohlgeformte, aber nicht erlaubte Aktionen unabhängig ablehnt. Eine wiederverwendbare Bibliothek von Injection-Zeichenketten für Interpreter wird nicht gepflegt.

Metriken

Jede Kennzahl behält ihren eigenen Nenner. Es gibt keinen Gesamtscore, und der Nutzen für harmlose Aufgaben wird getrennt berichtet.

Häufige Fehler

Umsetzungscheckliste

Standards und Quellen

Zur Quellennutzung: OWASP LLM01:2026 ist die aktuelle Klassifikation für Prompt Injection, den Mechanismus, der Modellausgaben prägen kann. OWASP behandelt das nachgelagerte Risiko unsachgemäß verarbeiteter Modellausgaben als LLM10:2026 Improper Output Handling. Die OWASP Cheat Sheets sind etablierte allgemeine Leitlinien der Websicherheit zu parametrisierten Operationen, Allowlist-Validierung und kontextgerechter Ausgabekodierung; sie sind nicht spezifisch für Sprachmodelle. Microsofts Leitlinie ist eine Herstellerleitlinie, die eine mehrschichtige Strategie aus probabilistischen und deterministischen Maßnahmen empfiehlt. Diese Seite nennt keine Wirksamkeitszahlen.

Häufige Fragen