Flight Recorder enregistreur de vol

Le problème #

Lors d’un post-mortem, les journaux sont dispersés ; il n’y a aucun lien entre une « lecture » et l’action qui l’a suivie ; et les journaux peuvent être modifiés par le même administrateur, voire par le même agent.

Plus fondamentalement : quand une fusion ou un souvenir est soupçonné d’être contaminé, il n’y a aucun moyen de répondre à « qu’a lu cette exécution ? »

Fonctionnement #

• Deux sortes de contenu. Les événements sont enregistrés un par un : commits, émission et révocation d’habilitations, demandes et décisions de validation, refus de politique, dérivations, oubli. Le manifeste de lecture est agrégé par exécution : quels chemins@commit, quelles plages et quels hachages de contenu ont été lus. Il n’enregistre pas chaque appel de lecture, et il n’enregistre jamais le contenu.
• Chaque commit porte des métadonnées de provenance : principal, on_behalf_of, run, lease, purpose et une référence au manifeste de lecture.
• Une chaîne de hachage (par jour), avec des signatures et un ancrage externe facultatifs (un second nœud, un bucket avec verrouillage d’objets). L’objectif est que « la falsification soit détectable », et non qu’elle soit impossible.
• Export : spans OpenTelemetry GenAI, JSON Lines, ou vers un SIEM.
• Vie privée : métadonnées seulement par défaut, pas de contenu ; la rétention des enregistrements est indépendante de la suppression du contenu ; les enregistrements eux-mêmes sont à accès contrôlé.
• **explain(commit) :** renvoie l’exécution, l’habilitation, les décisions de validation, le manifeste de lecture et les entrées derrière ce commit.
• Enregistrer d’abord, agir ensuite : une opération à conséquences doit d’abord écrire un enregistrement d’intention.

Commencer petit #

• Une table SQLite en ajout seul plus un hachage quotidien.
• Des trailers Git comme Run: et Lease: dans chaque message de commit.
• Exporter des spans OpenTelemetry vers la pile d’observabilité que vous avez déjà.

Esquisse d’interface #

À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3.

{
  "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..."
}

Ce que demande la spécification #

• Une opération à conséquences DOIT écrire un enregistrement d’intention avant de prendre effet ; si l’écriture échoue, l’opération DOIT échouer.
• Chaque exécution DOIT avoir un manifeste de lecture consignant les chemins, commits et plages lus (pas le contenu).
• Les enregistrements DOIVENT être chaînés par hachage et DOIVENT être vérifiables avec une commande publiée.
• explain(commit) DOIT renvoyer l’exécution, l’habilitation, les décisions de validation et une référence au manifeste de lecture.
• La rétention des enregistrements DOIT être indépendante de la suppression du contenu.

Ce qui est emprunté, et ce qui est nouveau #

Tout ce qui précède, ce sont des briques établies. Ce qui est nouveau, c’est le manifeste de lecture : il fait de la « lecture » un ensemble d’entrées traçable, de sorte que « une fusion contaminée » et « une mémoire empoisonnée » peuvent être examinées après coup.

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

Limites assumées #

• Sans ancrage externe, un administrateur root peut quand même détruire le journal.
• Les enregistrements eux-mêmes contiennent des métadonnées sensibles et doivent être contrôlés.
• La granularité du manifeste de lecture est un compromis entre coût de stockage et traçabilité.

Questions ouvertes #

• Comment maîtriser le coût de stockage des manifestes de lecture à fort débit ?
• Comment fusionner et vérifier les enregistrements de plusieurs nœuds ?

Questions #

Concepts liés #

• Capability Lease (habilitation de capacité) Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites.
• Trust Labels (étiquettes de confiance) Deux petites étiquettes plus la contamination de session appliquent la Rule of Two.
• Cascade Forget (oubli en cascade) Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait.