Datenprovenienz

Sicherheitsziel

Datenprovenienz ist die Aufzeichnung darüber, woher Inhalt stammt und wie er zu dem wurde, was ein Modell sah oder ein System speicherte. Sie erfasst Quellsystem, Ressource und Version, beteiligten Mandanten und Principal, Lieferanten und Autor, soweit bekannt, sowie jede Transformation zwischen Originalartefakt und modellsichtbarem oder gespeichertem Ergebnis.

Ihr Sicherheitswert ist Nachvollziehbarkeit. Mit vollständiger Lineage kann ein Team erklären, welche Quelle einen Modellvorschlag geprägt hat, jede Zusammenfassung, jeden Cache-Eintrag, Indexeintrag oder Speichereintrag aus einer kompromittierten Quelle finden und die Evidenz hinter einer Fluss- oder Autorisierungsentscheidung rekonstruieren. Andere Kontrollen nutzen diese Evidenz: Informationsflusskontrolle verwendet Provenienz und Klassifikation für Flussentscheidungen, Agentenautorisierung verwendet Principal- und Ressourcenattribute für Ausführungsentscheidungen.

Zuständigkeitsgrenzen

Provenienz entscheidet nicht, ob einer Quelle vertraut wird, ob ein Nutzer auf Inhalt zugreifen darf, ob Daten fließen dürfen oder ob eine Aktion ausgeführt wird. Wenn ein System den Provenienzdatensatz selbst als Erlauben-oder-Verweigern-Schalter nutzt, gehört diese Entscheidung trotzdem zu einer Policy, und diese Policy sollte benannt und verantwortet sein. Provenienz speist Spotlighting / Datenmarkierung, das bestimmt, wie Inhalte dem Modell präsentiert werden.

Provenienz ist kein Vertrauen

Der häufigste Fehlgebrauch von Provenienz besteht darin, eine bekannte Herkunft als Vertrauensurteil zu behandeln. Fünf Unterscheidungen verhindern das.

Vertrauensmodell

Payload und Provenienzmetadaten sind getrennte Sicherheitsobjekte. Menschenlesbarer Payload wird nie zu Systemmetadaten, und eine Systemkomponente, die Inhalt getreu verarbeitet, hebt dessen Vertrauensstatus nie an. Der Ablauf unten wechselt zwischen beiden Ebenen, damit die Unterscheidung sichtbar bleibt.

Lesen Sie den Ablauf als zwei parallele Ebenen. Payload-Knoten (Quellinhalt, erfasster Payload, abgeleitete Artefakte, modellsichtbarer Text, Vorschläge, Wirkungen) bleiben variabel, egal wie viele vertrauenswürdige Komponenten sie berühren. Metadatenknoten (Umschlag, Lineage-Datensätze, Lineage abgeleiteter Artefakte) werden von Systemkomponenten aus maßgeblichen Eingaben wie Connector-Konfiguration, Identitätsdiensten und Speicherschlüsseln erzeugt, nicht aus Payload-Text geparst. Ein Parser ist eine Systemkomponente, seine Ausgabe aber ist abgeleiteter Payload mit demselben nicht vertrauenswürdigen Charakter wie seine Eingabe.

Provenienz und benachbarte Eigenschaften

Quellenidentität und Autorenidentität

Die Komponente, die Inhalt geliefert hat, ist oft nicht die Partei, die ihn geschrieben hat. Ein Such-Tool liefert Seiten fremder Autoren. Eine Ticket-API liefert von Kunden bearbeitete Felder. Ein Mail-Connector liefert weitergeleitete Nachrichten mit Zitaten mehrerer Personen.

Zentrale Provenienzfelder

Maßgebliche Metadatenebene

Für Sicherheitsentscheidungen genutzte Provenienz muss außerhalb von angreiferbearbeitbarem und modellverfasstem Payload-Text liegen. Ein strukturierter Umschlag trägt Metadaten neben dem Payload; der Payload befüllt den Umschlag nie.

Transformations-Lineage

Jeder Schritt zwischen Originalartefakt und modellsichtbarem Text sollte einen Lineage-Datensatz mit Eingabe, Ausgabe, Komponente und deren Version hinterlassen.

Eins-zu-viele- und Viele-zu-eins-Ableitungen

Lineage ist ein Graph, keine Kette. Ein Dokument ergibt viele Chunks; viele Chunks ergeben eine Zusammenfassung; eine Zusammenfassung kann gecacht, eingebettet und in den Speicher geschrieben werden. Datensätze sollten jedes abgeleitete Artefakt mit allen Eingaben und jede Eingabe mit allen Ableitungen verknüpfen, damit Abfragen in beide Richtungen funktionieren: vom modellsichtbaren Span zurück zu den Quellen und von einer Quelle vorwärts zu allem, was daraus abgeleitet wurde.

Zuordnung modellsichtbarer Spans

Der nützlichste Datensatz für Vorfallsarbeit ist die Zuordnung jedes Spans oder Felds im zusammengesetzten Kontext zu seinem Artefakt, seiner Transformationskette und seinem Quell-Span. Wird ein Modellvorschlag hinterfragt, sehen Untersuchende genau, welcher abgerufene Text, welches Tool-Feld oder welcher Speichereintrag vorhanden war und woher er stammte.

Hashes, Signaturen und Attestierung

Ein signiertes Dokument eines geprüften Partners kann dennoch feindseligen Text enthalten. Ein Digest, der zur erfassten Version passt, belegt nur, dass die Bytes gleich sind. Nutzen Sie diese Mechanismen zum Schutz von Lineage-Datensätzen und zur Erkennung von Änderungen; sie ersetzen nie Fluss- oder Aktions-Policy.

Provenienz von Tools und Agenten

Bei Tool-Ergebnissen ist die Tool-Identität die liefernde Komponente, nicht der Autor des Payloads. Erhalten Sie endgültige Ressource sowie Beitragende von Datensatz und Feld, soweit das Tool sie bereitstellt.

Zwischen Agenten reicht die Identität des sendenden Agenten nicht. Erhalten Sie die Quellen, die der Sender genutzt hat, und die Transformationen, die er angewandt hat, damit der Kontext eines empfangenden Agenten über die Übergabe hinaus nachvollziehbar bleibt. Es gibt kein transitives Vertrauen: Von einem vertrauenswürdigen Agenten weitergeleiteter Inhalt behält Provenienz und Charakter seiner ursprünglichen Quellen.

Persistente und abgeleitete Artefakte

Zusammenfassungen, Caches, Indexeinträge, Speichereinträge und generierte Datensätze überdauern die Anfrage, die sie erzeugt hat. Darum ist persistente Injection ohne Lineage schwer zu bereinigen. Jedes Artefakt sollte Verweise auf seine Eingaben, die erzeugende Komponente und Version sowie den Erstellungszeitpunkt behalten.

Embeddings und Indexeinträge sind abgeleitete Artefakte mit Lineage zu Quelle, Chunk, Index und Version des Embedding-Modells. Ein Modell sieht normalerweise den abgerufenen Text, nicht den Vektor, und Vektorisierung bereinigt keinen semantischen Inhalt; der abgerufene Chunk hat denselben Charakter wie seine Quelle.

Ableitungen aus gemischten Quellen

Ein aus mehreren Quellen gebautes Artefakt behält die vollständige Menge der Beitragenden und den Klassifikationsverweis jeder Eingabe. Es wird nie stillschweigend auf ein Label reduziert, schon gar nicht auf das der vertrauenswürdigsten Eingabe.

Wie Labels für eine bestimmte Entscheidung kombiniert werden, ist keine Provenienzregel. Die nutzende Policy, zum Beispiel Informationsflusskontrolle, entscheidet, wie Klassifikationen für eine bestimmte Quelle und Senke zusammengeführt werden. Aufgabe der Provenienz ist es, die vollständige Menge bereitzustellen.

Fehlende und mehrdeutige Provenienz

Fehlen Herkunft oder Lineage, wird das als unbekannt erfasst. Rekonstruieren Sie Provenienz nie aus Modellausgaben oder angreiferbearbeitbaren Feldern, und füllen Sie Lücken nie mit einer Standardquelle.

Ob unbekannte Provenienz einen Fluss oder eine Aktion blockiert, ist eine nachgelagerte Policy-Entscheidung. Wo eine geschützte Policy eine ausfallsichere Behandlung verlangt, liegt diese in der Informationsflusskontrolle oder Autorisierung, nicht im Provenienzdatensatz selbst.

Integrität von Lineage-Datensätzen

Lineage-Datensätze nützen nur, wenn sie nicht still umgeschrieben werden können. Append-only- oder unveränderlicher Speicher ist ein optionales Umsetzungsmuster; zugriffsgeschützte Datensätze mit Änderungsaudit oder integritätsgeschützte Logs sind andere. Keine Speichertechnologie ist allgemein vorgeschrieben.

Unveränderlichkeit bewahrt Datensätze. Sie schafft kein semantisches Vertrauen in den Payload, den diese Datensätze beschreiben.

Versionierung, Quarantäne und Widerruf

Ändert sich eine Quelle, wird sie in Quarantäne gestellt oder ihr Zugriff widerrufen, erlaubt Lineage, abgeleitete Artefakte und betroffene Anfragen aufzuzählen. Provenienz selbst löscht oder invalidiert diese Ableitungen nicht. Ein separater, verantworteter Prozess muss auf die Aufzählung reagieren: Caches invalidieren, Indizes neu aufbauen, Speichereinträge zurückziehen und gespeicherte Zusammenfassungen neu bewerten.

Telemetrie und Korrelation

Korrelations-IDs für Anfrage, Aufgabe und Sitzung verbinden Provenienz mit Laufzeitereignissen: welche Anfrage welchen Kontext zusammensetzte, welcher Vorschlag folgte, welche Policy-Entscheidung und Wirkung sich ergab. Korrelations-IDs sollten vom System erzeugt, in Metadaten getragen und nie aus dem Payload übernommen werden.

Datenschutz, Minimierung und Aufbewahrung

Lineage-Metadaten können selbst sensibel sein: Principal-IDs, Mandantennamen, Dateipfade und Quell-Spans. Erfassen Sie genug, um Sicherheitsentscheidungen zu rekonstruieren und Bereinigung zu unterstützen, vermeiden Sie unkontrollierte Kopien des Payloads in Lineage-Datensätzen, wenden Sie dieselbe Zugriffskontrolle wie auf die beschriebenen Daten an und legen Sie eine Aufbewahrung fest, die forensischen Bedarf gegen Minimierung abwägt.

Vorfallsreaktion und lineagebasierte Bereinigung

Durchgerechnetes synthetisches Szenario

Alle Namen und Werte sind synthetisch. Ein Support-Workflow für den Mandanten "Tenant-A" nimmt ein vom Kunden eingereichtes Dokument "contract-draft.pdf" in Version 3 auf, hochgeladen von "customer-417". Ein Parser in Version 2.4 normalisiert es; das Ergebnis wird in zwölf Chunks geteilt. Chunk 7 enthält anweisungsartigen Text, der sich an einen Assistenten richtet. Später erzeugt ein Zusammenfasser aus den Chunks 5 bis 8 eine Fallzusammenfassung; sie wird gecacht, eingebettet und in den Fallspeicher geschrieben. Ein Modellvorschlag, ein Dokument extern zu senden, beruft sich auf die Zusammenfassung.

Die Prüfung markiert den Vorschlag. Untersuchende starten beim modellsichtbaren Span und folgen der Lineage: Span, dann Zusammenfassung, dann Chunk 7, dann Parser 2.4, dann contract-draft.pdf Version 3, dann Beitragender customer-417 in Tenant-A. Die Vorwärts-Lineage des Dokuments listet die zwölf Chunks, die Zusammenfassung, ihren Cache-Eintrag, ihren Indexeintrag und den Speichereintrag. Korrelations-IDs zählen die Anfragen auf, die davon etwas nutzten. Verantwortliche Prozesse stellen das Dokument in Quarantäne, invalidieren den Cache, entfernen den Indexeintrag, ziehen den Speichereintrag zurück und markieren die Anfragen zur Prüfung.

Tests und Metriken

Messen Sie jede Eigenschaft einzeln mit explizitem Nenner. Es gibt keinen zusammengesetzten Wert; der Nutzen für harmlose Aufgaben wird getrennt berichtet.

Die Bewertung von Provenienzdatensätzen als Evidenz können Sie im Lab Datenprovenienz üben.

Umsetzungs-Checkliste

Standards und Quellen

Zur Quellennutzung: Das NIST-Glossar definiert Provenienz als Chronologie von Ursprung, Entwicklung, Eigentum, Ort und Änderungen eines Systems oder einer Komponente und zugehöriger Daten; das ist allgemeine Terminologie, keine KI-spezifische Umsetzungsleitlinie. W3C PROV-DM liefert ein allgemeines Vokabular aus Entitäten, Aktivitäten, Agenten und Ableitungen; diese Seite behauptet nicht, formales W3C PROV umzusetzen. Microsofts Leitlinie zur Retrieval-Hygiene besagt, dass sicheres Retrieval Quellenprovenienz, berechtigungsbewusstes Indexieren und Validierung bei jedem Lese- und Schreibvorgang erfordert, und empfiehlt, Lese- und Schreib-Lineage aufzubewahren; die Seite Agent Safety beschreibt Vertrauensgrenzen für extern beeinflusste Daten. Beides sind Herstellerleitlinien.

Häufige Fragen