Zum Inhalt springen

Aufzeichnung privilegierter Sessions

Recording (modules/recording) ist die Ebene für die Aufzeichnung privilegierter Sessions — die PAM-konforme Kontrolle, die Käufer mit hohen Sicherheitsanforderungen für Konsolen und Notfallzugriff erwarten. Sie erfasst als strukturierte Evidenz, was eine privilegierte Operator-Session tatsächlich auf den sensibelsten Moduloberflächen getan hat, und bindet diese Evidenz an das manipulationsevidente Audit-Ledger, sodass sie nachträglich nicht umgeschrieben werden kann. Reife: LIVE.

Eine Recording-Session ist das privilegierte Fenster eines Credentials — die Login-Session eines menschlichen Operators oder ein Service-Token auf der Break-Glass-Ebene — innerhalb eines Tenants. Ihre Frames sind eine append-only Spur (Unveränderlichkeitsschutz auf DB-Ebene), ein Frame pro Modul-Routen-Aktion auf einer aufgezeichneten Oberfläche: wer, wann, die Routen-Gestalt und Berechtigung, bereinigte Ziel-Identifikatoren, Delegation, das Ergebnis und ein Einweg-SHA-256 des Request-Bodys. Frames sind strukturierte Aktionsereignisse, niemals Transkripte oder Bodies — Parameterwerte durchlaufen beim Schreiben eine beschränkte Maskierungsroutine, sodass ein E-Mail- oder credential-förmiger Wert nie persistiert wird.

Die Erfassung sitzt am Modul-Routen-Wrapper der Engine und ist deny-closed: auf einer aufgezeichneten Oberfläche bedeutet keine anfügbare Evidenz keine privilegierte Aktion. Der aufgezeichnete Umfang ist jede Break-Glass-Route für jeden Principal (die verpflichtende, nicht konfigurierbare Untergrenze) plus die pro Tenant konfigurierten privilegierten Namespaces.

Die Frames jeder Session sind hash-verkettet, und die Kettenspitze ist per PayloadHash in das signierte Audit-Ledger verankert — ein Open-Event beim Session-Start, periodische Anker während des Laufs und ein Seal beim Schließen. Das Umschreiben irgendeines Frames bricht sowohl die Session-Kette als auch ihre versiegelten Ledger-Anker. GET /sessions/{id}/verify berechnet die Kette neu und prüft jeden Anker; GET /sessions/{id}/replay rekonstruiert die menschenlesbare Timeline, korreliert mit dem Ledger-Fenster der Session. Die Oberfläche wurzelt unter /v1/m/recording/ (sessions, replay, verify, seal, config, ack).

  • Es zeichnet Modulrouten (/v1/m/<ns>) auf; die Core-/v1-Oberflächen sind ledger-auditiert, aber nicht frame-aufgezeichnet — Replay korreliert sie stattdessen über das Ledger-Fenster der Session.
  • Bei einer aktiven Session sind Frames nach dem letzten periodischen Anker nur durch die Kettenspitze gebunden, bis zum nächsten Anker oder Seal; verify meldet anchored_through, sodass die Grenze explizit und nie impliziert ist.
  • Es implementiert kein Purge und kein Legal-Hold — Retention/Legal-Hold besitzt die Löschung; Ledger-Anker überleben jedes Purge.
  • Dies ist das Recording-Subsystem, das das agentops-Governance-Panel für die I/O-Aufzeichnung pro Session nutzt: jeder gebrückte Claude-Code-Frame wird in dasselbe hash-verkettete, ledger-verankerte Muster eingefaltet.
  • Sicherheit — die umgebende Sicherheits- und Datenschutzebene (Guardrails, DLP, Retention, Residency).
  • Sessions — beherbergt die geregelte Claude-Code-Session-Runtime, deren I/O pro Session dieses Subsystem aufzeichnet.
  • Ehrlichkeit und Grenzen — die Posture live / on-demand / deny-closed über die Engine hinweg.