AXR/Agent eXecution Receipts/Quelloffen · MIT
AXR ist eine quelloffene Verantwortungsschicht für KI-Agenten und automatisierte Workflows: kryptografisch signierte, manipulationssichere Ausführungsbelege, die „Vertrau mir" in „Prüf es nach" verwandeln. Heute produktiv im Einsatz, stündlich verankert, und von jedem prüfbar, der den öffentlichen Schlüssel hat.
Das Problem
KI-Agenten treffen heute folgenreiche Aktionen: Sie rufen Tools auf, ändern Datensätze, bewegen Geld, senden Nachrichten im Namen anderer. Der Audit-Trail dafür ist meist eine Protokolldatei, die demjenigen gehört, der den Agenten betrieb — veränderbar, löschbar und außerhalb der eigenen Infrastruktur des Betreibers von niemandem prüfbar.
Im Nachhinein gibt es keine verlässliche Möglichkeit, die wichtigen Fragen zu beantworten: welcher Agent tat dies, was erhielt er als Eingabe, was entschied er und auf welcher Grundlage, wurde der Datensatz nachträglich verändert, und warum wurde einem Kunden „nein" gesagt?
Die Regulierung hat es bemerkt. Der EU AI Act macht automatische Ereignisprotokollierung zur Designanforderung für Hochrisiko-KI-Systeme (Artikel 12), verpflichtet Betreiber zur Aufbewahrung (Artikel 26), und seine Hochrisiko-Pflichten gelten ab dem 2. August 2026. In den USA hat das NIST Center for AI Standards and Innovation im Februar 2026 die AI Agent Standards Initiative gestartet, mit Agentensicherheit und -identität als Kernsäulen.
Ein Protokoll, das Sie umschreiben können, ist eine Erzählung. Ein Beleg, den Sie prüfen können, ist ein Nachweis.
Was es ist
Für jede Aktion, die zählt, gibt AXR einen Beleg aus: die durchgeführte Aktion, Hashes ihrer Ein- und Ausgaben, einen Zeitstempel, die Identität des Agenten und eine Ed25519-Signatur über den kanonisierten Datensatz. Es beweist genau eine Sache — dass ein bestimmter Workflow bei einer bestimmten Eingabe eine bestimmte Entscheidung traf und dass der Datensatz sich seither nicht geändert hat.
Das bringt zwei verschiedene Dinge. Manipulationssicherheit ist die kryptografische Grundlinie: die Signatur beweist, dass der Datensatz unverändert ist. Verhaltens-Lesbarkeit ist das, was sich täglich auszahlt — der Beleg macht das tatsächliche Verhalten des Workflows lesbar genug, dass ein interner Widerspruch auch dann auffällt, wenn nichts manipuliert wurde und jede Signatur gültig ist.
Es ist bewusst kein Workflow-Builder, kein Agenten-Framework und keine Observability-Plattform. Es ist die dünne Verantwortungsschicht, die unter diesen Werkzeugen liegt. Zwei Belegtypen tragen die Last: ein Schritt-Beleg erfasst einen einzelnen entscheidungsrelevanten Node, und ein Workflow-Beleg bindet die Schritte eines Laufs zu einem signierten, verketteten Datensatz. Schritte verketten innerhalb eines Laufs; Läufe verketten über die Historie eines Agenten — das Löschen eines Belegs bricht die Kette, das Ändern bricht die Signatur.
Beispielhafter Schritt-Beleg — die Form einer signierten Aktion
{
"axr_version": "0.2.1",
"agent_id": "axr:agent:eco-clean:v5.1",
"step": { "name": "Create Booking", "kind": "side_effecting" },
"io": {
"input_hash": "sha256:9f2c…b41a",
"output_hash": "sha256:1d7e…0c88",
"decision": "BOOKING_CONFIRMED"
},
"logic_version": "5.1",
"logic_hash": "sha256:a3b9…77e2",
"previous_receipt_hash": "sha256:5c10…d9f3",
"timestamp": "2026-06-13T09:14:22Z",
"signature": "ed25519:K8f…/Qb2Aw=="
} Für wen es ist
AXR zahlt sich überall dort aus, wo eine automatisierte Entscheidung später infrage gestellt werden kann und jemand hinter der Antwort stehen muss.
Sie buchen, bepreisen, schreiben Nachrichten, bewegen Geld oder ändern Datensätze im Namen anderer. Heute ist die einzige Aufzeichnung des Geschehenen eine Protokolldatei, die Ihnen gehört und die Sie ändern könnten.
Was Sie bekommen: Ein signierter Beleg pro folgenreicher Aktion — Nachweis, keine änderbare Erzählung.
Artikel 12 macht automatische Ereignisprotokollierung zur Designanforderung für Hochrisiko-Systeme; Artikel 26 verpflichtet Betreiber zur Aufbewahrung, ab dem 2. August 2026.
Was Sie bekommen: Datensätze, die auf diese Pflichten zugeschnitten sind, mit einem auditbereiten Bericht.
Im Nachhinein müssen Sie feststellen, welcher Agent was bei welcher Eingabe tat und ob der Datensatz verändert wurde — ohne dem Betreiber sein Wort zu glauben.
Was Sie bekommen: Offline-Verifizierung aus nichts als einem öffentlichen Schlüssel. Kein Betreiberzugriff nötig.
AXR ist kein Agenten-Framework und keine Observability-Plattform. Es ist die dünne, langweilige Schicht, auf der diese Werkzeuge aufsetzen können — Standard-Krypto, null Abhängigkeiten, MIT.
Was Sie bekommen: Ein eingefrorenes Wire-Format und zwei unabhängige Verifizierer, gegen die Sie bauen.
Die Löschung nach DSGVO Art. 17 scheint einem Append-only-Protokoll zu widersprechen: Wie löscht man personenbezogene Daten aus einem Datensatz, dessen ganzer Sinn es ist, dass er sich nicht ändern kann?
Was Sie bekommen: Feldweise gesalzene Merkle-Commitments — löschen Sie den Klartext, die Signaturen halten.
Ein unabhängiger Monitor macht aus latentem Schutz aktive Erkennung: Equivocation, Trunkierung, Historien-Umschreibungen und unautorisierte Schlüsselwechsel.
Was Sie bekommen: OCSF-förmige Detection Findings und Webhook-Zustellung in Ihr SIEM.
Wie es funktioniert
Der Beleg-Generator ist ein einzelner Code-Node am Ende eines Workflows, vor der Antwort. Er liest die Ausgaben der entscheidungsrelevanten Nodes und erzeugt alle Belege in einem Durchgang. Verankerung und Monitoring laufen außerhalb des Workflows, sodass der Live-Hot-Path keine Latenz und keine neue Abhängigkeit erhält.
Ein Protokoll selbst verifizieren — der ganze Befehl:
# offline, zero dependencies, exit 0 = valid node axr-verify.js receipts.jsonl public-key.pem sth.jsonl anchors.jsonl # the same log, checked by a fully independent Python implementation python3 axr_verify.py receipts.jsonl public-key.pem sth.jsonl anchors.jsonl
Kein Terminal? Ziehen Sie ein Protokoll in den In-Browser-Verifizierer — er führt dieselben Signatur-, Merkle-Root- und Witness-Prüfungen lokal aus, ohne dass etwas hochgeladen wird.
Das Design
Assurance-Arbeit sollte auch von Menschen prüfbar sein, die sie nicht geschrieben haben. Deshalb nutzt AXR nur standardisierte, gut verstandene Bausteine — und benennt seine Ziele klar:
Reifegrad
AXR wird als ein einziges Repo ausgeliefert, das mehrere Reifegrade umfasst. Der Sinn dieser Tabelle ist Ehrlichkeit: Lesen Sie den Grad eines Features, bevor Sie sich darauf verlassen. Das 0.2-Wire-Format ist eingefroren — ältere Protokolle verifizieren Byte für Byte unter dem aktuellen Verifizierer, und alle späteren Arbeiten sind additiv.
| Schicht | Version | Reifegrad |
|---|---|---|
| Kern — Signierung, Verkettung, schrittweises Eingabe-Hashing, kanonisches JSON, Cross-Impl-Parität Produktiv getestet, eingefrorenes Wire-Format; gehärteter n8n-Node. | 0.2.1 | Stabil |
| Verankerung — Merkle-Bündelung, Signed Tree Heads, Monitor, externe Zeitstempelung Stündlicher Verankerungs-Cron produktiv; separater STH-Schlüssel. | 0.3 | Im Einsatz |
| Schwärzbare Belege, Seiteneffekt-Attestierung, Trust-Root, Schlüssel-Rollentrennung Getestet; eingefroren im 1.0-Vertrag. | 0.4 | Stabil |
| Schlüsselnachfolge — root-verankerte Rotation, unterscheidbar von Kompromittierung Cross-Impl-Parität + adversariales Review; vom Piloten noch nicht genutzt. | 0.5 | Stabil |
| SIEM-Export — OCSF-Detection-Finding-Mapping + generischer Webhook OCSF-förmige Ausgabe; bewusst Best-Effort-Zustellung. | 0.6 | Stabil |
| Root-Lebenszyklus-Härtung — Quorum-(M-aus-N)-Root, Rotation, Widerruf, Zeremonie-CLI Cross-Impl-Parität; die Quorum-Policy ist Teil des Bedrohungsmodells. | 0.6 | Stabil |
| Control-Log — verankerte Governance-Verteilung + partielle Offenlegung Schließt die Out-of-Band-Zurückhaltungslücke; 1.5 ergänzt einen Off-Wire-Inclusion-Proof für einen einzelnen Datensatz (einen beweisen, keinen anderen offenlegen). | 0.7 – 1.5 | Stabil |
| Witness-Lebenszyklus — Cosigning, Notfall-Widerruf, temporäre, automatisch ablaufende Aussetzung Präventive Equivocation-Abwehr; der vollständige Slow-Revoke → Revoke → Suspend-Lebenszyklus, cross-impl. | 0.8 – 1.4 | Stabil |
| Bibliotheks-SDK — require('axr'): eine eingefrorene öffentliche API-Fläche + programmatisches verify() Die Fläche ist durch einen Test fixiert; axr.verify() führt den kanonischen Verifizierer aus, kann also nie abweichen. | 1.2 – 1.3 | Stabil |
Nachweis in Produktion
AXR läuft produktiv auf einem echten Buchungs-Workflow für ECO Clean HU — sechs der zwanzig Nodes des Workflows tragen Belege, und das Protokoll — inzwischen über 227 signierte Belege — wird seit Juni 2026 stündlich in einen Merkle-Baum verankert. Der Aufbau dieser Verantwortungsschicht tat etwas, womit ihr Betreiber nicht rechnete: Er brachte vier echte Fehler ans Licht, die AXR vorausgingen, und zwei Defekte in AXRs eigenem Werkzeug.
Keiner davon betraf Manipulation oder eine ungültige Signatur. Sie sind Verhaltens-Lesbarkeit, nicht Manipulationssicherheit: der Beleg machte den Lauf lesbar genug, dass ein Widerspruch zwischen beabsichtigtem und ausgeführtem Zweig von selbst auffiel. Bug B war genau das — eine Ablehnung, die dennoch den Erfolgszweig auslöste, entdeckt in dem Moment, als das Ergebnis des Belegs gelesen wurde.
Jeder Lauf feuerte alle drei Antwortzweige gleichzeitig: eine ZONE_INCOMPATIBLE-Ablehnung sendete trotzdem eine Erfolgs-E-Mail. Der final_status des Belegs machte den Widerspruch sofort sichtbar. Behoben mit einem Switch-Node, der auf das Beleg-Ergebnis routet.
Ablehnungen gaben „unknown_error" zurück und spiegelten die eigene Nachricht des Kunden — der wahre Grund ging verloren. Der Beleg erfasste bei jedem Lauf den korrekten Status, im Widerspruch zu dem, was Kunden erhielten.
Ein Recheck-Konflikt erzeugte einen HTTP 200 mit leerem Body, während der Beleg eine vollständige, signierte 5-Schritt-SLOT_TAKEN-Kette war. Die Lücke zwischen einem korrekten Beleg und einer leeren Antwort ist genau das, wofür AXR gebaut ist.
Nachdem ein Bugfix die Logik auf v5.1 hob, bezeugte jeder Beleg weiterhin v5.0 — gültige Signaturen über eine falsche Behauptung darüber, welcher Code entschied. Jetzt ersetzen Code-Hash-Fingerabdrücke handgeschriebene Etiketten, und die CI scheitert bei Drift. Versionsetiketten sind Aussage; Code-Hashes sind Nachweis.
Ein Sandbox-Probelauf der Verankerungs-Einführung fing zwei von AXRs eigenen Defekten ab, bevor sie das Live-Protokoll berührten: die versionsübergreifende Verankerung hätte jede Legacy-Signatur ungültig gemacht, und der Python-Verifizierer ignorierte still das Separate-Key-Flag. Beide behoben, bevor der erste Produktiv-Anker gesetzt wurde. Ein Probelauf, der in einer Sandbox bricht, ist ein Feature.
Adversarialer Nachweis
Eine Integritätsbehauptung ist nur so viel wert wie die Versuche, sie zu brechen. AXR beweist seine zentrale Behauptung systematisch statt rhetorisch:
Standards & Compliance
AXR ist darauf ausgelegt, auf die kommenden Aufzeichnungspflichten abzubilden — nicht zertifizierte Konformität mit irgendeiner zu behaupten. Artikel 12 des EU AI Act verlangt, dass Hochrisiko-Systeme Ereignisse automatisch zur Rückverfolgbarkeit aufzeichnen, und Artikel 26 verpflichtet Betreiber zur Aufbewahrung. DSGVO Artikel 17 zieht in die andere Richtung, zur Löschung. Die AI Agent Standards Initiative des NIST formt die US-Seite um Identität und Auditierbarkeit. Signierte, unabhängig prüfbare Belege sind ein Primitiv, auf dem jede dieser Richtungen aufbauen kann.
Zwei Bausteine machen das konkret. Schwärzbare Belege lösen die DSGVO-gegen-Append-only-Spannung: sensible Felder werden über einen gesalzenen, feldweisen Merkle-Baum committet, sodass der Klartext später gelöscht werden kann, während die Signatur, die Kette und der bereits verankerte Proof weiterhin halten. Und der Compliance-Report-Generator verwandelt ein rohes Protokoll in einen auditbereiten HTML-Bericht — Integrität, die Schlüssel-Governance-Zeitachse, Verankerungsstatus und ein EU-AI-Act-Art.-12-/DSGVO-Kontroll-Mapping.
Präzision zählt hier: „darauf ausgelegt, abzubilden" ist die Behauptung. Der Bericht ist eine Sicht auf das Urteil des Verifizierers, kein Ersatz dafür, und er behauptet nichts, was er nicht geprüft hat.
Dogfooding
AXR wurde von einer Drei-KI-Werkbank gebaut — Fable, Meridian und NEXUS — über ein gemeinsames, Append-only-Journal. Dieses Journal ist selbst ein prüfbares AXR-Protokoll: jeder Eintrag ist ein Ed25519-signierter Beleg, das gesamte Set ist in einen signierten Tree Head Merkle-verankert, und dieser Tree Head wurde von den zwei Reviewer-Agenten cosigniert — jeder in seinem eigenen Prozess, mit einem Schlüssel, den er selbst erzeugte und hielt, sodass der Orchestrator nie einen privaten Schlüssel sah. Der committete Snapshot verifiziert erneut unter dem vollen 1.0-Stack, in Ihrem Browser.
Ehrliche Einordnung: das beweist, dass das Journal seit der Signierung unverändert ist, nicht dass irgendein Eintrag beim Schreiben wahr war. Die Cosignaturen sind echt prozessunabhängig; die einzige verbleibende Lücke zum vollen Zero-Trust ist, dass die Verwahrung noch auf derselben Maschine liegt — produktiv laufen die Witnesses in getrennten Sicherheitszonen.
Status & Grenzen
AXR ist quelloffen, MIT-lizenziert und wird öffentlich entwickelt. Seit 1.0 sind das Wire-Format und der CLI-/Verifizierer-Vertrag für 1.x eingefroren; 1.1–1.4 fügten nur rückwärtskompatible Datensätze und ein eingefrorenes Bibliotheks-SDK hinzu. Der Kern und die Verankerungsschicht laufen produktiv; die höheren Schichten — Schlüsselnachfolge, Quorum-Roots, das Control-Log und der vollständige Witness-Lebenszyklus (Cosigning, Notfall-Widerruf, temporäre Aussetzung) — sind getestet, cross-impl verifiziert und additiv, aber vom Live-Piloten noch nicht genutzt. Das Projekt bleibt ehrlich über seine eigenen Lücken:
Nachweis
Jeder Deploy von chrisconen.dev veröffentlicht ein Manifest jeder Datei der Website, mit SHA-256 gehasht und mit Ed25519 signiert. Ihr Browser kann die Signatur prüfen und jede Datei gegen das Manifest neu hashen. Es ist AXRs Kernidee, auf eine Build-Pipeline statt auf einen Agenten angewandt — derselbe Beleg, anderer Akteur.