Vertrauensgrenze
Eine Vertrauensgrenze markiert den Übergang, an dem Daten oder Befehle aus einem weniger vertrauenswürdigen Bereich in einen geschützten Systembereich gelangen. Bei Sprachmodellen ist sie besonders problematisch, weil Instruktionen und Daten im selben Kontextfenster als Text verarbeitet werden. Prompt Injection entsteht, wenn unzuverlässiger Text diese Grenze faktisch überschreitet und Verhalten, Werkzeugnutzung oder Ausgaben verändert.1
Einordnung
In herkömmlicher Software werden Vertrauensgrenzen durch Schnittstellen, Datentypen, Berechtigungen und Prozessgrenzen sichtbar. Ein Webformular kann etwa Daten liefern, aber nicht eigenständig Serverrechte erhalten. Ein LLM unterscheidet im Kontext dagegen nicht zuverlässig zwischen einer vertrauenswürdigen Arbeitsanweisung und einem abgerufenen Dokument; beides sind Token mit potenziellem Einfluss auf die nächste Ausgabe. Das Problem ist daher nicht allein ein gefährliches Wortmuster, sondern die Vermischung von Kontrolle und Inhalt.
Die relevante Grenze liegt an jedem Eingang für fremden Kontext: Nutzertexte, Webseiten, E-Mails, Dateien, Suchtreffer, Datenbankfelder und Tool-Antworten. Ein klarer Rollenhinweis im Prompt kann das Modell an die Trennung erinnern, erzwingt sie aber nicht. OWASP empfiehlt deshalb, externe Inhalte zu kennzeichnen und abzusondern, Privilegien zu begrenzen sowie risikoreiche Operationen einer menschlichen Freigabe zu unterstellen.1 Diese Maßnahmen ergänzen sich: Kennzeichnung reduziert Fehlinterpretationen, Rechtebegrenzung reduziert die Folgen einer Fehlinterpretation.
Dokumentiertes Beispiel
Die Forschungsarbeit CaMeL behandelt die Vertrauensgrenze als Architekturaufgabe. Der Ansatz extrahiert Kontroll- und Datenflüsse aus der vertrauenswürdigen Anfrage und soll verhindern, dass nachträglich abgerufene unzuverlässige Daten den Programmfluss bestimmen; für Tool-Aufrufe nutzt er Fähigkeiten zur Durchsetzung von Datenflussregeln.2 In der von den Autoren verwendeten AgentDojo-Umgebung wurden 77 Prozent der Aufgaben mit nachweisbarer Sicherheit gelöst, gegenüber 84 Prozent ohne Schutzschicht.2 Das Ergebnis ist kein allgemeiner Sicherheitsbeweis für beliebige Agenten, zeigt aber den Unterschied zwischen einer Prompt-Konvention und einer systemseitig erzwungenen Grenze.
Bedeutung für die Abwehr
Eine belastbare Architektur behandelt abgerufenen Text als Datenobjekt mit Herkunft und Zweckbindung. Er darf eine Zusammenfassung, Suche oder Antwort beeinflussen, aber nicht selbst die Befugnis erzeugen, Daten weiterzugeben oder ein Werkzeug aufzurufen. Daraus folgen getrennte Komponenten für Planung, Ausführung und Freigabe, strukturierte Tool-Schnittstellen sowie eine autorisierende Instanz außerhalb des Modells. Prompt Injection bleibt damit möglich, wird aber von einer unkontrollierten Anwendungsübernahme zu einem begrenzteren Datenrisiko. Die Frage für Reviews lautet nicht „Ist der Prompt stark genug?“, sondern: Welche unzuverlässige Eingabe darf welche Wirkung über diese Kontextfenster hinweg überhaupt auslösen?
Quellen
- OWASP Gen AI Security Project, „LLM01:2026 Prompt Injection“, 3. August 2026sangabe, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ ↩
- Edoardo Debenedetti et al., „Defeating Prompt Injections by Design“, 24. Juni 2025, https://arxiv.org/abs/2503.18813 ↩