La maggior parte dei sistemi di permessi per gli agenti di programmazione sono allowlist: leggere file sì, scrivere file sì, eseguire test sì, per tutto il resto chiedere. Funziona finché qualcuno non contrassegna un agente come "completamente fidato" per interrompere i prompt, e l'agente esegue git push --force di venerdì.
La nostra posizione è che quattro categorie di azioni dovrebbero fermarsi per un umano ogni singola volta, indipendentemente da quanto sia fidato l'agente o chi ha fatto la richiesta. I livelli di fiducia decidono quante altre cose richiedono approvazione. Queste quattro non sono mai silenziose.
Le quattro azioni
1. Fare push su un branch condiviso. Un commit su un feature branch è un suggerimento. Un push su main o release è una decisione ereditata dall'intero team, spesso con un deploy collegato. Chiedere costa poco; tornare indietro costa molto.
2. Eliminare. File, branch, tabelle, bucket, risorse. L'eliminazione è l'unica operazione in cui un errore di interpretazione delle intenzioni non può essere annullato da un secondo tentativo. Gli agenti sono sicuri di sé, e l'eliminazione eseguita con sicurezza è il modo in cui vengono testati i backup.
3. Spendere soldi. Chiamare un'API a pagamento, allocare una risorsa, acquistare un dominio, inviare una campagna. La persona che ha fatto la richiesta potrebbe non sapere che comporta un costo. Chi paga dovrebbe saperlo.
4. Toccare credenziali. Leggere un file di chiavi, esportare variabili d'ambiente, accedere a un servizio, completare l'autenticazione a due fattori. Tutto ciò che tocca questo ambito riguarda l'identità, e l'identità appartiene al proprietario della macchina, non a chiunque si trovi nella stanza.
Perché "pienamente fidato" dovrebbe comunque fermarsi qui
Una modalità di autorizzazione descrive la relazione di una persona con l'agente: sola lettura, modifica senza push, fiducia totale. È la granularità giusta per le centinaia di chiamate ordinarie che un agente effettua in una sessione. È la granularità sbagliata per le quattro azioni sopra indicate, perché sono rare, irreversibili o costose, e perché il costo ricade su qualcuno diverso da chi ha fatto la richiesta.
Quindi la regola in muti è semplice: nessun template di permessi può impostare queste quattro azioni per l'esecuzione silenziosa. Anche in modalità "fiducia totale" si fermano e vengono evidenziate nella timeline. Il prompt è abbastanza raro da non risultare fastidioso e le categorie sono abbastanza precise da rendere la risposta solitamente ovvia.
Come questo si mappa sulle modalità di autorizzazione di Claude Code
Claude Code ha già una scala graduale: plan (sola lettura), default (chiede prima di modifiche e comandi), acceptEdits (le modifiche vengono eseguite, i comandi chiedono) e bypassPermissions (non chiede nulla). Queste modalità descrivono quanto l'agente chiede a te. Le quattro azioni descrivono cosa deve chiedere al proprietario quando è qualcun altro a fare la richiesta. Si sovrappongono.
L'ultima colonna è l'aggiunta della stanza ed è identica in ogni riga. Consulta le modalità di autorizzazione spiegate.
A chi va chiesto
Questa è la parte che la maggior parte delle architetture tralascia. Quando un agente condiviso ha bisogno di un umano, quale umano?
- Le credenziali vanno al proprietario. Login, codici a due fattori e accesso alle chiavi riguardano l'identità del proprietario. Vengono instradati al proprietario a prescindere da chi ha avviato l'attività. Chi ha fatto la richiesta vede che c'è stato un passaggio di controllo, non il segreto.
- Le domande sulle intenzioni vanno a chi ha fatto la richiesta. "Intendevi il database di staging?" riguarda ciò che la persona voleva fare. Viene instradata alla persona che ha fatto la richiesta.
- Entrambi vedono la stessa timeline. Nessuno dei due deve trasferire il contesto all'altro; la domanda e la sua risposta si trovano nello stesso thread del lavoro.
I prompt per credenziali e azioni pericolose vengono instradati al proprietario; le domande sulle intenzioni vanno a chi ha fatto la richiesta; entrambi vedono lo scambio.
Anatomia di una buona scheda di approvazione
Un'approvazione che le persone possono decidere in cinque secondi ha cinque elementi.
Fornisci tre pulsanti: approva, rifiuta e continua in sola lettura. Il terzo è sottovalutato. Permette al lavoro di procedere mentre il passaggio rischioso resta in attesa.
Consenti di rispondere alle approvazioni ovunque si trovi già il proprietario: la console, un telefono o una scheda di una piattaforma di chat. Decidere in un posto dovrebbe applicarsi ovunque. Imposta una scadenza in modo che una scheda dimenticata non venga eseguita una settimana dopo.
L'affaticamento da approvazione è il vero nemico
Ogni prompt addestra la persona che lo vede. Se sono troppi, troverà l'impostazione per disattivarli. Tre accorgimenti mantengono basso il tasso senza allentare le quattro regole.
- Delimita l'ambito dell'agente. Una directory di lavoro per agente significa meno file che potrebbe toccare, e meno prompt per toccarli.
- Usa le modalità ordinarie per le chiamate ordinarie. Sola lettura per esplorare, modifica senza push per la maggior parte del lavoro. Riserva la "fiducia totale" alle persone che altrimenti digiterebbero direttamente sulla tua tastiera.
- Rendi onesti i template predefiniti. Fornisci sola lettura, modifica-senza-push e piena fiducia come predefiniti con un nome chiaro, in modo che nessuno debba costruire una policy da zero e commettere errori.
La riga di audit
Ogni richiesta e ogni approvazione dovrebbero produrre una riga che il proprietario può esportare: chi ha chiesto, chi ha deciso, quando, quale regola, cosa è successo, cosa ha utilizzato. Non perché qualcuno la legga ogni giorno, ma perché il giorno in cui qualcosa va storto non è il giorno giusto per iniziare a registrare i log.
Domande frequenti
Chiedere ogni volta non rallenta l'agente? Solo per queste quattro categorie, che sono rare in una sessione normale. Il costo della pausa è di pochi secondi; il costo dell'errore si misura in ore o in denaro.
E se il proprietario usa il proprio agente? Il proprietario non è soggetto a modalità di autorizzazione sul proprio agente, ma le quattro azioni vengono comunque registrate nella timeline affinché la cronologia sia completa.
Chi fa la richiesta può approvare per se stesso? No. L'approvazione spetta al proprietario della macchina. Chi ha fatto la richiesta può annullare, riprovare o aggiungere contesto.
Le stanze in muti vengono fornite con queste regole attive e nessun modo per disattivarle. Se ti sembra l'impostazione predefinita corretta, crea una stanza per il tuo agente.
Pubblicato il · Aggiornato il