# Flight Recorder (enregistreur de vol)

*Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu.*

> **Un Flight Recorder** est un enregistrement en ajout seul, chaîné par hachage, tenu pour chaque exécution : ce que l’exécution a lu (le manifeste de lecture), ce qu’elle a écrit, ce qui a été autorisé ou refusé, et qui a approuvé quoi. Il se trouve à côté des données et répond à une seule question : « qu’est-ce qui a pu influencer ce changement ? »

**AN-03** · Niveau de conformité : L1 Authority · Groupe : Travail

## 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.

*record.json*

```json
{
  "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](https://opentelemetry.io/docs/specs/semconv/gen-ai/)
- [Certificate Transparency](https://certificate.transparency.dev)
- [Sigstore Rekor](https://docs.sigstore.dev/logging/overview/)
- [Git trailers](https://git-scm.com/docs/git-interpret-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

### Enregistre-t-il le contenu que l’agent a lu ?

Pas par défaut. Un enregistrement contient des chemins, des commits, des plages et des hachages de contenu : de quoi pointer vers les données d’origine sans copier de contenu sensible dans un journal. Le contenu reste dans le Store, protégé par des habilitations et des étiquettes.

### Que veut dire « à détection d’altération » ici ?

Nous promettons seulement que **la falsification est détectable** : les enregistrements sont chaînés par hachage, donc en modifier un casse la vérification de la chaîne ; avec un ancrage externe (un second nœud ou un bucket avec verrouillage d’objets), cela tient aussi face à un administrateur root. Sans ancrage, un administrateur peut quand même détruire tout le journal.

### Pourquoi enregistrer les lectures ?

Parce que le risque vient souvent de la lecture : une session qui a lu une page web peut ensuite écrire une note contaminée. Le manifeste de lecture permet de répondre après coup à « qu’est-ce qui a influencé ce changement ? »

## Concepts liés

- [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): 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)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two.
- [Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/): 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.

---

URL canonique : https://agentnas.com/fr/concepts/flight-recorder/
Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0
