AXR/Agent eXecution Receipts/Quelloffen · MIT
AXR ist eine quelloffene Rechenschaftsschicht für KI-Agenten und automatisierte Workflows: kryptografisch signierte, manipulationsnachweisbare 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 Entscheidungen: Sie rufen Tools auf, ändern Datensätze, bewegen Geld, senden Nachrichten im Namen anderer. Der Audit-Trail dafür ist meist eine Log-Datei, die demjenigen gehört, der den Agenten betreibt — veränderbar, löschbar und außerhalb der Infrastruktur des Betreibers für niemanden prüfbar.
Im Nachhinein lassen sich die entscheidenden Fragen nicht verlässlich beantworten: welcher Agent hat gehandelt, was bekam er als Eingabe, was hat er auf welcher Grundlage entschieden, 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 Log, 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. Er beweist genau eine Sache — dass ein bestimmter Workflow bei einer bestimmten Eingabe eine bestimmte Entscheidung getroffen hat und dass sich der Datensatz seither nicht geändert hat.
Das bringt zwei verschiedene Dinge. Manipulationsnachweisbarkeit ist die kryptografische Grundlinie: die Signatur beweist, dass der Datensatz unverändert ist. Verhaltensnachvollziehbarkeit ist das, was sich Tag für Tag auszahlt — der Beleg macht das tatsächliche Verhalten des Workflows so nachvollziehbar, dass ein interner Widerspruch selbst 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 schmale Rechenschaftsschicht, die unter diesen Werkzeugen liegt. Zwei Belegtypen tragen die Last: ein Schrittbeleg erfasst einen einzelnen entscheidungsrelevanten Knoten, und ein Workflow-Beleg bindet die Schritte eines Laufs zu einem signierten, verketteten Datensatz. Schritte verketten sich innerhalb eines Laufs; Läufe verketten sich über die Historie eines Agenten — das Löschen eines Belegs bricht die Kette, das Ändern bricht die Signatur.
Beispielhafter Schrittbeleg — 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 bewährt sich überall dort, wo eine automatisierte Entscheidung später infrage gestellt werden kann und jemand für die Antwort einstehen muss.
Sie buchen, bepreisen, schreiben Nachrichten, bewegen Geld oder ändern Datensätze im Namen anderer. Heute ist die einzige Aufzeichnung des Geschehenen eine Log-Datei, 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 schmale, unspektakuläre 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-Log zu widersprechen: Wie löscht man personenbezogene Daten aus einem Datensatz, dessen ganzer Sinn darin besteht, 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-Knoten am Ende eines Workflows, vor der Antwort. Er liest die Ausgaben der entscheidungsrelevanten Knoten und erzeugt alle Belege in einem Durchgang. Verankerung und Monitoring laufen außerhalb des Workflows, sodass der Produktionspfad keine zusätzliche Latenz und keine neue Abhängigkeit erhält.
Ein Log 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 Log 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 Reifestufen umfasst. Der Sinn dieser Tabelle ist Ehrlichkeit: Lesen Sie die Stufe eines Features, bevor Sie sich darauf verlassen. Das 0.2-Wire-Format ist eingefroren — ältere Logs 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-Knoten. | 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 Knoten des Workflows tragen Belege, und das Log — inzwischen über 227 signierte Belege — wird seit Juni 2026 stündlich in einem Merkle-Baum verankert. Der Aufbau dieser Rechenschaftsschicht bewirkte etwas, womit der Betreiber nicht gerechnet hatte: 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. Es geht um Verhaltensnachvollziehbarkeit, nicht um Manipulationsnachweisbarkeit: der Beleg machte den Lauf so nachvollziehbar, 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-Knoten, 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-Log 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.
Angreifertest
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 kommende Aufzeichnungspflichten abzubilden — nicht darauf, zertifizierte Konformität mit irgendeiner davon 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 rund um Identität und Auditierbarkeit. Signierte, unabhängig prüfbare Belege sind ein Grundbaustein, 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 Log 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 einem Drei-KI-Setup gebaut — Fable, Meridian und NEXUS — über ein gemeinsames, append-only Journal. Dieses Journal ist selbst ein prüfbares AXR-Log: 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.