Flight Recorder registrador de vuelo

El problema #

En un análisis posterior, los registros están dispersos; no hay enlace entre una “lectura” y la acción que le siguió; y los registros los puede editar el mismo administrador, o incluso el mismo agente.

Más a fondo: cuando se sospecha que una fusión o un recuerdo están contaminados, no hay forma de responder a “¿qué leyó esa ejecución?”.

Cómo funciona #

• Dos tipos de contenido. Los eventos se registran uno por uno: commits, emisión y revocación de concesiones, solicitudes y decisiones de compuertas, denegaciones de políticas, derivaciones, olvido. El manifiesto de lectura se agrega por ejecución: qué rutas@commit, qué rangos y qué hashes de contenido se leyeron. No registra cada llamada de lectura y nunca registra el contenido.
• Cada commit lleva metadatos de procedencia: principal, on_behalf_of, run, lease, purpose y una referencia al manifiesto de lectura.
• Una cadena de hashes (por día), con firmas y anclaje externo opcionales (un segundo nodo, un bucket con bloqueo de objetos). El objetivo es que “la manipulación se pueda detectar”, no que “la manipulación sea imposible”.
• Exportación: spans de OpenTelemetry GenAI, JSON Lines, o hacia un SIEM.
• Privacidad: por defecto solo metadatos, sin contenido; la retención de los registros es independiente del borrado del contenido; los propios registros tienen control de acceso.
• **explain(commit):** devuelve la ejecución, la concesión, las decisiones de las compuertas, el manifiesto de lectura y las entradas que hay detrás de ese commit.
• Primero se registra, después se actúa: una operación con consecuencias debe escribir antes un registro de intención.

Empezar en pequeño #

• Una tabla SQLite de solo anexado más un hash diario.
• Trailers de Git como Run: y Lease: en cada mensaje de commit.
• Exporta spans de OpenTelemetry a la pila de observabilidad que ya tengas.

Esbozo de la interfaz #

Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación 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..."
}

Lo que pide la especificación #

• Una operación con consecuencias DEBE escribir un registro de intención antes de surtir efecto; si la escritura falla, la operación DEBE fallar.
• Cada ejecución DEBE tener un manifiesto de lectura que registre las rutas, los commits y los rangos leídos (no el contenido).
• Los registros DEBEN estar encadenados por hashes y DEBEN poder verificarse con un comando publicado.
• explain(commit) DEBE devolver la ejecución, la concesión, las decisiones de las compuertas y una referencia al manifiesto de lectura.
• La retención de los registros DEBE ser independiente del borrado del contenido.

Lo prestado y lo nuevo #

Lo que sigue son todo piezas establecidas. Lo nuevo es el manifiesto de lectura: convierte la “lectura” en un conjunto de entradas rastreable, de modo que “una fusión contaminada” y “una memoria envenenada” se puedan investigar a posteriori.

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

Límites honestos #

• Sin anclaje externo, un administrador con root aún puede destruir el registro.
• Los propios registros contienen metadatos sensibles y deben controlarse.
• La granularidad del manifiesto de lectura es un equilibrio entre el coste de almacenamiento y la trazabilidad.

Preguntas abiertas #

• ¿Cómo se mantiene bajo control el coste de almacenamiento de los manifiestos de lectura con un alto rendimiento?
• ¿Cómo se fusionan y se verifican los registros de varios nodos?

Preguntas #

Conceptos relacionados #

• Capability Lease (concesión de capacidad) Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas.
• Trust Labels (etiquetas de confianza) Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two.
• Cascade Forget (olvido en cascada) Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer.