Perché il tuo AI per il coding è una falla di sicurezza (e come chiuderla)

Qualche giorno fa ho capito che per mesi avevo dato a un assistente AI i permessi per eseguire comandi a piacimento sul mio PC. Poteva toccare credenziali AWS, chiavi SSH, repo GitHub private e tutto ciò che stava nella mia home. Il peggio? Non ci avevo mai pensato. Era comodo, e non era successo nulla di male.

Proprio quel "finora tutto ok" è il modo più veloce per perdere un database in produzione.

La comodità nasconde i rischi

La verità nuda e cruda: gli AI per il coding hanno oggi gli stessi accessi che daresti a un ingegnere senior al primo giorno. Non lasceresti mai a un freelance le chiavi SSH di tutti i server. Eppure con un LLM lo fai senza battere ciglio.

Non è cattiveria. È distrazione. Sono così utili che dimentichi i pericoli. Un prompt malevolo da un repo clonato, un obiettivo sbagliato o un comando innocuo potrebbero spedire le tue credenziali a un server nemico. E tu non te ne accorgi.

Per fortuna, tool come Claude Code hanno controlli di sicurezza solidi. Basta attivarli.

I pericoli del setup di default

Per impostazione predefinita, molti AI coding agent girano in modalità "auto". Eseguono comandi senza chiederti nulla, a meno di blocchi espliciti. Sembra pratico? Ecco cosa significa in concreto:

Con una deny list vuota e modalità auto, il tuo AI può:

• Lanciare curl verso qualsiasi server
• Scaricare file con wget
• Connettersi via ssh a macchine remote
• Aprire porte con nc
• Leggere ogni .env nel progetto
• Toccare ~/.aws/credentials, ~/.ssh, ~/.gnupg
• Pushare codice sui tuoi repo

Tutto in silenzio. Nessun avviso. Fine.

Un modello di sicurezza a tre livelli

Serve controllo preciso. Non tutto va approvato, ma alcune azioni sì. Ecco come strutturarlo:

Livello 1: Blocco totale

Inizia con una deny list per credenziali e pericoli alti:

{
  "deny": [
    "Read(~/.ssh/**)",
    "Read(~/.aws/**)",
    "Read(~/.gnupg/**)",
    "Read(~/.azure/**)",
    "Read(~/.kube/**)",
    "Read(~/.npmrc)",
    "Read(~/.git-credentials)",
    "Read(*.env)",
    "Read(.env.*)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(nc *)",
    "Bash(ssh *)"
  ]
}

È il tuo firewall. Niente passa, punto.

Livello 2: Punto di revisione

Usa una "ask" list per operazioni rischiose ma reversibili:

{
  "ask": [
    "Bash(git push *)",
    "Bash(git commit *)",
    "Bash(git merge *)",
    "Bash(git reset *)",
    "Bash(npm publish *)",
    "Bash(docker push *)"
  ]
}

L'AI le fa se servono, ma ti chiede prima. Produttività senza passi falsi.

Livello 3: Via libera

Permetti operazioni sicure senza intoppi:

{
  "allow": [
    "Bash(npm run *)",
    "Bash(git status *)",
    "Bash(git diff *)",
    "Bash(git log *)",
    "Bash(ls *)",
    "Read(src/**)",
    "Read(tests/**)"
  ]
}

Queste vanno libere. Non cambiano nulla di critico.

Scegliere la modalità di default

Dopo deny e ask, decidi il default per il resto. Opzioni:

1. auto - Tutto ciò che non è bloccato parte da solo. Veloce, ma fidati della tua lista.

2. acceptEdits - Legge e suggerisce liberamente, ma chiede per comandi bash non permessi. Equilibrato.

3. ask - Chiede per ogni rischio. Lento, ma blindato.

Per la maggior parte, acceptEdits è ideale. Produttività con decisioni consapevoli.

Configurazione pronta all'uso

Ecco un setup solido per produzione:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.git-credentials)",
      "Read(~/.config/gh/**)",
      "Read(*.env)",
      "Read(.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git commit *)",
      "Bash(npm publish *)",
      "Bash(docker push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm install *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

L'AI lavora su test, codice e analisi. Ma non ruba dati né deploya senza ok.

Due approcci per contesti diversi

Io uso due alias shell:

# Default: sicurezza bilanciata
alias cc="claude --permission-mode auto"

# Debug: fidati al 100% (solo se serve)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc per il 95% del lavoro. ccd per emergenze, con rischio calcolato.

Il problema colpisce tutti

Non è solo Claude Code. Ogni AI che esegue comandi shell ha questi rischi: Copilot, Devin, Cursor, ChatGPT con execution. Tutti bilanciano comodità e sicurezza.

Claude Code spicca per i controlli fini. Gli altri ti obbligano a tutto o niente.

Implicazioni per il team

In azienda è vitale. Non puoi contare sui dev single. Serve:

• Deny list obbligatorie nei config condivisi
• Blocco file credenziali a livello filesystem
• Token temporanei, non chiavi eterne
• Controlli rete anti-esfiltrazione
• Formazione su produttività vs rischio

In sintesi

Gli AI coding sono potenti, usali. Ma configura i controlli. Non è gratis.

Dedica 15 minuti: deny per credenziali, ask per deploy, default sensato. Poi lavora sereno.

"Finora ok" non è una strategia di sicurezza.