Le migliori pratiche di sicurezza Claude Code per team nel 2026

Ultimo aggiornamento: June 28, 2026

Un agente di codifica AI che può leggere il tuo repo, eseguire comandi shell e chiamare servizi esterni è utile proprio perché ha portata. Quella stessa portata è il rischio. Un prompt letto male, un allowlist disordinato o un singolo server MCP non affidabile possono far trapelare un token o cancellare un branch. Questa guida è per lo sviluppatore o il responsabile della piattaforma che vuole Claude Code nel lavoro quotidiano e in CI senza dargli le chiavi di produzione.

Risposta rapida: come i team mantengono sicuro Claude Code?

Eseguire l'agente con il minimo privilegio e rivedere ciò che fa. Praticamente, questo significa cinque cose:

• Avviare in una modalità permessi restrittiva e concedere strumenti tramite un'allowlist ristretta, non un generico "sempre consentito".
• Mantenere i segreti fuori dal contesto del modello: nessuna chiave incollata e una regola deny su .env e percorsi di segreto.
• Verificare ogni server MCP prima di collegarlo, poiché un server non affidabile può leggere dati e agire per tuo conto.
• Trattare i contenuti web recuperati come input non attendibile che potrebbe contenere istruzioni di prompt-injection.
• In CI, fornire all'agente un token a breve termine e limitato alla lettura e non esporre mai le credenziali di produzione.

Il resto di questo articolo trasforma ciascuno di questi in impostazioni concrete, con una tabella dei rischi, un riferimento ai permessi e uno scenario CI che puoi copiare.

Come funzionano in realtà i modalità di permessi e le liste consentite (allowlist)?

Claude Code chiede prima di eseguire uno strumento per la prima volta. Tu decidi se questa decisione deve essere ricordata, limitata (scoped) o saltata. La modalità di permessi stabilisce il livello base:

• default richiede un prompt al primo utilizzo di ogni strumento o comando.
• plan è in sola lettura: l'agente può leggere i file e proporre un piano, ma non può modificare o eseguire comandi. Usalo per la revisione.
• acceptEdits accetta automaticamente le modifiche ai file ma richiede comunque prompt per i comandi shell.
• bypassPermissions salta ogni prompt. Trattalo come solo sandbox.

I controlli persistenti risiedono in .claude/settings.json sotto permissions, con regole allow, ask e deny. Le regole sono limitate (scoped) per strumento e pattern, quindi concedi esattamente ciò di cui un compito ha bisogno:

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)", "WebFetch"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl:*)", "Bash(rm -rf:*)"]
  }
}

Una regola deny vince sempre su allow, motivo per cui i percorsi segreti sopra rimangono illeggibili anche se esiste una regola Read ampia. Anthropic documenta la sintassi completa delle regole e la precedenza nei documenti di identity and access management di Claude Code.

Evita --dangerously-skip-permissions al di fuori di un container usa e getta. Rimuove il singolo controllo umano che intercetta un cattivo rm o una chiamata di rete inaspettata. Se desideri velocità senza quel rischio, preferisci una lista consentite (allowlist) stretta in modo che i comandi di routine vengano eseguiti automaticamente mentre qualsiasi cosa nuova faccia ancora una pausa per te.

Riferimento sui rischi e sulla mitigazione

La maggior parte degli incidenti risale a un piccolo insieme di pattern. Mappa ciascuno a un controllo prima di scalare l'agent in tutto il team.

La cornice qui segue OWASP Top 10 for LLM Applications, che segnala prompt injection, gestione non sicura dell'output e agenzia eccessiva come i principali rischi per gli agent.

Riferimento permessi e ambito

Questa tabella è la guida rapida che do ai nuovi membri del team. Copre le impostazioni che cambiano il raggio d'azione di un singolo ciclo.

Verificare i server MCP prima di connetterli

I server MCP estendono l'agente con nuovi strumenti: un client database, un'integrazione ticketing e un browser. Ogni componente che aggiungete è codice in grado di leggere il contesto ed eseguire azioni. Un server non affidabile è il modo più rapido per trasformare un agente utile in un percorso di esfiltrazione dati, quindi la soglia per connetterne uno dovrebbe essere la stessa che applichereste a qualsiasi dipendenza con accesso di rete.

Prima di aggiungere un server, rispondete a cinque domande:

1. Chi lo pubblica e la fonte è pubblica e mantenuta?
2. Quali scope richiede: solo lettura, o scrittura e rete?
3. Quali dati può vedere una volta connesso: solo questo repository, o l'intero vostro sistema?
4. Le credenziali sono limitate nello scope e a breve termine, o si tratta di un token amministratore a lungo termine?
5. Potete fissare una versione in modo che un aggiornamento automatico non possa allargare silenziosamente il suo accesso?

Connettete i server con lo scope minimo necessario per eseguire il lavoro, e tenete i server con capacità di scrittura o orientati alla produzione fuori dai file di configurazione condivisi o CI. Per la meccanica di setup e una guida più approfondita, consultate la nostra guida all'integrazione Claude Code MCP. Il post consigli di produttività per Claude Code spiega come mantenere questa impronta ridotta senza rallentarvi.

Mantenere i segreti fuori dalla portata del modello

Il segreto più pulito è quello che il modello non vede mai. Non incollare chiavi API nel prompt e non chiedere all'agente di "leggere la chiave dalla configurazione e usarla". Lasciare le credenziali nell'ambiente e fare riferimento ad esse per nome, così il valore rimane fuori dalla trascrizione.

Tre abitudini coprono la maggior parte del rischio:

• Aggiungere una regola di deny per .env, *.pem e qualsiasi directory secrets/ in modo che l'agente non possa leggerle nemmeno per caso.
• Utilizzare uno scanner di segreti pre-commit (come gitleaks o git secrets) in modo che una chiave esfiltrata fallisca il commit, non l'audit.
• Ruotare immediatamente qualsiasi cosa venga esposta, quindi controllare i log e la cronologia. La rotazione è l'unica correzione che chiude davvero il buco.

Se una chiave è già arrivata in una trascrizione o in un commit, assumere che sia compromessa e ruotarla. Cercare la cronologia git con git log -S aiuta a trovare dove è atterrata.

Scenario: abilitare Claude Code in CI senza credenziali di produzione

Un team vuole che Claude Code esamini le pull request in GitHub Actions. L'obiettivo è fornire commenti di revisione automatizzati, senza alcuna capacità di deployment, scrittura su main o accesso al database di produzione.

Ecco la configurazione che mantiene il lavoro utile ma circoscritto:

• Eseguire in modalità headless con claude -p in modalità plan in modo che l'agente legga il diff e scriva un commento, ma non modifichi mai i file o esegua comandi di build.
• Concedere al workflow solo contents: read e pull-requests: write. Nessun lavoro di deployment, nessun ambito infrastrutturale.
• Utilizzare il GITHUB_TOKEN a breve termine del lavoro, non un token personale, e non inserire mai chiavi di produzione di database o cloud nell'ambiente di quel lavoro.
• Aggiungere una lista deny per i percorsi segreti e per gli curl in uscita, in modo che un tentativo di prompt-injection all'interno del diff della PR non possa esfiltrare nulla.
• Fissare la versione dell'azione e di Claude Code, e bloccare qualsiasi passaggio di deployment dietro un ambiente separato e approvato da un umano.

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Il lavoro di revisione vede il codice e pubblica un feedback. Non può raggiungere la produzione perché le credenziali di produzione non sono mai nell'ambito (in scope). La panoramica sulla sicurezza di Claude Code di Anthropic descrive questa postura a minimo privilegio per esecuzioni automatizzate e headless.

Cosa non dovresti mai incollare in un agente di codifica AI?

Alcuni input non dovrebbero assolutamente trovarsi in una trascrizione, perché qualsiasi cosa nella finestra di contesto può essere riecheggiata, registrata o su cui agire:

• Chiavi API attive, URL di database con password o credenziali root del cloud.
• PII del cliente o dati regolamentati che non metteresti in un ticket di supporto.
• Chiavi di firma private, certificati o file .pem.
• Stringhe di connessione complete di produzione quando sarebbe sufficiente una replica di sola lettura o un fixture locale.

Quando l'agente ha bisogno di accesso, forniscigli un percorso per una credenziale limitata tramite l'ambiente piuttosto che il segreto stesso. Stesso risultato, raggio d'azione molto più piccolo.

Audit, hooks e revisione continua

Il principio del privilegio minimo stabilisce il pavimento; la revisione ti mantiene lì. Leggi il piano dell'agente prima di approvare un passaggio rischioso e leggi il diff prima di committare. Per modifiche più grandi, la stessa disciplina che rende sicuro AI-assisted refactoring si applica qui: piccoli passaggi revisionabili superano un unico gigantesco run non supervisionato.

Aggiungi guardrail deterministici con gli hooks. Un hook PreToolUse può ispezionare un comando e bloccarlo prima che venga eseguito, ed è così che si applicano regole che il modello non dovrebbe mai sovrascrivere, come rifiutare qualsiasi scrittura su un percorso protetto. Abbinalo a una traccia di audit in modo da poter rispondere cosa ha fatto l'agente, quando e per chi.

Una rapida lista di controllo ricorrente per il team:

• Rivedere le liste di permesso e divieto in .claude/settings.json su base periodica, non solo durante la configurazione iniziale.
• Rivalutare i server MCP dopo importanti aggiornamenti di versione.
• Confermare che i job CI vengano ancora eseguiti in modalità plan e non contengano segreti di produzione.
• Ruotare i token con cadenza e dopo qualsiasi sospetta esposizione.
• Mantenere un CLAUDE.md che dichiari i non negoziabili: nessun force-push su main, nessun accesso diretto al DB di produzione, nessun segreto nei prompt.

Per il flusso di lavoro più ampio che riguarda tutto questo, la Claude Code ultimate guide guida attraverso la configurazione dall'inizio alla fine.

Punto chiave

La sicurezza per gli agenti di codifica AI è lo stesso pensiero del minimo privilegio che si applica già agli account di servizio, scritto come regole di permessi. Iniziare in modo restrittivo, allargare con un'allowlist ristretta, negare percorsi segreti, verificare i server MCP come dipendenze, trattare i contenuti recuperati come non affidabili e tenere le credenziali di produzione fuori da qualsiasi lavoro che l'agente possa raggiungere. Facendo questo, Claude Code rimane un paio di mani veloci, non una porta aperta.