Flight Recorder Flugschreiber

Das Problem #

Bei einer Nachanalyse sind die Logs verstreut; zwischen einem „Lesen“ und der Aktion, die darauf folgte, gibt es keine Verbindung; und Logs kann derselbe Administrator ändern, oder sogar derselbe Agent.

Grundsätzlicher: Wenn der Verdacht besteht, dass ein Merge oder eine Erinnerung kontaminiert ist, lässt sich „Was hat diese Ausführung gelesen?“ nicht beantworten.

So funktioniert es #

• Zwei Arten von Inhalt. Ereignisse werden einzeln aufgezeichnet: Commits, Ausstellung und Widerruf von Leases, Gate-Anfragen und -Entscheidungen, Richtlinienablehnungen, Ableitungen, Vergessen. Das Lesemanifest wird pro Ausführung aggregiert: welche Pfade@Commit, welche Bereiche und welche Inhalts-Hashes gelesen wurden. Es zeichnet nicht jeden einzelnen Lesezugriff auf und nie den Inhalt.
• Jeder Commit trägt Provenienz-Metadaten: principal, on_behalf_of, run, lease, purpose und einen Verweis auf das Lesemanifest.
• Eine Hash-Kette (pro Tag), mit optionalen Signaturen und externer Verankerung (ein zweiter Knoten, ein Bucket mit Object Lock). Das Ziel ist „Manipulation lässt sich erkennen“, nicht „Manipulation ist unmöglich“.
• Export: OpenTelemetry-GenAI-Spans, JSON Lines oder in ein SIEM.
• Datenschutz: standardmäßig nur Metadaten, keine Inhalte; die Aufbewahrung von Records ist unabhängig vom Löschen von Inhalten; die Records selbst sind zugriffsgeschützt.
• **explain(commit):** liefert Ausführung, Lease, Gate-Entscheidungen, Lesemanifest und Eingaben hinter diesem Commit.
• Erst protokollieren, dann handeln: Eine folgenreiche Operation muss zuerst einen Absichtseintrag schreiben.

Klein anfangen #

• Eine Append-only-SQLite-Tabelle plus ein täglicher Hash.
• Git-Trailer wie Run: und Lease: in jeder Commit-Nachricht.
• Exportieren Sie OpenTelemetry-Spans in den Observability-Stack, den Sie bereits haben.

Schnittstellenskizze #

Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern.

{
  "seq": 18211,
  "time": "2026-11-12T09:14:22Z",
  "kind": "commit",
  "run": "run_91ab",
  "principal": "agt_cleo",
  "on_behalf_of": "usr_wei",
  "lease": "lse_7Qk3",
  "purpose": "Draft the Q4 release notes",
  "subject": { "path": "/shared/launch/notes.md", "commit": "91ce3a7" },
  "read_manifest": "rm_5d2e",
  "decision": { "effect": "allow", "rule": "r-17" },
  "taint": { "external": true, "sensitivity": "private" },
  "prev_hash": "sha256:b3a0..."
}

Was die Spezifikation verlangt #

• Eine folgenreiche Operation MUSS einen Absichtseintrag schreiben, bevor sie wirksam wird; schlägt das Schreiben fehl, MUSS die Operation fehlschlagen.
• Jede Ausführung MUSS ein Lesemanifest haben, das die gelesenen Pfade, Commits und Bereiche aufzeichnet (nicht den Inhalt).
• Records MÜSSEN per Hash verkettet sein und MÜSSEN mit einem veröffentlichten Befehl prüfbar sein.
• explain(commit) MUSS die Ausführung, die Lease, die Gate-Entscheidungen und einen Verweis auf das Lesemanifest liefern.
• Die Aufbewahrung von Records MUSS vom Löschen von Inhalten unabhängig sein.

Was übernommen ist und was neu ist #

Alles Folgende sind etablierte Bausteine. Neu ist das Lesemanifest: Es macht aus „Lesen“ eine nachvollziehbare Menge von Eingaben, sodass sich „ein kontaminierter Merge“ und „vergiftetes Gedächtnis“ im Nachhinein untersuchen lassen.

• OpenTelemetry GenAI conventions
• Certificate Transparency
• Sigstore Rekor
• Git trailers

Ehrliche Grenzen #

• Ohne externe Verankerung kann ein Administrator mit root das Protokoll weiterhin zerstören.
• Die Records selbst enthalten sensible Metadaten und müssen kontrolliert werden.
• Die Granularität des Lesemanifests ist ein Kompromiss zwischen Speicherkosten und Nachvollziehbarkeit.

Offene Fragen #

• Wie bleiben die Speicherkosten von Lesemanifesten bei hohem Durchsatz beherrschbar?
• Wie werden Records mehrerer Knoten zusammengeführt und geprüft?

Fragen #

Verwandte Konzepte #

• Capability Lease (befristete Berechtigung) Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein.
• Trust Labels (Vertrauenslabels) Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch.
• Cascade Forget (kaskadierendes Vergessen) Ableitungen entlang der Lineage löschen, den Verlauf nach Aufbewahrungsklasse behandeln und melden, was nicht möglich war.