Come configurare i permessi di Claude Code senza approvare tutto

Se approvi lo stesso comando di test venti volte, il controllo non sta più aiutando: interrompe soltanto il lavoro. Se invece autorizzi qualsiasi comando per non essere interrotto, perdi il punto in cui una conseguenza importante dovrebbe tornare visibile.

Configurare i permessi di Claude Code significa mettere ogni azione nella fascia giusta. Le operazioni note, locali e reversibili possono essere consentite. Quelle che richiedono una decisione restano in richiesta. Le azioni incompatibili con il progetto vengono negate.

Il risultato non è una sessione senza domande. È una sessione che fa le domande nel punto in cui la risposta cambia davvero il rischio.

Prima osserva le approvazioni ripetute

Non iniziare copiando una configurazione trovata online. Lavora per alcuni incarichi con un perimetro prudente e registra le richieste che ricorrono. Per ognuna annota quattro elementi:

• quale strumento o comando viene richiesto;

• su quali file, directory o servizi agisce;

• quale conseguenza produce;

• come puoi verificare o annullare il risultato.

«Eseguire test» è troppo generico. npm run test:unit in una cartella locale ha un profilo diverso da uno script che crea record in un ambiente condiviso. Anche due comandi con lo stesso nome possono avere conseguenze diverse in repository differenti.

La configurazione deve nascere dal lavoro osservato, non da una lista astratta di ciò che uno strumento potrebbe fare.

Modalità e regole non sono la stessa cosa

Le modalità definiscono l'atteggiamento generale della sessione. La modalità piano, per esempio, orienta Claude verso esplorazione e progettazione senza modificare i file sorgente. Altre modalità cambiano il modo in cui vengono gestite le richieste di permesso. La documentazione sui permission mode descrive questi assetti e i loro casi d'uso.

Le regole, invece, classificano operazioni specifiche. La documentazione sui permessi distingue tre esiti:

• allow: l'azione corrispondente può procedere senza una nuova richiesta;

• ask: l'azione richiede una decisione;

• deny: l'azione viene bloccata.

Una modalità non evita la necessità di regole puntuali, e una raccolta di regole non spiega da sola lo scopo della sessione. Usa la modalità per il flusso generale e le regole per il perimetro tecnico.

Parti dalle conseguenze, non dai nomi

Un inventario utile raggruppa le azioni per ciò che possono cambiare:

Questa tabella non è una configurazione pronta. Serve a non confondere la familiarità con la sicurezza. Un comando ripetuto può restare rischioso; un'azione rara può essere del tutto locale e reversibile.

I tre anelli del perimetro

Puoi progettare una prima policy con tre anelli.

Il primo comprende letture e controlli locali necessari per capire il progetto: ricerca, apertura dei file, stato del repository. Il secondo comprende modifiche locali e comandi reversibili con una prova chiara: test mirati, lint, formatter concordato. Il terzo comprende azioni che cambiano repository condivisi, dati, account o servizi esterni.

Per ogni anello chiedi:

1. qual è l'azione più precisa che posso descrivere;

2. quale conseguenza massima può produrre;

3. quale regola deve applicarsi;

4. quale evidenza voglio dopo l'esecuzione.

La precisione conta. Consentire un comando esatto è diverso dal consentire una shell generica. Autorizzare la lettura del progetto è diverso dal rendere leggibile ogni percorso raggiungibile dalla macchina.

Scrivi una configurazione minima

Una configurazione illustrativa può partire così:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:unit)"
    ],
    "ask": [
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

Il senso dell'esempio è più importante delle stringhe: un test locale noto può passare senza interruzione, il commit resta una decisione e il push o la lettura di un file sensibile vengono bloccati. Prima di usare questi pattern, confrontali con la sintassi documentata per la tua versione e con i comandi reali del repository.

Non aggiungere cinquanta eccezioni il primo giorno. Parti da pochi casi osservati e cambia una regola per volta.

Capisci l'ordine deny, ask, allow

Una stessa azione può corrispondere a più pattern. Secondo la documentazione Anthropic, Claude Code valuta prima deny, poi ask, infine allow. Una negazione specifica può quindi prevalere su un'autorizzazione più ampia.

Questo ordine aiuta a costruire un perimetro leggibile: puoi consentire una famiglia di azioni e negare un sottoinsieme sensibile. Ma i pattern troppo ampi rendono difficile prevedere le intersezioni. Dopo ogni modifica, prova almeno:

• un caso che deve passare;

• un caso che deve chiedere;

• un caso che deve essere negato;

• un caso vicino al confine, ma non identico.

Se non sai spiegare quale regola ha prodotto l'esito, la configurazione è già troppo opaca.

Tieni in ask le decisioni vere

La fascia ask non è un parcheggio per tutto ciò che non hai ancora classificato. Dovrebbe contenere le azioni in cui il contesto dell'incarico cambia la risposta.

Un commit può essere appropriato solo dopo aver controllato il diff. L'installazione di una dipendenza può essere corretta quando il progetto la richiede, ma non come scorciatoia automatica. Un comando che scrive su un database di prova può essere ammesso in un ambiente isolato e vietato in produzione.

Formula la domanda insieme all'evidenza necessaria: cosa verrà eseguito, dove, con quale effetto e come verrà controllato. Approvare una stringa senza conseguenza leggibile riduce la decisione a un riflesso.

Usa deny per confini stabili

La fascia deny è adatta a ciò che non deve accadere in quel progetto: leggere file con segreti, modificare directory generate, eseguire push o usare comandi distruttivi non previsti.

Un divieto utile è specifico e accompagnato da un percorso alternativo nelle istruzioni del progetto. Se neghi la modifica dei file generati, indica dove si trovano le sorgenti e quale comando li rigenera. Il permesso applica il confine; l'istruzione aiuta Claude a continuare senza tentare scorciatoie.

Controlla anche che il divieto copra le forme equivalenti dell'azione. Bloccare una singola stringa non serve se lo stesso risultato è raggiungibile con un altro strumento già consentito.

Aggiungi il confine della directory e la sandbox

Le regole non lavorano da sole. La directory da cui parte Claude Code definisce il contesto iniziale e quali percorsi sono naturalmente nel progetto. Le autorizzazioni aggiuntive possono estendere quel confine. La sandbox limita invece ciò che i processi possono raggiungere a livello di filesystem o rete, secondo la configurazione disponibile.

La guida alla sicurezza di Claude Code tratta questi livelli come controlli complementari. Puoi leggerli così:

• le regole decidono quali azioni Claude può richiedere o avviare;

• il confine della directory delimita il lavoro atteso;

• la sandbox riduce ciò che un processo può raggiungere anche se tenta di uscire dal percorso previsto.

Non affidare a una riga di testo un limite che deve essere applicato tecnicamente. E non scambiare una sandbox per la policy organizzativa che stabilisce chi può agire su un account.

Separa permesso tecnico e autorizzazione

Claude può essere tecnicamente in grado di eseguire un comando e non essere autorizzato dalla tua organizzazione a farlo. Un token disponibile non equivale al consenso a pubblicare. Un connettore configurato non autorizza a inviare dati di un cliente.

Definisci quindi due domande distinte:

1. il sistema consente questa azione nel perimetro tecnico?

2. una persona o una policy ha autorizzato questa conseguenza in questo caso?

La guida agli accessi nei workflow AI aiuta a distribuire ruoli, credenziali e responsabilità senza trasformare la disponibilità tecnica in un'autorizzazione implicita.

Prova la policy con casi avversi

Non limitarti a ripetere i comandi che vuoi consentire. Prova intenzionalmente i bordi: un percorso vicino ma escluso, un comando con argomenti diversi, una lettura del file sensibile, una scrittura fuori dalla directory.

Registra per ogni caso l'esito atteso e quello osservato. Se una regola consente troppo, restringila. Se interrompe continuamente un'azione locale nota, valuta un'autorizzazione più precisa. Dopo il cambiamento ripeti tutti i casi, perché una nuova regola può sovrapporsi alle precedenti.

Conserva anche una checklist di verifica degli output AI per l'esecuzione: il permesso stabilisce se un'azione può partire, non se il suo risultato è corretto.

Rivedi le regole quando cambia il lavoro

Una policy accumula eccezioni se viene aggiornata soltanto quando compare un blocco. Fissa una revisione periodica e chiedi quali autorizzazioni non vengono più usate, quali richieste si ripetono e quali azioni hanno acquisito conseguenze nuove.

Rimuovi i permessi che non sai più motivare. Restringi i pattern nati durante un'emergenza. Aggiorna i test del perimetro. Una configurazione breve con motivi chiari è più facile da controllare di una lunga cronologia di concessioni.

Costruisci il tuo primo perimetro

Prendi le ultime dieci richieste di approvazione. Classificale per conseguenza, assegna ciascuna a allow, ask o deny e scrivi soltanto le tre regole più ricorrenti. Poi prova un caso valido e un caso avverso per ogni regola.

Nel programma su Claude Cowork e Code di MAIKER HUB puoi costruire questo perimetro sui tuoi repository e sulle tue procedure. L'obiettivo non è eliminare le domande. È conservare quelle che proteggono una decisione e togliere quelle che non aggiungono più controllo.