Configura i guardrail

Questa guida mostra come configurare i guardrail: le regole che stabiliscono se l’azione di un agente viene eseguita, richiede prima un’approvazione o viene rifiutata.

I guardrail coprono le tredici classi di effetto che ogni strumento che modifica lo stato dichiara. Vengono applicati lato server nel punto in cui lo strumento viene chiamato, mai tramite un’istruzione in un prompt.

Imposta una decisione per una classe di azione

1. Vai su Impostazioni → Spazio di lavoro → Autorizzazioni degli agenti
2. Scegli un ambito con il controllo segmentato: Spazio di lavoro, Agente (poi scegli l’agente) o Spazio (poi scegli lo spazio)
3. Sulla riga della classe di azione, scegli Consenti, Chiedi prima o Nega
4. Per eliminare una regola che hai impostato, premi il pulsante di ripristino che compare alla fine di quella riga (Ripristina al valore ereditato) — la decisione torna all’ambito più ampio

Ogni riga mostra la decisione effettiva come tag di stato e un badge per la sua provenienza: Questo ambito, Ereditato o Predefinito. La matrice si risolve nella modalità Agente (chat), quindi Preimpostazione della modalità non compare mai qui — usa la sonda «E se?» con una modalità di sola lettura selezionata per vedere quel livello.

Scrivere una regola richiede il ruolo admin. Leggere la matrice no.

Verifica: imposta Eseguire il push a un remoto su Nega nell’ambito dello spazio di lavoro, poi esegui la sonda «E se?» qui sotto su git push origin main. Il risultato è deny con origine workspace.

Capire come si risolve una decisione

La risoluzione segue l’ordine prima la specificità, poi la restrittività:

1. Le regole di Spazio, poi quelle di Agente, poi quelle di Spazio di lavoro. Il primo ambito con una regola corrispondente decide e la risoluzione si ferma
2. Se nessuna regola corrisponde, si applica la preimpostazione della modalità — una modalità di sola lettura (plan, review, orchestrate) rifiuta undici delle tredici classi
3. Se la modalità non ha nulla da dire, si applica il predefinito integrato

Dentro un unico ambito, una regola sui comandi si risolve con il prefisso corrispondente più lungo e un conflitto ugualmente specifico si risolve nella forma più restrittiva — nega batte chiedi prima, che batte consenti. Un’azione che dichiara più classi le risolve ciascuna in modo indipendente e poi le combina nella forma più restrittiva.

Consenti non batte Nega

Una regola più ristretta vince per specificità e un pareggio si scioglie per restrittività — quindi un Consenti nell’ambito dello spazio di lavoro non sovrascrive un Nega da nessuna parte.

Una decisione Chiedi prima fa comparire un’unica richiesta di approvazione che copre tutte le classi risolte in prompt. Senza alcun approvatore collegato viene negata, sia per i comandi della shell sia per le chiamate agli strumenti dell’harness. È una scelta deliberata: un’esecuzione senza controllo è peggio di una rifiutata.

Classi di azione e predefiniti integrati

Classe di azione	Predefinito integrato
Eliminare un file	Chiedi prima
Scrivere fuori dal worktree	Consenti
Creare un commit	Consenti
Eseguire il push a un remoto	Chiedi prima
Aprire una pull request	Chiedi prima
Pubblicare una revisione o unire	Chiedi prima
Scrivere su un tracker esterno	Chiedi prima
Accedere alla rete	Consenti
Leggere un segreto	Consenti
Installare un pacchetto	Consenti
Eseguire un processo	Consenti
Modificare la struttura dello spazio di lavoro	Consenti
Pilotare un recinto (rig)	Consenti

La tassonomia è chiusa. Un nuovo strumento distribuito senza dichiarare le proprie classi non supera un test a cricchetto in CI, quindi nulla arriva con un insieme di effetti silenziosamente vuoto.

Prova una regola con la sonda «E se?»

Prima di modificare una regola, controlla come la policy attuale la risolve già.

1. Sulla stessa pagina, scorri fino a E se?
2. Scegli un’Azione (una delle tredici classi)
3. Se vuoi, compila Comando (ad esempio git push origin main), Agente, Spazio e Modalità
4. Leggi il risultato: la decisione, il motivo e Origine:

La sonda esegue lo stesso motore di risoluzione usato dal percorso di applicazione, sulle tue regole attive, quindi la risposta è esatta. Se ti sorprende, modifica una regola nella matrice qui sopra ed esegui di nuovo la sonda.

Imposta il selettore dell’autonomia di uno spazio

Il selettore è per agente e per spazio e si compone con le regole invece di sostituirle.

1. Apri lo spazio
2. Apri Gestisci partecipanti dall’intestazione dello spazio
3. Sotto Autonomia, sulla riga dell’agente, scegli un livello:

Livello	Effetto
Predefinito	Nessuna impostazione per lo spazio — si comporta come Agisci con approvazione
Solo proposta	Ogni strumento soggetto a controllo viene negato senz’altro, con un messaggio che invita l’agente a proporre l’azione
Agisci con approvazione	Le azioni rischiose incontrano il cancello di approvazione a chiusura predefinita
Agisci liberamente	Pre-approva tutto ciò che non si è risolto in un rifiuto netto

Agisci liberamente ingoia ogni richiesta

Con Agisci liberamente una decisione Chiedi prima viene concessa senza chiedere nulla a te. Solo un deny — da una regola, dalla preimpostazione della modalità o da un predefinito integrato — blocca ancora. Ricorri a questa opzione quando stai sorvegliando lo spazio, non come impostazione predefinita.

Il selettore raggiunge solo l’harness integrato. L’adattatore Claude Code esegue i propri strumenti fuori da questo cancello.

Sapere dove i guardrail non arrivano

La tabella Dove vengono applicate le regole in fondo alla stessa pagina è la versione in-app di questo concetto: per ogni classe di effetto indica se ciascun esecutore la intercetta al cancello della policy, la lascia alla sandbox o non riesce a intercettarla affatto.

• L’adattatore Claude Code è controllato solo in parte per le proprie chiamate agli strumenti. Claude Code viene avviato con --dangerously-skip-permissions, quindi le sue chiamate di lettura, scrittura e modifica non passano mai dal controllo. I suoi comandi bash lo raggiungono tramite un hook che classifica la riga di comando, e i suoi push passano dal gateway dei push come quelli di qualsiasi agente. Sono controllati anche la superficie degli strumenti MCP su cui richiama e il comando della shell che Control Center genera per avviarlo.
• Il verbo di output di una modalità (submit_plan, propose_orchestration) è fissato e non può mai essere negato — altrimenti una modalità sarebbe strutturalmente incapace di produrre il suo unico risultato.
• Se la sandbox faccia da rete di sicurezza per queste regole dipende dall’host. Dove cc_server trova un backend avvolge la CLI di Claude Code e lo strumento bash dell’harness, così anche una regola che non hai scritto poggia su una base del sistema operativo. Su Windows non ne esiste alcuna e su Linux o WSL2 senza bwrap e socat non ne esiste alcuna neanche lì — lì i guardrail e la superficie degli strumenti della modalità costituiscono l’intera applicazione, non una sua seconda linea. Controlla in quale caso ti trovi con Configura le policy del sandbox.

Guide correlate

• Configura le policy del sandbox
• Crea e configura un agente
• Gestisci adapter e modelli

Concetti correlati

• Guardrail — una sola policy per ogni azione che modifica lo stato
• Modalità
• Sandbox e sicurezza