Guida alla sicurezza di Claude Code: Permessi, MCP, Sandboxing

I chatbot tradizionali sono configurati dietro un'API, quindi nel peggiore dei casi possono allucinare. Ma un agente di coding AI vive dentro il tuo repository, il tuo terminale e (spesso) le tue credenziali cloud, il che lo avvicina molto di più ad ambienti di sviluppo privilegiati rispetto a qualsiasi cosa chiamassimo chatbot.

La domanda è come usare Claude Code in sicurezza senza rallentarti. Permessi, controlli MCP e sandboxing con il giusto grado di messa a punto ti porteranno lì.

In questo articolo ti spiegherò come funziona davvero il modello di sicurezza di Claude Code, dove devi prestare attenzione e le pratiche che lo mantengono utile senza concedergli più accesso di quanto intendevi.

Se sei completamente nuovo a Claude e Claude Code, iscriviti al nostro corso gratuito Claude Code 101 per apprendere le basi in un pomeriggio.

Capire il modello di sicurezza di Claude Code

Prima di regolare anche una sola regola, ti serve un modello mentale di cosa controlla effettivamente Claude Code.

Ci sono cinque componenti: un sistema di permessi che decide cosa è consentito, controlli di accesso agli strumenti che delimitano le singole capacità, permessi MCP per le integrazioni esterne, sandboxing per l'isolamento a livello di OS e auditabilità per la revisione a posteriori. Ognuno risolve un problema diverso, ma si sommano.

Sistema di permessi

Il sistema di permessi è lo strato statico.

Dichiari ciò che Claude può fare in settings.json, usando tre liste: allow, ask e deny. Le regole vengono valutate prima deny, poi ask, poi allow, e vince il primo match. Una regola deny blocca la chiamata anche se una regola allow più ampia l'avrebbe fatta passare.

Se nessuna regola corrisponde, Claude ricade sul defaultMode della sessione (maggiori dettagli sulle modalità nella prossima sezione).

Controlli di accesso agli strumenti

I permessi si applicano agli strumenti, non all'agente nel suo complesso.

Claude Code ha un proprio set di strumenti integrati, ad esempio Bash per i comandi shell, Read, Edit e Write per le operazioni sul filesystem, WebFetch per le richieste HTTPS, WebSearch per le ricerche, e altri. Ogni regola nomina uno strumento e (opzionalmente) uno specificatore tra parentesi, come Bash(git commit:*) o Read(./.env).

Questo è ciò che rende possibile il principio del minimo privilegio. Puoi consentire Bash(npm run:*) per i test senza dare a Claude pieno accesso alla shell.

Permessi MCP

I server MCP estendono Claude Code con strumenti per cui non era stato progettato.

Ogni server porta il proprio set di strumenti (un server GitHub aggiunge strumenti per le pull request, un server database aggiunge strumenti di query, e così via). Il sistema di permessi li copre anch'essi, ma con una sintassi diversa: le regole usano la forma mcp__servername__toolname invece dello specificatore tra parentesi.

Il punto da ricordare è che MCP raddoppia più o meno la questione, perché non stai solo decidendo cosa può fare Claude con la tua shell, stai decidendo cosa può fare con ogni sistema esterno a cui l'hai collegato.

Sandboxing

Il sandboxing è la sicurezza a livello di sistema operativo sotto lo strumento Bash.

Le regole di permesso dicono a Claude cosa dovrebbe fare. Il sandboxing impone ciò che può fare, limitando l'accesso al filesystem e le chiamate di rete in uscita a livello di OS. Su macOS funziona subito tramite Seatbelt. Su Linux e WSL2 devi prima installare bubblewrap e socat.

I due strati funzionano in modo simile ma coprono scenari diversi. I permessi impediscono a Claude di provare qualcosa, e il sandboxing impedisce che il tentativo riesca se una prompt injection convince Claude a provarci comunque.

Auditabilità

L'ultimo tassello è poter vedere cosa è successo.

Il comando /permissions elenca ogni regola attiva e il file di impostazioni da cui proviene, così puoi rispondere alla domanda "perché Claude ha eseguito quello?" Gli hook (PreToolUse, PostToolUse e altri) ti permettono di registrare ogni chiamata di uno strumento sul tuo sistema. Per i team, gli esportatori OpenTelemetry inviano i dati di utilizzo e delle chiamate agli strumenti nello stack di osservabilità che già usi.

Permessi e controllo degli accessi in Claude Code

Gran parte della sicurezza deriva dalle impostazioni dei permessi, quindi è l'area su cui trascorrerai più tempo a ottimizzare.

Accesso ai file

Per impostazione predefinita, Claude può leggere e modificare i file nella directory da cui lo avvii.

La lettura è controllata dallo strumento Read, e la modifica da Edit e Write. Ognuno accetta un pattern di percorso tra parentesi, usando la sintassi in stile gitignore; ad esempio Read(**/.env) corrisponde a ogni file .env a qualsiasi profondità, e Edit(src/**) corrisponde a tutto ciò che si trova sotto src/.

Un deny su Read copre gli strumenti file di Claude Code (Read, Grep, Glob, LS), ma è solo un tentativo best-effort. Uno script Python o Node eseguito tramite Bash può comunque aprire il file, perché quella lettura avviene tramite la shell e non tramite lo strumento Read di Claude. Se un segreto è importante, combina il deny su Read con un deny su Bash per cat, head e tail su quei percorsi.

Per estendere l'accesso oltre la directory di lavoro, usa additionalDirectories in settings.json. È il modo per dare a Claude accesso a una libreria condivisa fuori dal tuo repo o a un file di configurazione nella tua home, senza eliminare del tutto il confine della directory di lavoro.

Esecuzione di comandi

Lo strumento Bash è quello da delimitare con più attenzione.

Una regola Bash senza specificatori consente ogni comando. Una regola con ambito come Bash(npm run:*) consente solo le invocazioni corrispondenti. Il pattern due-punti-stella è ciò che devi usare qui, e Claude Code comprende gli operatori della shell, quindi una regola come Bash(safe-cmd:*) non corrisponderà a safe-cmd && rm -rf /.

Alcuni comandi vengono eseguiti senza prompt in ogni modalità, perché sono trattati come di sola lettura per impostazione predefinita. L'elenco include ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd e le forme di sola lettura di git. Non puoi ridurre questo elenco manualmente, ma puoi aggiungere una regola ask o deny per uno qualsiasi di essi per sovrascrivere il default.

Per qualsiasi cosa non pre-approvata, Claude mostra un prompt in modalità predefinita. Il prompt mostra il comando esatto e ti permette di approvarlo una volta, approvare tutte le chiamate future che corrispondono a un pattern o negare.

Modalità di permesso

Le regole di permesso sono statiche, ma le modalità di permesso cambiano il comportamento delle chiamate non corrispondenti.

Ce ne sono cinque:

• default: chiede al primo utilizzo di ogni strumento.

• acceptEdits: approva automaticamente le modifiche ai file nella directory di lavoro, e continua a controllare i comandi shell. Utile quando ti fidi delle modifiche ma non della shell.

• plan: Claude legge e analizza, ma non può modificare file o eseguire comandi. La modalità giusta per code review o sessioni di pianificazione.

• dontAsk: nega automaticamente qualsiasi cosa non esplicitamente nella allow list.

• bypassPermissions: salta ogni prompt. Sicura solo in ambienti completamente isolati come un container o una VM.

Puoi scorrere le tre modalità principali con Shift+Tab a sessione in corso, o selezionarne una come default in settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Per i team, le impostazioni gestite ti danno uno strato che l'utente non può sovrascrivere. Il file segue lo stesso formato JSON e si trova in un percorso di sistema:

• /Library/Application Support/ClaudeCode/managed-settings.json su macOS

• /etc/claude-code/managed-settings.json su Linux

• C:\ProgramData\ClaudeCode\managed-settings.json su Windows

Le regole di deny nelle impostazioni gestite valgono per ogni progetto sulla macchina, ed è così che fai rispettare regole come "nessuno legge i file .env" o "nessuno esegue bypassPermissions" in tutta l'organizzazione.

Il principio alla base di tutto questo è il minimo privilegio, lo stesso che applicheresti a qualsiasi account di servizio. 

Dovresti iniziare con il set più piccolo di permessi che consente di svolgere il lavoro e allargarli solo quando incontri un ostacolo. Le linee guida di Anthropic vanno nella stessa direzione: rivedi le modifiche che Claude apporta, controlla le tue regole con /permissions e mantieni le impostazioni specifiche del progetto sotto controllo versione così che il team sia allineato su ciò su cui Claude può lavorare.

Sandboxing in Claude Code

Più consenti a Claude di operare in autonomia, più ha senso il sandboxing.

Lo strumento Bash ha l'esposizione più ampia perché i comandi shell possono leggere qualsiasi file che puoi leggere tu e modificare qualsiasi cosa per cui abbiano permessi di scrittura. Il sandboxing impone confini a livello di OS su ogni comando Bash e sui suoi figli, così Claude può operare più liberamente dentro il perimetro senza che tu debba approvare ogni chiamata. Anthropic l'ha integrato proprio per supportare esecuzioni autonome più sicure.

Un dettaglio importante è che il sandbox copre solo Bash e i suoi processi figli. Non limita gli strumenti Read, Edit o Write, che passano comunque dal sistema di permessi.

Sandboxing nativo

Il sandbox nativo è integrato in Claude Code e si attiva con /sandbox.

Su macOS, il sandboxing usa il framework Seatbelt integrato e non c'è nulla da installare. Su Linux e WSL2, installi bubblewrap per l'isolamento del filesystem e socat per il proxy di rete. Windows nativo non è supportato, quindi esegui Claude Code all'interno di una distribuzione WSL2.

Il confine del filesystem è facile da capire. Le letture funzionano ovunque tranne che sui percorsi negati, e le scritture funzionano solo dentro la directory di lavoro e i percorsi aggiuntivi che consenti. Se provi a scrivere su ~/.bashrc dall'interno del sandbox riceverai "Operazione non consentita" prima ancora che Claude sappia di aver fallito.

Il confine di rete è un po' diverso. Il traffico in uscita passa attraverso un server proxy che gira fuori dal sandbox, che controlla ogni richiesta rispetto alla tua lista allowedDomains. I domini nuovi attivano invece un prompt di permesso, così vedi esattamente a cosa sta cercando di accedere Claude.

Una configurazione funzionante è così:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Nell'uso interno di Anthropic, il sandboxing riduce i prompt di permesso dell'84%.

Container di sviluppo

I dev container sono il passo successivo in termini di isolamento.

Anthropic ha un devcontainer di riferimento per Claude Code che configura un ambiente Ubuntu, monta il tuo repo e fornisce all'agente una shell in cui lavorare. Il vantaggio rispetto al sandboxing nativo è la riproducibilità, perché tutti nel team ottengono lo stesso ambiente, con gli stessi strumenti e la stessa configurazione.

Lo svantaggio, però, è l'overhead. 

Aggiungi build del container, montaggio dei file e (a volte) un ciclo di feedback più lento quando usi i container. Per un singolo sviluppatore, il sandbox nativo è di solito sufficiente. Per l'uso in team o in CI, questa configurazione vale la pena.

Isolamento basato su Docker

Per sessioni autonome di agenti di lunga durata, Docker può ampliare ulteriormente il perimetro del sandboxing.

Di solito la configurazione è questa:

• Immagine base minimale: rimuovi gestori di pacchetti e strumenti di rete non necessari al task.
• Utente non root: Claude non gira mai come root, quindi non può modificare file di sistema o installare pacchetti globali.
• Filesystem root in sola lettura: monta la root del container in sola lettura, con solo specifiche directory di output scrivibili.
• Proxy in uscita: instrada la rete in uscita attraverso un proxy che consente il registry dei pacchetti (npm, PyPI) e nega tutto il resto, così comandi come npm install funzionano ma un curl arbitrario no.
• Limiti di risorse: imposta limiti a CPU, memoria e I/O così un processo non può bloccare l'host.

Le Docker Sandboxes danno a ogni sandbox la propria microVM con un demone Docker privato. Il demone host non può nemmeno vedere le sandbox in docker ps. Il confine è più vicino a una VM che a un container, il che chiude la maggior parte dei percorsi di fuga dai container che preoccupano gli sviluppatori.

Strategie di sandboxing per l'enterprise

Per le organizzazioni, la domanda è come stratificare le tecniche di sandbox, non se usarle.

Ecco come la maggior parte le affronta:

• Le regole di permesso vanno in managed-settings.json e non possono essere sovrascritte dai singoli sviluppatori.

• Il sandboxing nativo gira sotto lo strato dei permessi.

• Dev container o Docker girano sotto a quello.

• Per gli scenari a massima fiducia (accesso in produzione, gestione segreti), l'ultimo strato è una VM dedicata senza mount del filesystem dell'host.

Claude Code sul web è una versione gestita della stessa idea. Ogni sessione gira in una VM gestita da Anthropic, credenziali sensibili come i token git sono posizionate fuori dal sandbox in un proxy, e il confine è applicato dall'infrastruttura.

Sicurezza MCP in Claude Code

MCP è la parte di Claude Code che cresce più rapidamente.

Ogni server MCP che connetti moltiplica grosso modo ciò che Claude può fare, ma moltiplica anche la superficie che una prompt injection o una dipendenza compromessa può raggiungere. 

Per esempio:

• Un server MCP GitHub dà a Claude accesso alle pull request.
• Un server MCP per database gli dà il tuo schema e le query.
• Un server Slack gli dà i tuoi canali.

Nulla di ciò è un problema, ma significa che MCP ha bisogno di una propria governance. I contenuti recuperati tramite uno strumento MCP (una pagina web o una risposta API) possono contenere istruzioni iniettate che Claude esegue come se le avessi digitate tu. Inoltre, ogni server aggiunge una credenziale e un percorso di autenticazione da gestire separatamente.

Permessi degli strumenti

Gli strumenti MCP usano una convenzione di denominazione diversa dagli strumenti integrati.

Il formato delle regole è mcp__servername__toolname, senza specificatore tra parentesi. Ad esempio, mcp__github__create_pull_request consente a Claude di chiamare esattamente quello strumento, e un deny su mcp__github__delete_repo blocca quello pericoloso. Le liste allow, ask e deny funzionano come per Bash o Read.

Si applicano anche le stesse regole di precedenza: prima deny, poi ask, poi allow. Un deny nelle impostazioni gestite su mcp__github__delete_* è valido in ogni progetto sulla macchina.

Permessi delle risorse

I server MCP possono esporre risorse insieme agli strumenti.

Una risorsa è un dato che il server rende disponibile per la lettura da parte di Claude (un file in un server di project management o una riga in un server database). L'accesso alle risorse segue lo stesso controllo di fiducia delle chiamate agli strumenti, e una prima connessione a un server MCP esegue un passaggio di verifica della fiducia prima che uno qualsiasi dei suoi strumenti o risorse sia raggiungibile.

Il default corretto è trattare le risorse come un altro strumento. Se non concederesti la credenziale, non concedere l'accesso alla risorsa.

Server MCP approvati

L'Anthropic Directory elenca i connettori che Anthropic ha revisionato in base ai suoi criteri di listing.

Per le organizzazioni, un buon schema è usare una allowlist interna. Ci sono due impostazioni che ti danno il controllo:

• allowedMcpServers: un pattern glob dei server che gli sviluppatori possono aggiungere ai loro progetti (ad esempio, company-* per consentire solo server mantenuti internamente).

• deniedMcpServers: un pattern di server che non possono essere aggiunti, anche se lo sviluppatore prova.

Per i server obbligatori che dovrebbero essere presenti in ogni sessione, un file managed-mcp.json posizionato nelle impostazioni gestite è il modo per distribuirli. Gli sviluppatori non possono rimuovere o modificare le voci.

Un'impostazione da evitare nei repo condivisi è enableAllProjectMcpServers, che approva automaticamente ogni server MCP definito in .mcp.json. È comoda per il lavoro in solitaria e pericolosa per qualsiasi cosa versionata, perché una PR malevola può aggiungere un nuovo server a .mcp.json e farlo eseguire senza prompt.

Accesso agli strumenti a minimo privilegio

Stesso principio dei permessi Bash, solo applicato a MCP.

La domanda iniziale è quale credenziale ha ogni server. Un server MCP per database dovrebbe connettersi a una replica di lettura con accesso in sola lettura, non al primario con diritti di scrittura. Un server MCP per API dovrebbe usare un token limitato al set minimo necessario di endpoint, non un token personale con accesso completo all'organizzazione. E così via.

I subagent sono un altro modo per delimitare l'accesso MCP. Una definizione di subagent in .claude/agents/ può dichiarare esattamente quali strumenti ha a disposizione (usando la sintassi mcp:<server>:<tool>), così un "deploy-agent" ottiene il server di infrastruttura e un "review-agent" ottiene solo Read, Grep e Glob. L'agente non può chiamare strumenti che non gli sono stati assegnati.

Governance MCP

Per un team o un'organizzazione che esegue Claude Code su larga scala, MCP necessita della stessa forma di governance di qualsiasi altra integrazione di produzione.

Ciò significa un registro di server approvati con proprietari nominati, tracce di audit end-to-end delle invocazioni degli strumenti (quali strumenti MCP sono stati chiamati, da chi, con quali parametri) e una revisione periodica della lista di approvazione. Gli esportatori OpenTelemetry in Claude Code ti forniscono i dati di audit in un formato che si integra nello stack di osservabilità che già utilizzi.

Per le organizzazioni più grandi, un gateway MCP centralizzato è la versione più pulita di questo. 

Gli sviluppatori si connettono al gateway invece di registrare singoli server. Il gateway gestisce l'autenticazione, applica l'accesso basato sui ruoli a livello di strumento ed emette un'unica traccia di audit. Risolve anche la proliferazione di credenziali, perché un set di credenziali al gateway sostituisce ogni sviluppatore in possesso di una copia di ogni chiave API.

Gestione dei segreti e dati sensibili

Claude Code può leggere tutto ciò che puoi leggere tu, il che rende i segreti raggiungibili.

Per impostazione predefinita, Claude Code può leggere ogni file a cui il tuo account utente può accedere. Ciò include i file .env nel tuo progetto, le credenziali AWS in ~/.aws/, le chiavi private SSH in ~/.ssh/, i token GitHub nel tuo file rc della shell e le variabili d'ambiente in qualsiasi processo figlio creato da Claude. È perfettamente normale e voluto.

Tieni i segreti fuori dallo spazio di lavoro

La prima mossa è assicurarsi che i segreti non siano nella directory che Claude sta leggendo.

.env è il caso più comune. Sono nella root del progetto, vengono caricati da ogni strumento di sviluppo e contengono esattamente i valori che non vuoi in un contesto Claude (URL di database e chiavi API). 

Ecco un paio di schemi che puoi usare:

• Sposta i segreti in una directory fuori dall'albero di lavoro, ad esempio ~/.config/myapp/secrets.env, e caricali tramite un gestore di ambienti o una configurazione direnv che punti al file esterno.

• Per il lavoro containerizzato, mantieni una cartella .secrets/ fuori dal bind mount così che il file sia invisibile dall'interno del container.

• Aggiungi Read(**/.env) e Read(**/.env.*) alla tua lista permissions.deny e abbinale a deny su Bash(cat:*/.env) così che uno script shell non possa leggere ciò che lo strumento Read non può.

Usa un gestore di segreti

Per qualsiasi cosa oltre i progetti demo, il posto giusto per i segreti è un secret manager.

Lo schema è lo stesso a prescindere dal fornitore (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). I segreti sono inseriti nel manager. La tua shell o il runtime li recuperano su richiesta e li espongono solo al processo che ne ha bisogno. Claude non vede mai il valore effettivo.

Per Claude Code nello specifico, questo significa impostare CLAUDE_CODE_SUBPROCESS_ENV_SCRUB per rimuovere le credenziali di Anthropic e del cloud provider dai processi figli, o usare sandbox.credentials per disattivare variabili specifiche per i comandi in sandbox. La prima impedisce a Claude di passare il tuo ANTHROPIC_API_KEY in uno script di build, e la seconda copre il caso più ampio di qualsiasi variabile d'ambiente sensibile che finisca in un comando shell.

Limita l'accesso al repository

La terza opzione è a livello di repo.

Se uno sviluppatore non ha bisogno di accesso in scrittura a configurazioni solo di produzione, nemmeno la sua sessione di Claude Code ne ha bisogno. Sembra ovvio, ma il default per la maggior parte dei team è che gli sviluppatori abbiano accessi più ampi di quelli che usano abitualmente, e Claude eredita tutto ciò.

Ecco due passi che puoi intraprendere:

• Dividi la configurazione di produzione in un repo separato con accessi più rigidi, così l'ambiente di sviluppo in cui lavora Claude non ha i segreti di produzione fin dall'inizio.

• Usa token con scope per qualsiasi servizio con cui Claude interagisce. Ad esempio, un token GitHub per il lavoro di code review non ha bisogno di repo:delete.

Sicurezza di Claude Code per i team

Uno sviluppatore singolo può modificare settings.json come vuole. Un team no, perché la sicurezza complessiva è solo tanto forte quanto la configurazione più debole sulla macchina più debole. Per le distribuzioni a livello di team e organizzazione, Claude Code ha uno strato separato di controlli che un admin impone e che gli utenti non possono sovrascrivere.

Impostazioni gestite

Le impostazioni gestite sono le fondamenta.

Il file si trova in un percorso di sistema che richiede privilegi di admin per essere scritto:

• /Library/Application Support/ClaudeCode/managed-settings.json su macOS

• /etc/claude-code/managed-settings.json su Linux

• C:\ProgramData\ClaudeCode\managed-settings.json su Windows

Le impostazioni in questo file hanno la precedenza su quelle a livello utente e progetto. Una regola di deny qui è una regola di deny per ogni progetto sulla macchina, e lo sviluppatore non può rimuoverla modificando il proprio settings.json. La maggior parte delle organizzazioni distribuisce il file tramite MDM (Mobile Device Management) o lo stesso canale di configurazione usato per gli altri strumenti di sviluppo.

Ecco alcune impostazioni da conoscere a livello gestito:

• permissions.deny per percorsi sensibili e comandi pericolosi

• defaultMode impostato su default o plan (mai bypassPermissions)

• allowManagedPermissionRulesOnly: true per bloccare il set di permessi

• enableAllProjectMcpServers: false per richiedere approvazione esplicita dei MCP

• Configurazione dell'esportatore OpenTelemetry per il logging

Policy di permessi condivise

Un team che concorda su ciò che Claude può fare dovrebbe versionare tale accordo.

Le impostazioni a livello di progetto si trovano in .claude/settings.json alla root del repo. Qualsiasi cosa versionata qui si applica a chiunque esegua Claude in quel repo. Il file è il posto giusto per allow e deny specifici del progetto.

Tenendo presente ciò, c'è una distinzione tra impostazioni gestite e di progetto da conoscere:

• Le impostazioni gestite contengono la policy dell'organizzazione (nessuno esegue bypassPermissions, nessuno legge i .env).

• Le impostazioni di progetto contengono convenzioni di workflow (i test di questo repo si eseguono con npm test; lo script di deploy di questo repo è off-limits).

Governance del team

Per un rollout di team, lo strato di policy ha bisogno di un owner.

La maggior parte dei team che usa Claude Code su larga scala finisce con un piccolo gruppo, di solito sicurezza e piattaforma, che possiede le impostazioni gestite, la allowlist MCP, gli script hook e la pipeline OpenTelemetry. Lo stesso gruppo gestisce le richieste di eccezione e adatta le policy man mano che emergono nuovi casi d'uso.

Dovresti puntare ad avere questi elementi per iscritto:

• Quali repo sono in scope e quali no, con modalità a rischio graduato (un repo che tratta dati regolamentati probabilmente esegue Claude in modalità plan, mentre un repo del sito marketing può girare in acceptEdits).
• Chi può concedere eccezioni e come vengono tracciate.
• Una cadenza di revisione (trimestrale è comune) in cui il team rivede regole di permesso, server MCP e dati sugli incidenti.

Audit logging

Claude Code emette eventi OpenTelemetry per ogni decisione di strumento, connessione a server MCP, cambio di modalità di permesso e richiesta API. Nessun dato fluisce finché un admin non configura l'endpoint OTLP nelle impostazioni gestite.

Ecco un blocco minimo di impostazioni gestite per la telemetria:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Per impostazione predefinita, il contenuto dei prompt e i parametri degli strumenti sono esclusi dall'export, quindi gli eventi che raccogli sono metadata, non l'intera conversazione. Per includere il testo dei prompt, imposti OTEL_LOG_USER_PROMPTS=1. Per includere gli argomenti degli strumenti (che è ciò che di solito vuoi per l'audit), imposti OTEL_LOG_TOOL_DETAILS=1. Entrambe le decisioni hanno implicazioni sulla privacy, quindi la maggior parte dei team le tratta come scelte di policy deliberate e configura il backend di telemetria per filtrare o redigere prima dello storage.

Monitoraggio dell'uso

Lo stesso flusso OpenTelemetry che sta dietro all'audit è anche alla base del monitoraggio dell'uso.

Claude Code esporta metriche per l'uso di token, costo per richiesta, conteggio delle sessioni e tassi di decisione sugli strumenti. Quando aggregate, queste ti dicono quali team ottengono più valore, quali workflow producono più rifiuti e quali modelli generano il costo. Backend come Datadog, Honeycomb, SigNoz, Elastic e Splunk ingeriscono tutti il formato standard OTLP.

Un picco di eventi permission_decision con decision=deny può significare che Claude sta provando troppo, ma può anche significare che le regole di allow del team sono troppo restrittive.

Errori comuni di sicurezza in Claude Code

Un piccolo set di configurazioni errate ricorre nella maggior parte degli incidenti legati a Claude Code. Ora ti mostrerò quali sono e cosa farci.

Permessi troppo ampi

Il modo più rapido per attenuare il sistema di permessi è consentire troppo.

I prompt per comando aggiungono attrito, e la scorciatoia facile è una allow ampia Bash(*) o un'impostazione defaultMode: bypassPermissions. Entrambe annullano gran parte di ciò che fa il sistema di permessi.

Dovresti delimitare le regole allow agli strumenti e comandi specifici che usi davvero (ad esempio Bash(npm test:*) e Bash(git status)), e lasciare che tutto il resto ricada su un prompt. All'inizio avrai più prompt, ma in poche sessioni avrai messo in allow i comandi che usi e i prompt quasi scompaiono.

Accesso MCP non ristretto

Il secondo errore è connettere server MCP senza verificare quali credenziali usano o a cosa possono accedere.

Di solito succede perché qualcuno abilita enableAllProjectMcpServers, connette qualche server dalla directory pubblica MCP e non torna più a rivederli. Quando un server con credenziali deboli fa trapelare qualcosa di sensibile, la connessione è talmente indietro nella configurazione che nessuno ricorda di averla approvata.

La soluzione è la stessa dei permessi. Usa una allowlist esplicita tramite allowedMcpServers, un managed-mcp.json interno per i server che servono a tutti, e una cadenza di revisione della lista.

Nessun sandboxing

Se il sandboxing è disattivato, il sistema di permessi è l'unica cosa tra Claude e il tuo filesystem.

Va bene per sessioni interattive brevi in cui approvi comunque ogni comando. Non va bene per esecuzioni autonome, per sessioni in cui hai ampliato le regole allow o per qualsiasi lavoro che tocchi codice da fonti esterne.

/sandbox lo attiva. Se le dipendenze non sono installate, il menu ti mostra quali installare per la tua piattaforma. Una volta attivato, i prompt di permesso diminuiscono e l'OS intercetta i casi che le tue regole allow non coprono.

Accettare i cambiamenti alla cieca

acceptEdits è sia comodo che rischioso.

Quando Claude riscrive una funzione e tu lo stai monitorando, l'auto-accept va bene. Quando Claude itera su 30 file per un'ora, tendi a smettere di leggere i diff e a fidarti dell'agente. È lì che possono sorgere i problemi.

Ecco due abitudini da prendere:

• Fai sempre un commit prima di lasciare che Claude operi in autonomia, così il rollback è a un git reset di distanza.

• Rivedi il diff prima di ogni commit firmato da Claude, non il diff cumulativo alla fine della sessione.

Ignorare le tracce di audit

Un team che esegue Claude Code senza telemetria non ha modo di rispondere alla domanda "quale sessione l'ha fatto?" Gli eventi si accumulano localmente su ogni macchina e restano lì. La prima volta che hai bisogno di una traccia di audit è anche il momento peggiore per scoprire di non averla configurata.

Il minimo indispensabile è esportare gli eventi tool_decision, permission_decision e api_request nello stack di osservabilità che il team già usa. Da lì, costruisci dashboard e alert man mano che emergono i casi d'uso.

Conclusione

Lo scenario peggiore per un chatbot è una risposta sbagliata. Ma per un agente di coding, è un comando shell eseguito in produzione con le tue credenziali.

Ecco perché i tre pilastri contano:

• I permessi decidono cosa è autorizzato a fare Claude
• I controlli MCP decidono quali sistemi esterni può raggiungere
• Il sandboxing decide cosa succede quando i primi due non bastano

Ognuno copre una modalità di fallimento che gli altri non coprono. Insieme, definiscono il perimetro effettivo dentro cui lavora Claude.

Se stai cercando di ottenere una certificazione in AI generativa, qui trovi confronti, corsi migliori, consigli per la preparazione e FAQ per le Migliori certificazioni in AI generativa nel 2026.