Passa al contenuto principale

Rendere sicure le esecuzioni autonome

Avanzato
What you'll learn
  • I tre rischi specifici di un'esecuzione senza nessuno che guardi
  • Una checklist di rafforzamento in otto punti, nell'ordine in cui applicarla
  • Quale primitiva di permesso toglie davvero capacità — e quale si limita a pre-approvarla
  • Perché un token a privilegio minimo conta più di un prompt accurato
  • Come limitare un ciclo fuori controllo con un budget imposto dalla piattaforma invece di un'istruzione fiduciosa
  • Perché i file di istruzioni persistenti vanno confrontati (diff) in un luogo in cui l'agente non può scrivere

Eseguire Claude in modalità headless o programmata — in CI, in un cron job, in un hook di pre-commit — elimina la persona che normalmente intercetterebbe un'azione sbagliata. Questa comodità è esattamente il motivo per cui queste esecuzioni richiedono le protezioni più strette.

I rischi specifici delle esecuzioni non presidiate​

  • Nessuno che dica "no" a una chiamata rischiosa a uno strumento sul momento.
  • Credenziali ambientali. La CI ha spesso token potenti (deploy, registry dei pacchetti, cloud). Un agente lì dentro li eredita.
  • Input non fidati. Un'esecuzione innescata da una PR o da una issue può elaborare contenuti scritti da un attaccante (injection).
Watch out

Il modo di fallire contro cui progettare non è un modello malevolo. È un modello ordinario, che possiede un token che non avrebbe mai dovuto avere, e agisce su un testo scritto da un attaccante. Ogni punto qui sotto rimuove uno di questi tre ingredienti.

Una checklist di rafforzamento​

Guided walkthrough1 of 8
  1. Blocca la lettura di .env, file di chiavi e percorsi di credenziali tramite le regole deny dei permessi. Non affidarti al modello per evitarli. Le regole deny sono l'unica primitiva che toglie capacità — vedi l'ordine di valutazione in sei passi per capire perché una allow list non può fare questo lavoro.

Deny toglie, allow pre-approva soltanto​

L'errore più comune in un'esecuzione rafforzata è scegliere la leva sbagliata. Una allow list sembra un lucchetto e non lo è: tutto ciò che lasci fuori è ancora disponibile all'agente e ricade semplicemente nella modalità di permesso della sessione.

Toglie la capacità — lo strumento sparisce dalla richiesta

claude -p "run the test suite" \
--disallowedTools "Bash(curl *)" "Read(//.ssh/**)" "Edit(//etc/**)"

Rende esatta una lista di pre-approvazione — tutto il resto è negato, non richiesto

claude -p "run the test suite" \
--permission-mode dontAsk \
--allowedTools "Bash(npm test)" "Read"

La seconda forma è quella che vuoi per la CI: dontAsk trasforma ogni richiesta in un rifiuto, così un'esecuzione che incontra qualcosa di imprevisto fallisce in modo evidente invece di bloccarsi o di ripiegare silenziosamente su un'impostazione permissiva.

Un controllo che gira a ogni chiamata​

Le regole allow e deny confrontano dei pattern. Quando serve un controllo che ispezioni il contenuto di una chiamata — una stringa dalla forma di un segreto in un argomento, un hostname inatteso — mettilo in un hook PreToolUse. Gli hook girano prima di ogni altro passo di permesso, e il rifiuto di un hook tiene anche in modalità bypass.

Rifiuta qualsiasi chiamata a uno strumento che contenga materiale segreto

# .claude/settings.json -> hooks.PreToolUse
# Exit code 2 blocks the call and tells Claude why.
jq -e '.tool_input | tostring | test("AKIA|BEGIN PRIVATE KEY|ghp_")' >/dev/null \
&& { echo "secret material in tool input" >&2; exit 2; } || exit 0

Esempio: un revisore CI sicuro​

Un bot di revisione delle PR dovrebbe: fare il checkout del codice in sola lettura, non avere accesso a deploy o segreti, girare in un container e commentare i suoi risultati — senza mai modificare i branch protetti. Vedi la guida passo passo alla revisione delle PR.

Check yourself

0/3
  1. La tua esecuzione CI usa bypassPermissions dentro un container. Quale di questi blocca ancora una chiamata a uno strumento?
  2. Quale singola misura limita di più il danno di una prompt injection riuscita in un'esecuzione CI?
  3. Perché CLAUDE.md e i file di skill vanno confrontati (diff) in una posizione in cui l'agente non può scrivere?
Key takeaways
  • Le esecuzioni non presidiate perdono il veto umano, ereditano credenziali ambientali e spesso leggono testo scritto da un attaccante — rimuovi un ingrediente alla volta.
  • Le regole deny e gli hook tolgono capacità; le allow list si limitano a pre-approvare. Abbina allowedTools a dontAsk per renderla esatta.
  • Limita l'ambito del token prima di rifinire il prompt. È la difesa che un'injection non può aggirare con le parole.
  • Limita costo e iterazioni con un budget imposto dalla piattaforma, non con un'istruzione.
  • Consegna gli output come una PR o un commento, così il merge umano resta nel ciclo.
  • Confronta (diff) i file di istruzioni iniettati automaticamente in uno spazio di archiviazione in cui l'agente non può scrivere.

Prossimi passi​