Vertrauensgrenzen und Modellkontext

Was modellsichtbarer Kontext ist

Modellsichtbarer Kontext umfasst alles, was das Modell für eine einzelne Inferenz erhält: Anweisungen der Anwendung, den Gesprächsverlauf, abgerufene Passagen, Tool-Ergebnisse, Dateiinhalte und alle Metadaten, die die Anwendung als Text darstellt. Aus Sicht des Modells ist das eine einzige Tokenfolge. Jede Struktur, die die Anwendung beabsichtigt, muss entweder als Text überleben, den das Modell interpretiert, oder vollständig außerhalb des Modells bleiben.

Quelle, Darstellung und Vertrauen

Drei Dinge werden leicht vermischt:

Eine vertrauenswürdige Quelle garantiert keine vertrauenswürdige Darstellung, und keine von beiden macht die Anweisungen im Inhalt verbindlich. Ein Dokument aus einem internen Repository kann trotzdem Text einer externen Partei enthalten. Wie Herkunft und Transformationen erfasst werden, beschreibt Datenprovenienz.

Vertrauen entsteht nicht durch Position oder Verkettung

Wer Inhalte in eine System-Nachricht, an den Anfang des Prompts oder in einen abgegrenzten Block setzt, macht sie dadurch nicht vertrauenswürdig, und weiter unten platziert werden sie nicht harmlos. Verkettung fügt Zeichenketten zusammen, Berechtigungen reisen dabei nicht mit. Steht Text erst einmal im Kontext, beantwortet das Modell nur noch die Frage, wie es fortfährt, und diese Antwort wird von allem darin beeinflusst.

System-, Entwickler-, Nutzer-, Retrieval- und Tool-Inhalte

Anwendungen kombinieren in der Regel Inhalte unterschiedlicher Herkunft. Anbieter bieten unterschiedliche Rollenmodelle, Bezeichnungen und Prioritätsregeln an. Die folgenden Kategorien beschreiben daher Herkünfte, keine universelle Schnittstelle:

Die Einstufungen beziehen sich auf die Autorität von Anweisungen, nicht auf sachliche Richtigkeit. Behandeln Sie sie als Standardwerte, die die Anwendung nur mit Systemnachweisen überschreibt.

Anwendungskontrollierte Metadaten und modellsichtbare Prosa

Die Anwendung kennt Fakten, die das Modell nicht prüfen kann: die authentifizierte Person, den Mandanten, die Zugriffsliste eines Dokuments, welches Tool ein Ergebnis geliefert hat, ob ein Inhalt eine Prüfung bestanden hat. Halten Sie diese Fakten als strukturierte Metadaten im Anwendungszustand und nutzen Sie sie für Entscheidungen. Wird ein Teil davon auch dem Modell gezeigt, ist diese Kopie nur informativ; die maßgebliche Fassung bleibt in der Anwendung.

Kontextzusammenstellung als Sicherheitsgrenze

Bei der Kontextzusammenstellung entscheidet die Anwendung, was in den Kontext des Modells gelangt: welche Dokumente, welche Tool-Ergebnisse, wie viel Verlauf, welche Metadaten. Das ist eine echte Sicherheitsgrenze, denn sie bestimmt, was das Modell beeinflussen kann und welche Daten es offenlegen könnte.

• Nur aufnehmen, was die Aufgabe braucht. Jedes zusätzliche Dokument vergrößert Angriffsfläche und Offenlegungsrisiko.
• Zugriffskontrolle vor dem Abruf anwenden, damit das Modell nie Daten sieht, die die Person nicht lesen dürfte.
• Festhalten, was woher zusammengestellt wurde, damit sich Entscheidungen und Vorfälle nachvollziehen lassen.

Provenienz und Herkunftskette

Provenienz hält fest, woher ein Inhalt stammt; die Herkunftskette (Lineage) hält fest, wie er auf dem Weg in den Kontext transformiert wurde. Beides gehört zu den Metadaten der Anwendung, wird als eigenes Objekt neben dem Inhalt geführt und erlaubt späteren Kontrollen die Frage: Stützt sich dieser Vorschlag auf Inhalte aus externer Quelle? Einzelheiten beschreibt Datenprovenienz.

Abgerufene Inhalte und Tool-Ausgaben bleiben variabel

Abgerufene Passagen und Tool-Ergebnisse bleiben variable oder nicht vertrauenswürdige Inhalte, solange keine Systemnachweise etwas anderes belegen. Relevanz im Ranking ist kein Vertrauen. Die Authentifizierung eines Tools belegt, wer geantwortet hat, nicht, dass man der Antwort gefahrlos folgen kann. Siehe RAG Prompt Injection, Tool-Output-Injection und Indirekte Prompt Injection.

Kontrollen außerhalb des Modells

Weil das Modell keine Grenzen durchsetzen kann, fallen die entscheidenden Entscheidungen in deterministischem Code um das Modell herum:

Validierung nimmt Strukturen an oder lehnt sie ab; Autorisierung und Flusskontrolle entscheiden über Berechtigungen. Keine davon macht modellerzeugte Inhalte vertrauenswürdig. Siehe Agentenautorisierung, Informationsflusskontrolle und Ausgabevalidierung.

Ein konzeptioneller Vertrauensfluss

Systemkomponenten treffen Entscheidungen; Inhalte und Vorschläge bleiben durchgehend variabel. Die Wirkung ist das, was die deterministischen Prüfungen zugelassen haben, nicht das, was das Modell wollte.

Häufige Fehler

Speziell zum System Prompt siehe System-Prompt-Extraktion.

Checkliste für die Umsetzung

Im Lab nachvollziehen

Das Lab Vertrauensgrenzen und Modellkontext macht diesen Artikel zur praktischen Übung: modellsichtbaren Text mit Anwendungsnachweisen vergleichen und die Policy auf einen Modellvorschlag anwenden. Das Lab Grundlagen der direkten Prompt Injection macht modellsichtbaren Kontext und den Autorisierungsschritt in einer kontrollierten Simulation sichtbar. Falls noch nicht geschehen, beginnen Sie mit Was ist Prompt Injection? und lesen Sie danach die Abwehrübersicht.

Standards und Quellen

Häufige Fragen