Zusammenfassung

  • Revision 09 kann nachweisen, dass alle sichtbaren Ausführungsbelege eine geordnete, intern konsistente Kette bilden. Wer Einträge an den Rändern entfernen und die Links neu berechnen kann, kann dennoch eine kürzere gültige Kette vorlegen.
  • Das optionale externe Commitment bindet Job-ID, Digest des letzten Eintrags, Anzahl und Veröffentlichungszeit. Die Anzahl allein schützt den letzten Eintrag nicht; auch ein korrektes Commitment beweist keine Handlung außerhalb des Beobachtungsbereichs.

Eine formal geschlossene Kette beantwortet jede interne Prüffrage. Die Folge beginnt bei eins, hat keine Lücke und verwendet durchgehend dieselbe Job-ID. Jeder prev_digest stimmt mit dem neu berechneten Digest seines Vorgängers überein. Nur der letzte Eintrag trägt close:true. Auch die kanonischen Belegdaten passen.

Offen bleibt eine andere Frage: Wer kannte diesen Endpunkt bereits, bevor die Prüfung begann?

Ohne unabhängige Antwort könnten aus acht Einträgen sechs geworden sein. Der Präsentierende entfernt den Rand, baut die überlebenden Links neu und reicht eine vollständig gültige kürzere Geschichte ein. Revision 09 von AER-1: A Portable Execution Receipt for AI Agent Tool Calls beschreibt dies ausdrücklich als ehrliche Grenze der Hash-Verkettung. Es ist kein Bruch von SHA-256.

Das Dokument wurde am 1. Oktober 2026 als aktiver individueller Internet-Draft veröffentlicht. Datatracker weist darauf hin, dass solche Einreichungen nicht vom IETF gebilligt sind und keinen formalen Rang im Standardisierungsverfahren haben. Dort sind weder RFC-Stream noch beabsichtigter RFC-Status verzeichnet; der Text selbst nennt Independent Submission und Informational als Ziel. Er läuft am 1. April 2027 aus und ist kein RFC.

Was intern festgelegt wird

Eine Job-Zeitleiste besteht aus einem nicht leeren Array. Jeder Eintrag führt vorherigen Digest, Sequenz, Job- und Beleg-ID, Werkzeug, Provenienzklasse, kanonische Belegbytes, Ausgabe-Hash und optionalen Schlussstatus.

Der Prüfer übernimmt gespeicherte Links nicht ungeprüft. Er dekodiert den Beleg, kontrolliert dessen Hash, kanonisiert ein JSON-Objekt aus close, id, job_id, output_hash, prev_digest, provenance_class, seq und tool und berechnet SHA-256. Die Genesis verweist auf 64 Nullen. Die Folge startet bei eins und steigt jeweils um eins. Alle Einträge gehören zu einem Job; nur der letzte darf und muss schließen.

Auch die Konstruktionsversion gehört zur Evidenz. Revision 06 band lediglich die dekodierten kanonischen Belegbytes. Revision 07 nahm die kontextgebenden Metadaten in das Commitment auf; 08 und 09 behalten diese Konstruktion. Eine alte 06-Kette erhält keine rückwirkende Sicherheit, nur weil heutige Software sie mit jüngeren Erwartungen liest.

Innerhalb dieser Grenze ist die Wirkung klar. Wer Werkzeug, Provenienz, ID, Ausgabe-Commitment, Job, Reihenfolge oder Schlussstatus ändert, ohne den abhängigen Rest neu zu bilden, erzeugt am nächsten Glied einen Fehler. Einfügen, Löschen, Umordnen und Umbenennen werden sichtbar, sofern der Handelnde die Folgekette nicht neu erzeugen kann.

Dieses „sofern“ ist die eigentliche Kontrollgrenze.

Ein neuer Schluss kann völlig korrekt aussehen

Bei acht Einträgen lassen sich sieben und acht entfernen. Der sechste wird zum Schluss erklärt und sein Digest neu berechnet. Es gibt keinen siebten Eintrag mehr, der den alten Digest des sechsten festhält. Die neue Sechserkette erfüllt sämtliche internen Regeln. Ebenso kann ein Präfix verschwinden und der Rest mit neuer Genesis wieder bei eins beginnen.

Der Draft verbietet deshalb, die Kettenprüfung allein als truncation-proof darzustellen. Nötig ist ein Commitment außerhalb der Kette: ein Zeuge, ein zeitgestempelter Kopf, ein Anker oder ein Workflow-Manifest mit erwarteten Schritten beziehungsweise erwarteter Anzahl.

Revision 08 empfahl bereits, den finalen Digest zu binden. Revision 09 definiert ein optionales interoperables Artefakt mit job_id, final_entry_digest, entry_count und published_at. Es muss außerhalb liegen. Im letzten Eintrag wäre es zirkulär, weil dessen endgültiger Digest erst nach Fertigstellung des Eintrags entsteht.

Der Prüfer berechnet den sichtbaren End-Digest neu, zählt, prüft die Job-ID und vergleicht alles mit dem separat abgerufenen Artefakt. Bei Übereinstimmung ist belegt, dass die sichtbare Kette den Endpunkt erreicht, den der Zeuge zu diesem Zeitpunkt veröffentlicht hatte.

Die Anzahl lässt das letzte Wort offen

Ein Commitment auf acht Einträge erkennt die Verkürzung auf sechs. Es erkennt nicht zwingend, wenn der achte Eintrag ausgetauscht und die Anzahl acht beibehalten wird.

Jeder Digest außer dem letzten wird noch einmal vom prev_digest des Nachfolgers gebunden. Für den finalen Digest existiert intern kein Nachfolger. Der letzte Eintrag kann ersetzt und neu gehasht werden, ohne die Anzahl zu verändern. Ein reines Zähl-Commitment bleibt zufrieden; ein extern gebundener End-Digest nicht.

Die vier Felder erfüllen verschiedene Aufgaben. Anzahl begrenzt Länge, Digest begrenzt den sichtbaren Endinhalt, Job-ID verhindert das Übernehmen eines fremden Kopfes, Veröffentlichungszeit datiert die Referenz. Zusätzlich müssen Identität des Zeugen, Abrufweg, Abrufzeit und Ergebnis erhalten bleiben. Liegen Kette und Commitment unter derselben veränderlichen Hoheit, sind zwei Dateien noch keine zwei Vertrauensdomänen.

Ein Anker erweitert keinen Sensor

Externe Verankerung stärkt Kontinuität, nicht Beobachtungsumfang. Ein gültiger Beleg-Hash bestätigt die aufgezeichneten Bytes. LOGGED BY AGENT bleibt ein Bericht des Agenten; die Verkettung macht daraus keine unabhängige Messung.

Unsichtbar bleiben Werkzeugaufrufe, die den Recorder nie erreichten, Seitenkanäle, nicht erfasste Autorisierung sowie Zahlungen, Lieferungen oder Konfigurationsänderungen, die ein anderes System besitzt. Bei folgenreichen Jobs muss die Organisation vorher die autorisierten oder erwarteten Handlungen einfrieren, sie anschließend mit den Belegen abgleichen und den tatsächlichen Effekt beim zuständigen System bestätigen lassen.

Geschlossene Zeitleiste, bezeugter Endpunkt, vollständige Abdeckung und externer Erfolg sind getrennte Urteile. Die gemeinsame Schicht sollte schmal bleiben: Format, Ordnung und reproduzierbare Commitments. Zuständigkeit für Vollständigkeit und Folgen darf nicht unbemerkt in das Format wandern.