Un audit log per un agente di coding condiviso è un registro append-only con una riga per richiesta e una riga per approvazione, conservato dal proprietario della macchina ed esportabile da quest'ultimo. Risponde a posteriori a chi ha chiesto all'agente di fare cosa, chi lo ha autorizzato, cosa è stato effettivamente eseguito e quanto è costato. Se l'agente viene usato esclusivamente dal suo proprietario, la trascrizione del runtime è sufficiente. Nel momento in cui una seconda persona può inviare richieste, non lo è più.
Questo post elenca i campi, nell'ordine in cui servono a chi legge, e poi gli elementi che devono restarne fuori.
La riga della richiesta
Ogni richiesta produce esattamente una riga quando raggiunge uno stato terminale.
La riga dell'approvazione
Le approvazioni hanno una propria riga perché sono decisioni, e le decisioni hanno lettori diversi rispetto alle esecuzioni.
Righe di richiesta e righe di approvazione, con un push approvato in ambra e un'eliminazione scaduta in rosso.
Cosa non deve comparire nel log
- Segreti. L'approvazione di una credenziale registra che è stato eseguito l'accesso a una chiave, non la chiave stessa.
- Contenuto dei file. I diff sono percorsi e conteggi di righe. La modifica si trova nel repository, dove si applica il controllo di accesso del repository stesso.
- Output completo dei comandi. La parte finale è sufficiente per spiegare un fallimento. I log completi possono contenere qualsiasi cosa.
- Altre stanze. Il log di ciascuna stanza è limitato a quella stanza. Il proprietario ha visibilità su tutte le stanze; i membri vedono la propria stanza.
Proprietà, non solo campi
Append-only. Nessuno modifica il log, compreso il proprietario. Le correzioni sono nuove righe.
Conservato dal proprietario. La persona sulla cui macchina è stato eseguito il lavoro conserva il registro e può esportarlo. Chi invia richieste vede le proprie righe nella stanza.
Completo anche in caso di revoca. Revocare un'autorizzazione o una macchina annulla il lavoro in coda e lascia completare quello in esecuzione, evitando vuoti nel log in cui “qualcosa è stato eseguito ma abbiamo smesso di monitorare”.
Azioni del proprietario incluse. Il proprietario non è soggetto ad approvazioni sul proprio agente, ma le sue richieste vengono registrate allo stesso modo. Un log che registra solo gli esterni registra solo metà del rischio.
Leggere il log
Tre domande emergono più spesso, e i campi sopra rispondono a ciascuna con un solo filtro.
- “Chi ha fatto quel push?” Filtra le righe di approvazione per regola = push, leggi chi ha fatto la richiesta e chi ha deciso.
- “Perché questa richiesta ha richiesto un'ora?” Confronta creata e avviata; l'attesa dell'approvazione di solito è la risposta.
- “Quanto è costato prestare il mio agente questo mese?” Somma l'utilizzo sulle righe di richiesta in cui chi ha fatto la richiesta non è il proprietario.
Domande frequenti
La timeline della stanza è l'audit log? La timeline è la registrazione dettagliata e leggibile da un essere umano di una singola esecuzione. L'audit log è il riepilogo riga per riga di ogni evento tra le varie esecuzioni, progettato per filtri ed esportazione. muti conserva entrambi; il log è ricavato dagli stessi eventi che il daemon carica. Vedi cosa carica il daemon.
Per quanto tempo viene conservato? Le righe di richiesta e approvazione vengono conservate per l'intera durata della stanza. L'eliminazione di una stanza è un soft-delete; il registro rimane a disposizione del proprietario.
Chi fa una richiesta può vedere le righe degli altri? Vede la timeline della stanza, che include le richieste di tutti in quella stanza. L'esportazione è riservata al proprietario.
Le richieste del proprietario hanno bisogno di approvazione per essere registrate? No. Le esecuzioni del proprietario vengono registrate senza approvazioni, con regola = proprietario.
Il log è ciò che rende “puoi revocarlo in seguito” una vera promessa. Crea una stanza per il tuo agente e ne avrà uno incluso.
Pubblicato il