Permessi dei coding agent AI e YOLO mode: una configurazione più sicura

Le modalità di permesso in tre tool

Ogni coding agent AI bilancia due cose: quanto spesso ti interrompe e quanto può fare senza chiedere. Le impostazioni hanno nomi diversi in ogni tool ma la stessa struttura: una modalità che chiede, una modalità che lascia decidere a un revisore automatico e una modalità che salta tutto, chiamata informalmente YOLO mode.

Cosa saltano davvero le modalità “salta tutto”

Le modalità “salta tutto” eliminano più delle sole richieste di conferma. In Codex, il flag rimuove sia le approvazioni sia la sandbox. Cursor descrive Run Everything come l’esecuzione automatica di ogni chiamata ai tool senza sandbox e senza revisore. La modalità bypass di Claude Code salta anche le conferme per le scritture nella propria directory .claude e in .git.

I vendor sono concordi su dove vadano usate queste modalità: Claude Code dice di usare la modalità bypass solo in ambienti isolati come container o VM, e Codex indica il suo flag come a rischio elevato e sconsigliato. Anche in un container, tutto ciò che vi è montato, come una credenziale cloud o un agent SSH, è alla mercé dell’agent. La guida a ciò a cui possono accedere gli agent elenca cosa comprende di solito.

Cosa può cambiare un repository

La configurazione degli agent vive sempre più spesso nel repository, accanto al codice: impostazioni in .claude/, .codex/config.toml, .cursor/mcp.json, definizioni di hook e file di istruzioni come AGENTS.md e CLAUDE.md. Per i team è comodo, e significa che un git clone può cambiare il comportamento di un agent.

• I controlli di attendibilità aiutano. Codex carica il livello .codex/ di un progetto solo dopo che hai dichiarato attendibile il progetto. Claude Code applica le regole allow di un repository solo dopo che ogni membro del team ha dichiarato attendibile la cartella, e ignora bypassPermissions come modalità predefinita nelle impostazioni di progetto.
• Non tutto è protetto allo stesso modo. Hook, definizioni di server MCP e file di istruzioni arrivano comunque con il repository; i server MCP hanno una propria richiesta di approvazione, e il workspace trust di Cursor è disattivato a meno che tu non lo abiliti.
• Le versioni più vecchie si comportano diversamente. Un’impostazione che le release attuali ignorano potrebbe essere ancora rispettata da un client più vecchio sulla macchina di qualcuno, e la sua presenza ti dice che il progetto si aspetta che gli agent girino senza supervisione.

Impostazioni degli agent da non committare

Questi sono gli schemi da intercettare in review prima che arrivino sul branch principale:

• Approvazioni disattivate: bypassPermissions come modalità predefinita, un subagent con permissionMode: bypassPermissions, oppure uno script del package che avvia un agent con --dangerously-skip-permissions o --dangerously-bypass-approvals-and-sandbox.
• Regole allow che pre-approvano qualsiasi cosa: Bash(*), oppure wildcard su shell, interpreti, package runner e strumenti di rete come Bash(curl:*) o Bash(npx:*).
• Hook che scaricano ed eseguono uno script, per esempio passando l’output di curl in pipe a una shell.
• Server MCP non fissati a una versione, avviati da uno script remoto, raggiunti in HTTP semplice o configurati con una credenziale hard-coded.
• Testo nascosto nei file di istruzioni: commenti HTML o caratteri Unicode invisibili in AGENTS.md o CLAUDE.md che un revisore non vede ma l’agent legge.

{  "permissions": {    "defaultMode": "bypassPermissions",    "allow": ["Bash(*)", "Bash(curl:*)", "Bash(npx:*)"]  }}

Una base più sicura

1. Mantieni la modalità predefinita o auto sui portatili; riserva le modalità “salta tutto” agli ambienti usa e getta.
2. Committa regole allow ristrette per i comandi esatti che il progetto esegue e nega la lettura dei segreti.
3. Fissa le versioni dei server MCP e tieni le loro credenziali in variabili d’ambiente, non nel file.
4. Attiva la sandbox dove è opzionale e limita l’accesso alla rete a una allowlist.
5. In review, tratta le modifiche alla configurazione e ai file di istruzioni degli agent come rilevanti per la sicurezza.

{  "permissions": {    "allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],    "deny": ["Read(./.env)", "Read(./secrets/**)"]  }}

Le regole allow che terminano con una wildcard sono sicure solo quanto il comando che la precede: una regola per npm run test è ristretta, una per node o curl no.

Il ruolo di vetkit

L’audit del repository di vetkit controlla la configurazione degli agent committata come parte della sua suite sui rischi del codice AI: impostazioni e flag che aggirano le approvazioni, regole allow che pre-approvano comandi di shell o di rete arbitrari, hook che eseguono script remoti, server MCP non fissati a una versione o avviati da remoto, server MCP in HTTP semplice o con credenziali hard-coded, e commenti nascosti o caratteri Unicode nei file di istruzioni degli agent. Le stesse regole sono condivise con il server @vetkit/mcp e con Agent Watch, che riporta ciò che gli agent fanno davvero sulle macchine del team; la guida al monitoraggio copre questo aspetto.

Fonti

Abbiamo ricavato le affermazioni su ciascun tool dalla sua documentazione ufficiale il 10 novembre 2026:

• Claude Code: permessi, impostazioni e sicurezza
• OpenAI Codex: approvazioni e sicurezza dell’agent e nozioni di base sulla configurazione
• Cursor: modalità di esecuzione e sicurezza dell’agent

I nomi dei prodotti sono marchi dei rispettivi proprietari. vetkit non è affiliato, approvato né sponsorizzato da loro. Hai notato qualcosa di non aggiornato? Scrivi a contact@vetkit.dev e lo correggeremo.