Informationsflusskontrolle

Sicherheitsziel

Informationsflusskontrolle ist die Kontrolle, die entscheidet, ob Daten mit einer bestimmten Provenienz und Klassifikation von einer konkreten Quelle über eine Folge von Verarbeitungsschritten zu einer konkreten Senke fließen dürfen. Das NIST-Glossar definiert Information Flow Control als die Verfahren und Kontrollen, die sicherstellen, dass Informationstransfers innerhalb eines Systems oder einer Organisation nicht gegen die Sicherheitsrichtlinie verstoßen, und NIST SP 800-53 Rev. 5 beschreibt in der Kontrolle AC-4 die allgemeine Anforderung der Flussdurchsetzung. Beides ist allgemeine Leitlinie, kein agentenspezifischer Mechanismus - und genau deshalb anwendbar: Sie definieren die Eigenschaft, die ein Agentensystem erben sollte, kein nachrüstbares Feature.

Prompt Injection kann ändern, was das Modell tun will. Sie darf nicht ändern können, welche Daten wohin fließen dürfen. Die Fluss-Policy wird deshalb außerhalb des Modells aus vertrauenswürdigen Provenienz-, Klassifikations-, Identitäts- und Zielattributen entschieden, niemals aus modellverfassten Labels oder Freitext.

Die Metadatenknoten werden out-of-band aus autoritativen Speichern aufgelöst; die Inhaltsknoten bleiben variable, auch wenn sie Systemkomponenten durchlaufen, denn Parser, Retriever oder Modell machen den transportierten Inhalt nicht vertrauenswürdig. Ein konkretes Deployment kann über eine Senke mehr wissen, aber eine Senke ist nicht allein deshalb vertrauenswürdig, weil sie ein adressierbares Ziel ist. Bestandteile mit niedrigerem Vertrauen oder höherer Sensitivität behalten ihre Provenienz und Klassifikation durch Verarbeitung und Zusammenführung.

Bedrohungsmodell: Beeinflussung kann die Fluss-Policy nicht umschreiben

Das Bedrohungsmodell ist das, auf das die Angriffsartikel dieser Seite zulaufen: Injizierter, abgerufener oder anderweitig nicht vertrauenswürdiger Inhalt kann den Plan des Modells steuern, und ein manipulierter Plan versucht typischerweise, Daten dorthin zu bewegen, wo sie nicht hingehören - in eine Antwort, einen Tool-Parameter, ein geteiltes Dokument, einen Memory-Speicher oder eine ausgehende Nachricht.

Flusskontrolle senkt nicht die Wahrscheinlichkeit, dass das Modell beeinflusst wird. Sie macht Beeinflussung unzureichend: Der Plan kann alles beabsichtigen, aber die Flussentscheidung wird an der Grenze aus vertrauenswürdigen Attributen getroffen, nicht aus dem Plan. Die angriffsseitigen Motivationen dokumentieren RAG-Prompt-Injection, Tool Output Injection und Multi-Agent-Prompt-Injection.

Zugriff, Autorisierung, Erreichbarkeit und Fluss: Vier getrennte Erlaubnisse

Agentensysteme vermischen vier Erlaubnisse, die vier verschiedene Fragen beantworten. Sie getrennt zu halten ist die Voraussetzung dafür, jede einzeln zu testen und nach einem Vorfall zu wissen, welche Kontrolle versagt hat.

Alle vier werden außerhalb des Modells durchgesetzt. Ein Deployment, das nur die ersten drei prüft, kann trotzdem leaken: Das Modell durfte die Daten lesen, die Sendeaktion war autorisiert, der Netzpfad existierte - und der Fluss war trotzdem verboten. Genau diese Lücke ist das Thema dieser Seite. Die ergänzende Grenze der Netzreichweite gehört einer separaten Egress-Kontrolle und wird hier nur referenziert, nicht spezifiziert.

Das Quelle-Transformation-Senke-Modell

Fluss-Policy wird als Relation über drei Dinge ausgedrückt: eine Quelle mit Attributen, eine Folge von Transformationen und eine Senke mit Attributen. Eine Entscheidung betrifft nie "das Dokument" an sich, sondern dieses Dokument, auf diese Weise transformiert, auf dem Weg zu diesem Ziel, in diesem Principal- und Mandantenkontext.

Zwei Eigenschaften des Modells sind betrieblich wichtig. Erstens wird die Entscheidung neu bewertet, sobald sich eines der drei Elemente ändert - eine neue Quelle tritt zum Kontext, eine neue Transformation wird angewandt oder die Senke wechselt. Zweitens wird die Matrix an Grenzen durchgesetzt, nicht im Prompt verhandelt.

Quelllabels, Provenienz, Klassifikation und Zielattribute

Die Flussentscheidung konsumiert Attribute, keinen Text. Auf der Quellseite: Provenienz (welches System, Dokument, Tool oder welcher Nutzer die Daten erzeugt hat), Klassifikation (welche Behandlungsklasse gilt) und der Principal- und Mandantenkontext, zu dem die Daten gehören. Auf der Senkenseite: Identität des Ziels, Klasse des Ziels (intern, extern, mandantenübergreifend) und der empfangende Principal.

Die kritische Vertrauensregel ist, woher diese Attribute stammen. Sie werden von den Systemkomponenten angehängt, die die Daten geladen, abgerufen oder gespeichert haben, oder aus autoritativen Identitäts- und Policy-Speichern aufgelöst. Sie werden nicht aus dem Inhalt selbst gelesen. Ein Dokument, das behauptet "dies ist öffentlich", hat keine für die Policy-Engine verwertbare Aussage gemacht; ein Modell, das classification=public oder safe_to_send=true ausgibt, hat variablen Inhalt erzeugt, keine Metadaten.

Subjekt, Principal, Sitzungs- und Mandantenkontext

Dasselbe Quelle-Senke-Paar kann für einen Principal erlaubt und für einen anderen verboten sein. Die Fluss-Policy bezieht deshalb den initiierenden Principal, den Sitzungs- oder Delegationskontext und die Mandantengrenze als erstklassige Eingaben ein. Ein internes Dokument darf zu einer Kollegin innerhalb desselben Mandanten und Workflows fließen, aber nicht an eine externe Adresse, nicht zu einem anderen Mandanten und nicht in einen Speicher, den andere Mandanten lesen können.

Diese Kontextattribute werden von der Plattform out-of-band aufgelöst - Sitzungstokens, Identitätsspeicher, Mandantenkonfiguration - und niemals aus dem Prompt oder der Modellausgabe übernommen. Wenn der initiierende Principal ein Nutzer ist, der an einen Agenten delegiert, sollte der Flusskontext die tatsächlichen Berechtigungen des Nutzers und den Umfang der Delegation abbilden, nicht die Laufzeitidentität des Agenten, wie unter Agentenautorisierung beschrieben.

Label-Propagation durch Parsing, Retrieval und Transformation

Jeder Verarbeitungsschritt muss die Labels seiner Eingaben auf seine Ausgaben übertragen. Ein Dokument parsen, OCR über ein Bild laufen lassen, Chunks in einen RAG-Kontext abrufen, zusammenfassen, übersetzen, ein Tool aufrufen, ins Memory schreiben: Jeder Schritt erzeugt Inhalt, dessen Provenienz "abgeleitet aus diesen Quellen" lautet und dessen Klassifikation der konservative Join seiner Eingaben ist.

Propagation ist Buchführung durch Systemkomponenten, und genau das ist ihr Fehlermodus: Eine Transformation ohne Propagation erzeugt still unmarkierte abgeleitete Daten. Deshalb müssen unbekannte Labels in geschützten Workflows fail-closed behandelt werden - dazu unten mehr.

Inhalte gemischten Vertrauens und der konservative Join

Agentenkontexte führen routinemäßig Quellen unterschiedlichen Vertrauens und unterschiedlicher Klassifikation zusammen: Systemprompt, Nutzeranfrage, abgerufene Dokumente, Tool-Ergebnisse, frühere Turns. Zusammenführen mittelt die Labels nicht. Die Standardregel ist der konservative Join: Das kombinierte Artefakt wird vom strengsten Bestandteil geregelt, und jeder Bestandteil behält seine eigene Provenienz für Entscheidungen, die Quellenpräzision brauchen.

Zwei Folgen ergeben sich. Inhalt wird nicht vertrauenswürdig, weil eine Systemkomponente ihn verarbeitet hat - die Zusammenfassung einer nicht vertrauenswürdigen Seite durch das Modell bleibt Inhalt, der aus einer nicht vertrauenswürdigen Seite abgeleitet ist. Und Inhalt wird nicht unklassifiziert, weil er mit öffentlichen Daten gemischt wurde - ein Kontext, der zu 95 Prozent öffentlich und zu 5 Prozent eingeschränkt ist, ist eingeschränkt, bis eine vertrauenswürdige Transformation das ausdrücklich ändert.

Abgeleitete Daten, Zusammenfassungen und die Deklassifikationsgrenze

Abgeleitete Daten - Zusammenfassungen, Auszüge, Embeddings, Übersetzungen, gecachte Schnipsel - erben die Klassifikation, weil sie Information aus ihren Quellen tragen. Die einzige Operation, die eine Klassifikation senkt, ist ein expliziter, vertrauenswürdiger Deklassifikationsschritt: ein Schwärzungs-, Bereinigungs- oder Freigabeprozess mit begrenzter Semantik, ausgeführt oder verifiziert durch eine vertrauenswürdige Komponente oder einen Prozess und mit seiner Herkunft protokolliert.

Deklassifikation ist ein Policy-Ereignis, kein Nebeneffekt von Formulierung. "Die Zusammenfassung enthält den Kundennamen nicht mehr" ist eine Aussage über Inhalt, die nur eine vertrauenswürdige Prüfung verifizieren kann; "der Freigabeprozess hat dieses Artefakt für externe Weitergabe genehmigt" ist ein Policy-Fakt. Das Erste ist prüfbarer Text; das Zweite ist das, worauf sich die Fluss-Engine stützen darf. Ein Modell darf seine eigene Ausgabe niemals per Behauptung deklassifizieren.

Ein Taint-artiges Modell, kein formaler IFC-Beweis

Das auf dieser Seite verwendete Modell ist Taint-artiges Reasoning: Verfolge, woher Daten kamen, propagiere die strengsten Labels und prüfe Flüsse an Grenzen. Das ist bewusst weniger ambitioniert als formale Informationsflusskontrolle, die über vollständige Systemverhalten, Verbände von Sicherheitsstufen und Noninterference-Garantien argumentiert.

Die Unterscheidung ist wichtig für Ehrlichkeit beim Testen. Ein Taint-artiges Deployment kann zeigen, dass markierte Flüsse an den überwachten Grenzen durchgesetzt wurden. Es kann nicht behaupten, dass keine unautorisierte Information über irgendeinen Kanal leaken kann - Timing, Existenz, Metadaten und andere indirekte Kanäle liegen außerhalb eines praktischen Durchsetzungsperimeters. Diese Seite beansprucht die praktische Eigenschaft und benennt ihre Grenzen, statt Vokabular aus Garantien zu leihen, die sie nicht liefert.

Wo Entscheidungen getroffen und durchgesetzt werden

Fluss-Policy folgt derselben Trennung von Entscheidung und Durchsetzung wie die Agentenautorisierung: Ein Policy-Entscheidungspunkt bewertet Attribute gegen die Policy, und Durchsetzungspunkte sitzen an den Grenzen, an denen Daten tatsächlich fließen können. Die Entscheidung ist zentral genug für Konsistenz und Versionierung; die Durchsetzung ist auf die Orte verteilt, an denen Daten sich bewegen.

Jede Grenze wird in den nächsten Abschnitten behandelt. Logging und Telemetrie sind eine fünfte, leisere Grenze: Logs und Traces sind ebenfalls Senken, und die Fluss-Policy gilt auch dafür, was in sie geschrieben wird.

Die Grenze der Kontextzusammenstellung

Alles, was das Modell sieht, wurde vom Kontextassembler dort platziert - das macht ihn zum ersten Durchsetzungspunkt. Die Policy an dieser Grenze entscheidet, welche Quellen in diesen Kontext für diesen Principal und diese Aufgabe gelangen dürfen: welche abgerufenen Dokumente, welche Tool-Ausgaben, welche früheren Gesprächsinhalte, welche Memory-Einträge.

Das ist eine Flussentscheidung, keine Relevanzentscheidung. Ein Dokument kann hochrelevant und in diesem Kontext trotzdem verboten sein - etwa ein eingeschränkter Datensatz, der zu einer Frage abgerufen wurde, deren Ausgaben nach außen gehen. Wer hier nicht durchsetzt, muss an jeder späteren Grenze gegen Inhalt verteidigen, den das Modell bereits gesehen hat - was strikt schwerer ist.

Die Tool-Aufruf- und Parametergrenze

Ein Tool-Aufruf ist ein Datenfluss: Modell-sichtbarer Inhalt bewegt sich in Parameter und von dort in alles, was das Tool erreichen kann. Das Gateway, das Tools ausführt, sollte deshalb nicht nur prüfen, ob die Aktion autorisiert ist, sondern welche Daten getragen werden: Enthält dieser Parameter Inhalt, der aus einer Quelle abgeleitet ist, deren Klassifikation die Zielklasse dieses Tools verbietet.

Die Prüfung läuft auf dem Envelope, nicht auf der Beschreibung des Modells. "Ich sende nur eine kurze Zusammenfassung" ist variabler Inhalt; die Fluss-Engine vergleicht die an den Parameterinhalt angehängte Provenienz mit den Zielattributen des Tools. Tools, die Daten lesen, müssen außerdem labeln, was sie zurückgeben, sonst verliert jede nachfolgende Flussentscheidung ihre Eingaben.

Die Speicher- und Memory-Grenze

Persistenz verlängert die Lebensdauer jeder Flussentscheidung. Was in einen Memory-Speicher, Cache, Index oder Log geschrieben wird, wird später gelesen - möglicherweise von anderen Aufgaben, Sitzungen, Nutzern oder Agenten. Die Speichergrenze entscheidet deshalb, was persistieren darf, in welcher Partition, mit welcher Aufbewahrung und mit welchen Labels.

Die Wechselwirkung mit persistenter Prompt Injection ist direkt: Ein Speicher, der Inhalt ohne Provenienz und Klassifikation behält, ist ein Speicher, dessen spätere Leser überhaupt keine Fluss-Policy mehr anwenden können. Nach Mandant und Vertrauenszone partitionieren, Labels beim Schreiben anhängen und ein fehlendes Label beim Lesen als unbekannt behandeln - mit einer Policy für unbekannt.

Die Ausgabe- und Egress-Grenze

Die letzte Grenze ist die, an der Inhalt zu einer Senke hinausgeht: eine nutzerseitige Antwort, ein gerendertes Dokument, eine Nachricht, eine API-Antwort, ein Webhook-Payload. Hier bewertet die Fluss-Engine die Herkunft des ausgehenden Artefakts - die Menge der Quellen, aus denen es abgeleitet ist - gegen die Attribute der Senke.

Diese Seite behandelt nur die Datenfrage. Ob ein Netzpfad zum Ziel existiert, welche Protokolle erlaubt sind und wie Konnektivität begrenzt wird, gehört zu Netzwerk- und Egress-Beschränkungen, einer separaten Kontrolle. Beide greifen ineinander: Egress sagt, dass der Pfad existiert; Fluss sagt, was ihn durchqueren darf; Autorisierung sagt, dass die Aktion geschehen darf; Least Privilege begrenzt, wie viel Reichweite überhaupt existiert. Alle vier müssen zustimmen, und jede kann unabhängig verneinen.

Mandanten- und nutzerübergreifende Isolation

Mandanten- und Nutzergrenzen sind Flussgrenzen mit dem strengsten Standard. Daten des Mandanten A dürfen nicht in Kontexte, Ausgaben, Logs oder Caches des Mandanten B gelangen, und Inhalte eines Nutzers dürfen nicht in der Sitzung eines anderen auftauchen - auch nicht über geteilte Infrastruktur wie Prompt-Caches, Embedding-Indizes oder Memory-Speicher.

Isolationsfehler sind hier meist strukturell, nicht adversarial: ein geteilter Cache-Schlüssel, ein Index ohne Mandantenscoping, eine aggregierende Log-Pipeline. Weil das Architektureigenschaften sind, sind sie testbare Architektureigenschaften: Isolationstests gehören in die Release-Pipeline, mit einer Bestehensrate pro Grenze, nicht als allgemeiner Eindruck.

Bereinigung, Schwärzung und vertrauenswürdige Deklassifikation

Legitime Arbeit muss ständig Grenzen überschreiten, die die strikte Policy verbietet: einen geschwärzten Auszug veröffentlichen, ein anonymisiertes Aggregat teilen, eine kundensichere Zusammenfassung senden. Flusskontrolle ermöglicht das über explizite Deklassifikationstransformationen mit drei Eigenschaften: Die Transformation wird von einer vertrauenswürdigen Komponente ausgeführt oder verifiziert, ihre Semantik ist begrenzt (was sie entfernt und was sie garantiert), und der Vorgang wird mit Herkunft protokolliert.

Das wiederkehrende Antimuster ist das Modell, das eingeschränkte Inhalte "sicher" zusammenfasst, während die Pipeline die Zusammenfassung als sauber behandelt. Die Zusammenfassung erbt die strengste Quellklassifikation, bis ein vertrauenswürdiger Schritt sie ändert - Formulierung ist keine Deklassifikation.

Aggregations- und Kompositionsrisiko

Einzeln erlaubte Flüsse können sich zu einem sensibleren Ergebnis zusammensetzen. Zehn erlaubte Abfragen können einen Datensatz rekonstruieren; ein Verzeichnis einzeln harmloser Einträge kann das geschützte Attribut offenbaren. Fluss-Policy, die nur Einzeltransfers bewertet, wird das übersehen.

Praktische Gegenmaßnahmen sind begrenzt, nicht absolut: Raten- und Volumenlimits pro Principal und Senke, aggregationsbewusste Regeln für bekannte sensible Zusammensetzungen und menschliche Prüfung bei ungewöhnlich breiten Extraktionsmustern. Die ehrliche Position ist, dass Aggregationsrisiko gemanagt, nicht gelöst wird - es gehört ins Bedrohungsmodell und ins Monitoring, nicht in die Behauptung, die Grenzprüfungen allein genügten.

Indirekte Flüsse und abgeleitete Attribute

Information bewegt sich auch über Kanäle, die keine Inhaltstransfers sind: Antwortzeiten, Existenz eines Datensatzes, Längen, Fehlerverhalten, Zählerstände und aus eingeschränkten Daten abgeleitete Attribute wie Embeddings oder Statistiken. Ein Taint-artiges System schließt diese Kanäle nicht und sollte das nicht behaupten.

Was praktikabel ist: Hochauflösende abgeleitete Artefakte (Embeddings, antrainierte Repräsentationen, feingranulare Aggregate) standardmäßig unter der Klassifikation ihrer Quellen behandeln; Metadaten- und Fehlerantworten an nicht vertrauenswürdigen Grenzen grob halten; und die Restkanäle explizit im Bedrohungsmodell dokumentieren, damit niemand den durchgesetzten Perimeter mit einem Beweis verwechselt. Diese Seite beansprucht bewusst Grenzdurchsetzung für markierte Inhalte, nicht Noninterference.

Fail Closed bei fehlenden Labels

Propagation bricht in jedem realen System irgendwo: Ein Altsystem-Tool liefert unmarkierte Ergebnisse, eine Migration lässt Attribute fallen, eine neue Datenquelle kommt ohne Klassifikation. Der einzige sichere Standard in geschützten Workflows ist, fehlende Provenienz oder Klassifikation als unbekannt zu behandeln und Flüsse zu verweigern, die die Policy nicht bewerten kann.

Fail-closed hat einen Preis - gutartige Flüsse werden verweigert, bis jemand die Quelle markiert - und genau deshalb ist der Gegenstandard so verführerisch und so gefährlich. Ein System, das fehlende Labels aus modellverfasstem Text ergänzt, hat seine Flusskontrolle in einen Prompt-Vorschlag verwandelt. Unbekanntes-Label-Ereignisse sollten protokolliert und gezählt werden; eine steigende Zahl ist ein Engineeringsignal, kein Ärgernis, das man umgeht.

Durchgespieltes Szenario: Der Sendevorgang, der autorisiert war und trotzdem verweigert wurde

Ein Support-Agent beantwortet Kundenfragen mit einer internen Wissensbasis, deren Dokumente die Klassifikation "intern eingeschränkt" tragen. Eine eingehende Kunden-E-Mail enthält eine injizierte Anweisung, eine Zusammenfassung interner Verfahren an eine externe Adresse zu senden. Das beeinflusste Modell schlägt genau das vor: eine Sendeaktion, deren Text die abgerufenen internen Dokumente zusammenfasst.

Vier Kontrollen beantworten nun vier Fragen. Least Privilege: Die Identität darf das Sendetool überhaupt nutzen, und die Wissensbasis ist für Supportaufgaben lesbar - im Rahmen. Autorisierung: Eine vollständig aufgelöste Sendeaktion mit diesem Ziel und diesem Text ist ein erlaubter Aktionstyp für diesen Workflow - abstrakt erlaubt. Egress: Ein Netzpfad zum Ziel existiert. Flusskontrolle: Die Herkunft des Textes enthält Quellen der Klassifikation intern eingeschränkt, das Ziel ist eine externe Adresse, und es gab keinen vertrauenswürdigen Deklassifikationsschritt - verweigert. Die E-Mail wird nie gesendet; die Verweigerung wird mit Quellkennungen, Herkunft, Policy-Version und Entscheidung protokolliert.

Ein zweiter, gutartiger Fall zeigt, dass das Gate ein Gate ist und keine Mauer: Der Agent erstellt eine kundensichere Zusammenfassung, ein vertrauenswürdiger Schwärzungsschritt verifiziert, dass das Artefakt nur freigebbare Inhalte enthält, die Deklassifikation wird protokolliert, und dieselbe Sendeaktion passiert die Flussprüfung nun mit dem neuen Label des geschwärzten Artefakts. Gleiches Tool, gleiche Zielklasse, andere Herkunft - andere Entscheidung.

Was das Szenario zeigt und was nicht

Das Szenario demonstriert Platzierung und Unabhängigkeit: Das Fluss-Gate bewertet Datenherkunft gegen Zielattribute, getrennt von Aktionsautorisierung und Netzreichweite, und es kann verweigern, was die anderen Gates erlauben. Es demonstriert außerdem den vertrauenswürdigen Deklassifikationspfad für legitime Grenzüberschreitungen.

Es beweist nichts über Abdeckung. Quellen, die nie Labels erhielten, Transformationen, die Provenienz verloren, Tools, die unmarkierte Ergebnisse liefern, und Senken außerhalb des Durchsetzungsperimeters liegen allesamt außerhalb dessen, was ein Szenario zeigt. Es beweist nichts über indirekte Kanäle. Und es sagt nichts über die Wahrscheinlichkeit von Beeinflussung, die keine Kontrolle auf dieser Seite senkt. Für genau diese Eigenschaften existiert das Testprogramm.

Beobachtbarkeit, Herkunft, Tests und Metriken

Jede Flussentscheidung, erlaubt oder verweigert, sollte einen Datensatz erzeugen: Quellkennungen, Provenienz- und Klassifikationslabels, die Transformationskette, die Attribute der Senke, Principal- und Mandantenkontext, Policy-Version und Ergebnis. Herkunftsvollständigkeit - wie viel des bewegten Inhalts intakte Labels trägt - ist selbst die primäre Gesundheitsmetrik, denn Entscheidungen sind nur so gut wie die Attribute, die sie konsumieren.

Kontrollierte Tests nutzen eine Matrix: Quellklassen mal Senken mal Transformationen mal Principals und Mandanten, mit Zellen für erwartete Verweigerung und erwartete Erlaubnis, plus separat gemessene gutartige Aufgaben. Simulierte Beeinflussung - eine injizierte Anweisung in einem abgerufenen Dokument - verifiziert, dass Verweigerungen vom Fluss-Gate kommen und nicht aus Modellvorsicht.

Entscheidungen von der Quelle zur Senke können Sie im Lab Informationsflusskontrolle üben.

Erfolg gutartiger Aufgaben wird separat als Nutzen berichtet und nie in eine Sicherheitskennzahl gefaltet: Ein Deployment, das nichts fließen lässt, erreicht bei jeder Flussmetrik Höchstwerte. Es gibt keine Gesamtnote; jede Metrik wird mit ihrem Nenner berichtet.

Vorfallreaktion und häufige Fehler

Nach einem vermuteten unautorisierten Fluss drehen sich die Fragen um Bewegung: Welche Quelldaten waren betroffen, welche Senken haben sie erreicht, welche abgeleiteten Kopien existieren, und welche Replikate - Memory, Logs, Caches, Indizes - tragen sie jetzt.

Zur Quellennutzung: Die NIST-Definition und AC-4 sind allgemeine, autoritative Leitlinien und nicht agentenspezifisch; sie werden für das Prinzip und die Platzierung der Flussdurchsetzung genutzt, nicht für Agentenaussagen. Die OWASP-Listen werden als benachbarte Risikorahmen für Datenleckage und Zielmanipulation in AI-Systemen zitiert, nicht als Informationsfluss-Standards. Microsofts Seiten Agent Safety und Reduce autonomous agentic AI risk werden als Herstellerleitlinie zitiert: Agent Safety für Vertrauensgrenzen und die Sicherung von Datenflüssen, die Seite zu agentic Risk für die Klassifikation sensibler Daten sowie deterministische Use-, Retention- und Output-Kontrollen. Microsoft FIDES wird ausschließlich als produktspezifische experimentelle Implementierungsevidenz für markenbasierte Informationsflusskontrolle-Middleware innerhalb von Agent Framework zitiert; sein Verhalten wird nicht als universelle Eigenschaft von Informationsflusskontrolle dargestellt. Nirgendwo auf dieser Seite werden Statistiken, Benchmarkzahlen oder formale Sicherheitsgarantien behauptet. Das anfrageseitige Gegenstück ist die Agentenautorisierung; das reichweitenseitige Gegenstück ist Least Privilege; die angriffsseitigen Motivationen stehen in der Angriffsbibliothek.

Häufige Fragen