Ein Audit-Log für einen geteilten Coding-Agent ist ein Append-only-Protokoll mit einer Zeile pro Request und einer Zeile pro Approval, das beim Besitzer der Maschine liegt und von ihm exportiert werden kann. Es beantwortet im Nachhinein, wer den Agenten gebeten hat, was zu tun, wer es erlaubt hat, was tatsächlich lief und was es gekostet hat. Wird der Agent ausschließlich von seinem Besitzer genutzt, reicht das eigene Transkript der runtime völlig aus. Sobald jedoch eine zweite Person Requests senden kann, genügt das nicht mehr.
Dieser Beitrag listet die Felder in der Reihenfolge auf, in der man sie braucht, und zeigt anschließend, was keinesfalls hineingehört.
The request line
Jeder Request erzeugt genau eine Zeile, sobald er einen finalen Zustand erreicht.
The approval line
Approvals erhalten eine eigene Zeile, weil es Entscheidungen sind – und Entscheidungen haben andere Leser als Programmdurchläufe.
Request-Zeilen und Approval-Zeilen, mit einem freigegebenen Push in Bernstein und einer abgelaufenen Löschung in Rot.
What must not be in the log
- Secrets. Ein Credential-Approval zeichnet auf, dass auf einen Schlüssel zugegriffen wurde, nicht den Schlüssel selbst.
- File contents. Diffs bestehen aus Pfaden und Zeilenzahlen. Die Änderung liegt im Repository, wo dessen eigene Zugriffskontrolle greift.
- Full command output. Der Tail reicht aus, um einen Fehler zu erklären. Vollständige Logs können alles Mögliche enthalten.
- Other rooms. Das Log jedes Raums ist auf diesen Raum beschränkt. Der Besitzer sieht raumübergreifend alles; Mitglieder sehen nur ihren Raum.
Properties, not just fields
Append-only. Niemand bearbeitet das Log, auch nicht der Besitzer. Korrekturen sind neue Zeilen.
Owner-held. Die Person, auf deren Maschine die Arbeit lief, behält das Protokoll und kann es exportieren. Anfragende sehen ihre eigenen Zeilen im Raum.
Complete under revocation. Wird eine Berechtigung oder eine Maschine widerrufen, bricht dies Arbeit in der Warteschlange ab und lässt laufende Arbeit zu Ende laufen. So entsteht im Log nie eine Lücke, in der „etwas lief, wir aber nicht mehr hingeschaut haben“.
Owner actions included. Der Besitzer benötigt für seinen eigenen Agenten keine Approvals, aber seine Requests werden genauso protokolliert. Ein Log, das nur Außenstehende erfasst, deckt nur das halbe Risiko ab.
Reading the log
Drei Fragen tauchen am häufigsten auf, und die obigen Felder beantworten jede davon mit einem einzigen Filter.
- „Wer hat das gepusht?“ Approval-Zeilen nach rule = push filtern, who asked und who decided lesen.
- „Warum hat dieser Request eine Stunde gedauert?“ Erstellungs- und Startzeit vergleichen; die Approval-Wartezeit liefert meist die Antwort.
- „Was hat das Verleihen meines Agenten diesen Monat gekostet?“ Die Nutzung in Request-Zeilen summieren, bei denen who asked nicht der Besitzer ist.
Frequently asked questions
Is the room timeline the audit log? Die Timeline ist das detaillierte, menschenlesbare Protokoll eines einzelnen Laufs. Das Audit-Log ist die Zusammenfassung über alle Läufe hinweg mit einer Zeile pro Ereignis, ausgelegt für Filterung und Export. muti behält beides; das Log wird aus denselben Ereignissen abgeleitet, die der daemon hochlädt. Siehe was der daemon hochlädt.
How long is it kept? Request- und Approval-Zeilen bleiben für die Lebensdauer des Raums erhalten. Das Löschen eines Raums ist ein Soft-Delete; das Protokoll bleibt für den Besitzer bestehen.
Can a requester see other people’s lines? Sie sehen die Timeline des Raums, die die Requests aller Personen in diesem Raum enthält. Der Export bleibt dem Besitzer vorbehalten.
Do owner requests need approval to be logged? Nein. Läufe des Besitzers werden ohne Approvals protokolliert, mit rule = owner.
Das Log macht „du kannst es später widerrufen“ zu einem echten Versprechen. Gib deinem Agenten einen Raum und er bringt eines mit.
Veröffentlicht am