Autorität besitzt man nicht, man erbt sie

Stellen wir uns einen KI-Agenten vor, der gebeten wird, ein Dokument zusammenzufassen. Die Aufgabe wirkt harmlos: lesen, zusammenfassen, einen kürzeren Text zurückgeben. Doch das Dokument enthält zwischen den Zeilen eine versteckte Anweisung, die nicht vom Nutzer stammt: Lösche diese Datei, exfiltriere jenes Geheimnis. Es ist eines der Szenarien, die der Informatiker Nicola Gallo in seinem Paper Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents nutzt, welches am 9. Juli 2026 auf arXiv veröffentlicht wurde. Es ist nützlich, genau dort anzusetzen, weil es präzise zeigt, wo das Problem liegt.

Um seine Arbeit zu erledigen, hält der Agent mehrere Autoritätsquellen gleichzeitig in den Händen: seine eigenen Dienstanmeldeinformationen, ein vom Nutzer delegiertes Token und spezifische Berechtigungen für jedes aufgerufene Werkzeug. Wenn er die vom Dokument geforderte Aktion ausführt, verstößt er nicht notwendigerweise gegen eine technische Regel: Er besitzt irgendwo in seinem Bündel an Anmeldeinformationen die Berechtigung, Dateien zu löschen oder auf dieses Geheimnis zuzugreifen. Das Problem ist nicht, dass ihm die Autorisierung fehlt. Es ist, dass diese Berechtigung zu einer anderen Ausführungskette gehört als derjenigen, die die aktuelle Anfrage ausgelöst hat. Eine traditionelle Prüfung, die nur darauf schaut, ob die Berechtigung existiert und nicht woher sie stammt, kann die beiden Fälle nicht unterscheiden.

Gallo schlägt vor, diese Frage mit einem formalen Gerüst zu beantworten, das er Proof-of-Continuity nennt und das in ein umfassenderes Modell namens PIC (Provenance Identity Continuity) eingebettet ist. Die These, maximal vereinfacht: Wir müssen aufhören, nur in Begriffen wie „Wer hält den Pass in der Hand?“ zu denken, und anfangen, auch zu hinterfragen, wie sich die Autorität vom Ursprung bis hierher fortgepflanzt hat. Es lohnt sich zu verstehen, warum das so ist und was sich dadurch tatsächlich ändern würde.

Das grundlegende Problem: Wenn das Token nicht mehr ausreicht

Viele Autorisierungssysteme übertragen Autorität über Objekte wie Tokens und Anmeldeinformationen: Wenn Sie das richtige Objekt besitzen, können Sie das tun, was das Objekt autorisiert. Es gibt bereits Systemfamilien, sogenannte Capability-basierte Systeme, die die einfachste Form dieses Problems gut lösen—nämlich jene mit einem einzigen Schritt zwischen Anforderer und Ausführer—, weil sie die Berechtigung unrennbar an den Akt des Aufrufs binden. Die Frage, die PIC stellt, betrifft einen anderen Fall: Wenn Autorität nacheinander mehrere Dienste, mehrere Agenten und mehrere Ausführungsgrenzen durchläuft, kann der Empfänger dann wirklich überprüfen, ob diese Autorität genau zu der Kette gehört, die fortgesetzt wird, oder prüft er nur, ob das Objekt gültig ist?

Der technische Name für dieses Problem ist fast vierzig Jahre alt. Im Jahr 1988 beschrieb der Ingenieur Norm Hardy in einem kurzen Artikel, der zu einem Klassiker der IT-Sicherheit wurde, The Confused Deputy, einen realen Vorfall beim Timesharing-Unternehmen Tymshare. Ein FORTRAN-Compiler, der in einem privilegierten Verzeichnis installiert war, hatte die Berechtigung, Nutzungsstatistiken in eine eigene Datei zu schreiben. Ein Nutzer rief ihn auf und bat darum, die Debug-Ausgabe in eine Datei zu schreiben, die durch einen einfachen Pfadfehler mit der Abrechnungsdatei des Unternehmens übereinstimmte. Der Compiler überschrieb unter Nutzung seiner Autorität über das Verzeichnis die Abrechnungsdaten. Der Nutzer hatte nie die Berechtigung gehabt, diese Datei anzurühren, und hätte diese Aktion daher niemals autorisieren können. Der Compiler hingegen besaß diese Berechtigung für eigene Rechnung und übte sie als direkte Folge einer Anfrage aus, die dies nicht rechtfertigte. Das ist der „verwirrte Stellvertreter“: ein Intermediär, der eine fremde Autorität besitzt, die nicht zur bedienten Anfrage gehört, und sie dennoch in gutem Glauben nutzt, um eine Aktion zu erzeugen, die der Anforderer niemals alleine hätte autorisieren können.

Es gibt einen Film, der genau diese Pathologie mit fast prophetischer Präzision erzählt: Brazil von Terry Gilliam. Die gesamte Handlung dreht sich um ein Insekt, das auf einem Drucker zerquetscht wird und den Namen „Tuttle“ in „Buttle“ verwandelt. Von diesem Moment an verhaftet und verfolgt der bürokratische Staatsapparat streng nach seinen Verfahren den falschen Mann. Kein Beamter im Film ist böse oder korrupt: Jeder übt gewissenhaft die Autorität aus, die er besitzt und die formell gültig ist, hat aber die Verbindung zur korrekten Ursache verloren. Es ist dieselbe Distanz zwischen Besitz und Kontinuität, die das Paper für Software formalisiert.

Von „Besitz“ zu „Kontinuität“: Der Kerngedanke

Hier liegt der Kern des Vorschlags. Anstatt nur zu fragen: „Wer besitzt die Autorität, dies zu tun?“, fragt das Modell: „Ist diese Autorität eine überprüfbare Fortsetzung derjenigen, die die gesamte Kette erzeugt hat, oder stammt sie aus einer anderen Ausführung oder einer unabhängigen Quelle, die unterwegs aufgetaucht ist?“.

Die intuitivste Metapher ist die eines Konzertpasses mit mehreren Kontrollpunkten: An jedem Tor wird er gestempelt, und jeder Stempel kann nur Einschränkungen hinzufügen, niemals welche entfernen. Ein Pass, der Zugang zum Innenraum gewährt, kann am zweiten Tor auf einen Zugang nur zur Tribüne reduziert werden, niemals umgekehrt. Wenn ein Schritt versucht, mehr Autorität zu präsentieren, als er erhalten hat, stoppt ihn der Sicherheitsdienst: Die Kette ist gebrochen und die Ausführung wird nicht fortgesetzt.

Einschränkung alleine reicht jedoch nicht aus. Es ist auch erforderlich, dass jeder Schritt nachweist, dass er tatsächlich kausal mit dem unmittelbar vorangegangenen Schritt verbunden ist und nicht mit einem zufällig ähnlichen. Erst die Kombination aus beidem—Einschränkung von Berechtigungen und nachgewiesene kausale Verbindung—garantiert, dass kein am Ursprung fehlendes Privileg weiter hinten auftauchen kann, indem es sich als Teil derselben legitimen Fortsetzung ausgibt.

Unter der Haube: Die drei Prinzipien des PIC-Modells

Der Name PIC ist keine zufällige Bezeichnung, und es lohnt sich, ihn aufzuschlüsseln, da er hilft, die Struktur des gesamten Modells zu behalten. Die offizielle Website des Projekts, pic-protocol.org, präsentiert es als drei verschiedene Prinzipien, die zusammenarbeiten.

Provenance (Herkunft): Die kausale Kette muss von Anfang bis Ende immer zurückverfolgbar sein. Bricht sie ab, stoppt die Ausführung. Identity (Identität): Identifiziert das Subjekt, von dem Autorität ausgehen kann—sei es das Login eines Nutzers oder eine Unternehmensrichtlinie—, verlangt jedoch nicht, dass diese Identität bei jedem folgenden Schritt unverändert weitergegeben werden muss. Was überprüfbar bleiben muss, ist, dass die ausgeübte Autorität weiterhin zu der spezifischen Ausführungskette gehört, die fortgesetzt wird. Continuity (Kontinuität): Bei jedem Schritt muss nachgewiesen werden, dass man kausal mit dem vorherigen Schritt verbunden ist, und die Autorität kann sich nur verringern, niemals erweitern.

Hier sollte auch eine mögliche terminologische Verwirrung geklärt werden. Im Paper ist PIC der Name des formalen Gesamtsystems, während Proof-of-Continuity die End-to-End-Eigenschaft beschreibt, die man erhält, wenn man zwei Dinge entlang der gesamten Kette zusammenfügt: jeden einzelnen lokalen Beziehungsbeweis—was das Paper Proof-of-Relationship nennt—und die Bedingung, dass sich die Autorität niemals von einem Schritt zum nächsten erweitert. In einem Satz: Man beweist jeden lokalen Link, prüft, dass die Autorität niemals wächst, und die Summe dieser beiden Bedingungen stellt die Kontinuität vom Ursprung bis zum aktuellen Schritt her.

Der Autor stellt in den Schlussfolgerungen des Papers ein Detail klar, das einem häufigen Missverständnis vorbeugt: Der Begriff „Identity“ bedeutet nicht, dass die Identität des Nutzers bei jedem Schritt entlang der gesamten Kette wiederholt mitreisen muss. Dieselbe Identität mit exakt denselben Privilegien kann an völlig unterschiedlichen Ausführungen beteiligt sein: Was sie unterscheidet, ist nicht die Identität, sondern die spezifische kausale Kette, zu der sie gehören. Das ist eine subtile, aber wichtige konzeptionelle Verschiebung: Die Last der Autorisierung verlagert sich von der ständigen Neuinterpretation von „Wer bist du?“ zur Überprüfung von „Ist dies wirklich eine legitime Fortsetzung dieser spezifischen Ausführung?“.

Das Theorem, das die Türen schließt

Der eleganteste Teil des Papers, der auch das größte Gewicht für Entwickler realer Systeme hat, ist ein Theorem, das beweist, dass drei wünschenswerte Eigenschaften in keinem Autoritätspropagationssystem koexistieren können: erstens, dass die Autorisierung historie-invariant ist, es also keine Rolle spielt, wie man zu einer Aktion gelangt ist, sondern nur, ob man die Berechtigung besitzt; zweitens, dass ein Dienst legitimerweise eine eigene Autorität unabhängig von der Anfrage halten kann, was in der Praxis fast immer notwendig ist; drittens, dass der verwirrte Stellvertreter strukturell unmöglich ist.

Die Beweisführung ist eher ein Ausschlussverfahren als eine Rechnung: Wenn ein Ausführer seine eigene Autorität mit der der Anfrage mischen kann und die Autorisierungsprüfung in keiner Weise liest, welche spezifische Kette die Aktion verursacht hat, dann existieren Situationen, in denen eine authentische Autorität, die jedoch zu einer anderen Ausführung gehört, der falschen Anfrage zugeschrieben wird. Das ist kein Implementierungsfehler, sondern eine direkte Konsequenz daraus, welche Informationen die Autorisierungsentscheidung ignoriert.

Die praktische Konsequenz ist interessanter als das Theorem selbst. Wenn man auf die zweite Eigenschaft verzichtet—also einem Dienst verbietet, eigene Autorität zu besitzen—, ist das fast immer unpraktikabel: Ein Zahlungs-Gateway muss Gelder mit seiner eigenen Bankautorisierung bewegen können, nicht nur mit der des Nutzers. Wenn man auf die dritte verzichtet, akzeptiert man, dass der verwirrte Stellvertreter möglich bleibt, was schlicht unsicher ist. Für Systeme, die beide Eigenschaften beibehalten wollen—unabhängige Autorität der Ausführer und Schutz vor dem verwirrten Stellvertreter—, wird die gangbare Wahl daher darin bestehen, auf die erste zu verzichten: Die Autorisierung muss sensitiv gegenüber der spezifischen kausalen Kette werden, die die Aktion erzeugt hat, anstatt invariant gegenüber ihrer Historie zu sein. Das Paper fasst diesen Punkt treffend zusammen: Eine Aktion kann räumlich gültig, aber zeitlich ungültig sein—das heißt, die Berechtigung existiert und ist authentisch, gehört aber zur falschen Ursache.

PoR und PoC: Die operativen Bausteine

Das Modell baut auf zwei verschiedenen, aber ineinandergreifenden Konzepten auf. Proof-of-Relationship ist der lokale Einzel-Hop-Beweis: Er zeigt, dass ein Ausführungsschritt die legitime kausale Fortsetzung des unmittelbar vorangegangenen Schrittes ist und nicht eines beliebigen anderen, der ihm ähnelt. Proof-of-Continuity ist dagegen die Zusammensetzung all dieser Links über die gesamte Sequenz hinweg, zusammen mit der Überprüfung, dass sich die Autorität niemals erweitert hat: Wenn jedes einzelne Glied hält und kein Schritt zusätzliche Privilegien erlangt hat, ist die gesamte Kette nachweisbar mit dem Ursprung verbunden.

Eine nützliche Klarstellung: Proof-of-Relationship ist keine besondere Kategorie von Token; es ist eine überprüfbare Eigenschaft der Beziehung zwischen zwei Schritten. Ein Kontinuitäts-Artefakt, das an den spezifischen Vorgänger gebunden ist, kann den erforderlichen Nachweis erbringen, um diese Eigenschaft konkret umzusetzen—jedoch nur unter einer Bedingung: dass der Empfänger diese Verbindung in seiner Entscheidung tatsächlich überprüft. Der bloße Besitz des Artefakts reicht nicht aus. Dieses Detail widerlegt die Idee, dass Proof-of-Possession und Proof-of-Continuity konkurrierende Ansätze seien: Ersterer beweist die Kontrolle über ein Objekt in einem Moment, Letzterer beweist, dass dieser Moment tatsächlich kausal mit allen vorherigen verbunden ist. Eine Enforcement-Architektur begleitet die Ausführung, indem sie die Beweise für diese Aufgabe generiert und überprüft, ohne dass das Modell zwingend eine physisch getrennte Komponente vorschreibt.

Der Fall, den das Paper konkret aufgreift

Kehren wir zum Szenario des Agenten und des Dokuments mit der versteckten Anweisung zurück, da das Paper es mit einer Sorgfalt behandelt, die es verdient, getreu wiedergegeben zu werden. Wenn der ursprüngliche Autoritätskontext nur die Operation „Dieses Dokument zusammenfassen“ autorisiert, kann unter Proof-of-Continuity eine Operation wie „Diese Ressource löschen“ oder „Dieses Geheimnis exfiltrieren“ niemals eine gültige Fortsetzung sein, egal was das Dokument nahelegt. Der Agent kann die Aktion physisch versuchen: Das Modell erhebt nicht den Anspruch, sie physisch unmöglich zu machen, aber ein konformes System kann sie nicht als legitimes Ergebnis dieser Kette akzeptieren, da dieses Privileg nicht in der vom Ursprung ererbten Menge auftaucht.

Das Paper schlägt auch einen subtileren Fall vor, der nützlich ist, um die Präzision der Bedingung zu verstehen: Ein Ausführer hat legitimerweise Zugriff auf zwei verschiedene Berechtigungen—eine Lese- und eine Schreibberechtigung—, die jeweils für eine andere, gleichzeitig laufende Anfrage gültig sind. Wenn dieser Ausführer die beiden Berechtigungen kombiniert und nur einer der beiden Anfragen zuordnet, bleibt jede einzelne Berechtigung authentisch, aber die Kombination gehört zur falschen Kette. Es ist dasselbe Prinzip wie im Dokumentenbeispiel, angewendet auf einen noch heimtückischeren Fall, weil keine der beiden Berechtigungen für sich genommen verdächtig wirkt.

Das ist kein isoliertes Laborszenario. Indirekte Prompt-Injection—also bösartige Anweisungen, die in vom Agenten verarbeiteten Inhalten versteckt sind—ist heute einer der meistdiskutierten Angriffsvektoren für Agentensysteme. Die Autorisierungsspezifikation des Model Context Protocol, des Standards, über den sich KI-Agenten heute mit externen Werkzeugen verbinden, schreibt vor, dass jedes Token an einen präzisen Empfänger gebunden sein muss, und verbietet explizit die Weitergabe eines für einen Dienst empfangenen Tokens an einen nachgelagerten anderen Dienst. Das ist eine reale, bereits in Produktion befindliche Abhilfe, bleibt aber eine punktuelle Prüfung Hop für Hop: Sie legt fest, für welchen Dienst ein Token ausgestellt wurde, beweist aber nicht von selbst, dass die aktuelle Aktion die kausale Fortsetzung der gesamten Kette ist, die diese Autorität begründet hat. Es ist wieder der Unterschied zwischen gebundenem Besitz und nachgewiesener Kontinuität.

Das Problem unterschiedlicher Vokabulare

In einem realen System spricht jeder Hop oft eine andere Sprache. Ein REST-Endpunkt beschreibt Berechtigungen anders als ein OAuth-Scope oder eine Datenbankrolle. Das Paper führt daher eine Übersetzungskontrolle zwischen Vokabularen ein, die es ermöglicht, Autorität von einem Berechtigungssystem in ein anderes zu übertragen, ohne jemals die Nicht-Erweiterungs-Bedingung zu verletzen.

Es gibt jedoch eine wichtige Bedingung zu beachten: Das Modell betrachtet diese Übersetzung als Eingangsgröße, als Policy-Entscheidung, nicht als etwas, das es selbst beweist. Wenn die Übersetzung zu großzügig ist und am Ende mehr gewährt als sie sollte, ist das ein Fehler in der Konfiguration dieser spezifischen Übersetzung, nicht eine Lücke in der Logik des Modells. Es ist wie das Übersetzen eines Vertrags von einer Sprache in eine andere: Wenn die Übersetzung Rechte hinzufügt, die das Original nicht vorsah, liegt der Fehler in der Übersetzung, nicht im Prinzip, dass ein Vertrag einzuhalten ist.

Wie es tatsächlich gebaut werden könnte

Das Paper ist ein Modell, kein Implementierungshandbuch: Die konkrete Konstruktion des Proof-of-Relationship wird einer begleitenden Enforcement-Architektur überlassen. Für die Skalierbarkeit deutet es an, dass nicht die gesamte Historie bei jedem Hop erneut validiert werden muss; Checkpoints oder zusammengefasste Beweise reichen aus, um jedem Schritt zu erlauben, seinen Platz in der Kette zu beweisen, ohne die gesamte Vergangenheit mitzuschleppen.

Was diese Arbeit zu mehr als einer akademischen Übung macht, ist, dass eine konkrete Implementierung unter demselben Dach bereits im Gange ist. Das Projekt PIC-X geht von einer bereits bestehenden Autorität aus—beispielsweise einem OAuth-Token—, leitet daraus einen initialen PIC-Autoritätskontext ab und erzeugt konkrete signierte Artefakte wie dedizierte JWT-Tokens und COSE-Strukturen, wobei die Nicht-Erweiterungs-Bedingung über den gesamten Pfad eingehalten wird. Auf der Open-Source-Ebene existieren bereits mit dem Projekt verknüpfte Pakete, etwa eine Rust-Bibliothek, die die Überprüfungslogik für Kontinuitätsbeweise implementiert, zusammen mit einer offen veröffentlichten technischen Spezifikation. Es ist noch kein Standard, aber es ist der Beweis, dass der Sprung von der Theorie zur Praxis bereits begonnen hat.

Die vom Autor selbst eingeräumten Grenzen

Es muss ebenso deutlich gesagt werden, was das Modell noch nicht abdeckt. Das im Paper vom 9. Juli veröffentlichte formale Modell beschreibt nach eigenem Eingeständnis nur lineare Ketten: ein Schritt nach dem anderen, ohne Verzweigungen. Szenarien, in denen ein Agent eine Aufgabe an zwei Subagenten parallel delegiert, bleiben in diesem Text als zukünftige Erweiterung vermerkt. Seitdem hat das Projekt begonnen, in nachfolgenden formalen Materialien den einfacheren Fall des Fan-Out zu behandeln—also zwei „Schwester“-Fortsetzungen, die am selben Punkt der Kette entstehen; die Komposition, also das Zusammenführen unabhängiger Ketten zu einem einzigen Ergebnis, bleibt hingegen ein separates Problem mit noch zu definierenden Regeln.

Es ist verlockend, hier an Jorge Luis Borges und seine Erzählung Der Garten der Pfade, die sich verzweigen zu denken: Die Geschichte stellt sich einen Roman—und letztlich ein Schicksal—vor, in dem jede Verzweigung die Alternativen nicht eliminiert, sondern sie in parallelen Zeiten koexistieren lässt. Gallos Modell kann vorerst nur auf einem einzigen Pfad gleichzeitig gehen; es in die Lage zu versetzen, Verzweigungen zu verwalten, ohne die Garantie zu verlieren, dass kein Zweig mehr Autorität erlangt als der Stamm, aus dem er entspringt, bleibt das offene Problem.

Es gibt weitere erklärte Grenzen. Der Widerruf wird nicht als rückwirkende Operation auf eine bereits laufende Kette behandelt: Es bleibt zu definieren, ob ein Widerruf nur zukünftige Übergänge blockiert oder auch bereits ausgestellte entwertet. Zudem besteht ein subtileres Sicherheitsrisiko, auf das der Autor selbst hinweist: Das Modell bindet die Autorität innerhalb einer bereits gestarteten Kette, entscheidet aber nicht von selbst, wann ein Ausführer legitimerweise eine neue eigene Kette öffnen darf. Zu unterscheiden, ob eine Aktion wirklich autonom ist oder nur als solche getarnt—also in Wirklichkeit durch eine externe Anfrage verursacht wurde—, bleibt nach ausdrücklicher Einräumung des Papers eine Verantwortung der Enforcement-Architektur, nicht des Modells selbst.

Was sich für Entwickler, Architekten und Entscheider ändert

Für Entwickler von Agenten und Werkzeugen wird die nützliche Frage bei jeder Aktion einfach zu formulieren sein, auch wenn sie nicht trivial zu beantworten ist: Was ist der Ursprung dieser Autorität, ist diese Operation wirklich eine direkte Fortsetzung der ursprünglichen Absicht, und halte ich verschiedene Autoritätsquellen getrennt, falls ich sie mische?

Für Plattformarchitekten legt das Paper nahe, Herkunftsmetadaten in Aufrufe zwischen Diensten einzuführen, dedizierte Enforcement-Komponenten zu evaluieren—sei es als Sidecar, Gateway oder Middleware—und Kontinuität als Kriterium zur Beurteilung von Multi-Agenten-Orchestrierungs-Frameworks heranzuziehen, bevor diese akzeptiert werden.

Für Sicherheitsexperten und Entscheider auf Unternehmensebene bietet das Modell ein präzises Vokabular zur Bewertung des Risikos einer stillschweigenden Rechteausweitung in automatisierten Pipelines sowie ein solides Argument, um die Rückverfolgbarkeit der kausalen Kette in die Mindestsicherheitsanforderungen autonomer Systeme aufzunehmen—nicht nur als nützliche Information für ein späteres Audit, sondern als Eigenschaft, die die Autorisierungsentscheidung aktiv nutzt.

Schlussfolgerungen

Die größte Frage bleibt offen, die das Paper selbst stellt, ohne sie zu beantworten: Welche bestehenden Standards von OIDC über OAuth bis hin zu Capability-Systemen werden letztlich etwas Ähnliches wie Kontinuität integrieren und mit welchem Komplexitätsaufwand für Entwickler?

Das Paper ist jedoch in einem Punkt klar, den man als zentrale Erkenntnis festhalten sollte: Besitz, Beziehung und Kontinuität beweisen nicht dasselbe. Besitz beweist die Kontrolle über ein Objekt in einem bestimmten Moment. Beziehung beweist den kausalen Zusammenhang zwischen zwei aufeinanderfolgenden Schritten. Kontinuität beweist, dass die Autorität die gesamte Kette durchlaufen hat, ohne sich jemals zu erweitern. Das macht Tokens, Anmeldeinformationen oder Besitznachweise keineswegs falsch: Es verlagert die Frage lediglich auf eine andere Dimension. Zwei Aktionen können dasselbe Subjekt, dasselbe Token und sogar dieselbe Berechtigung haben, aber unter dem Gesichtspunkt der Autorisierung zu unterschiedlichen Ergebnissen führen, weil sie auf verschiedene Ursachen zurückgehen.

Das ist der zentrale konzeptionelle Wandel: Autorität ist nicht mehr nur etwas, das ein Subjekt in einem bestimmten Moment besitzt. Wenn sie über eine verteilte Ausführung hinweg propagiert wird, muss sie eine überprüfbare Fortsetzung der Autorität bleiben, die diese spezifische Ausführung verursacht hat—nicht einmalig am Anfang behauptet und dann bis zum Ende als gegeben vorausgesetzt.