Portare Claude Code a un team di cinquanta o cinquecento sviluppatori non è un problema di installazione, è un problema di policy. La domanda che ti farà il CISO non è «come si installa», ma «che cosa impedisce a uno sviluppatore di disattivarlo». La documentazione di amministrazione risponde con una gerarchia esplicita, e conviene attraversarla nell’ordine in cui la pone.

Quattro decisioni, in quest’ordine

La guida per amministratori struttura il lavoro come una mappa: quale provider API, come le impostazioni raggiungono i dispositivi, che cosa si applica, come si vede l’uso, come sono trattati i dati.

Il provider non è solo fatturazione. Scegliendo Amazon Bedrock, Google Cloud o Microsoft Foundry si eredita la postura di conformità di quel cloud, ma “Some Claude Code features require a claude.ai account”: Claude Code on the web, Routines, Code Review, Remote Control e l’estensione Chrome non sono disponibili con le sole chiavi Console o le credenziali di un cloud provider. È una decisione da prendere sapendo quali funzionalità si stanno spendendo.

Sulla consegna, quattro meccanismi in ordine di priorità: server-managed dalla console claude.ai, recuperate all’avvio e aggiornate ogni ora; plist macOS o registro HKLM; file managed-settings.json su percorso di sistema; registro utente HKCU. Su quest’ultimo la documentazione è esplicita: è scrivibile senza privilegi elevati, quindi va trattato “as a convenience default rather than an enforcement channel”.

macOS   /Library/Application Support/ClaudeCode/managed-settings.json
Linux   /etc/claude-code/managed-settings.json
Windows C:\Program Files\ClaudeCode\managed-settings.json

La gerarchia che decide chi vince

Cinque livelli, dal più forte al più debole: impostazioni gestite, riga di comando, progetto locale, progetto condiviso, utente. Il comportamento controintuitivo riguarda gli array: “Array settings such as permissions.allow and permissions.deny merge entries from all sources, so developers can extend managed lists but not remove from them.” Un team può quindi aggiungere permessi al proprio progetto, ma non togliere quelli che hai negato. Per fallbackModel, availableModels e modelPicker il valore gestito sostituisce invece i livelli inferiori.

La verifica si fa sul campo: /status mostra la riga Setting sources, che nomina la sorgente gestita selezionata.

Che cosa si blocca e che cosa invece si standardizza

Il confine va spiegato bene, perché l’errore più comune è credere di aver chiuso una porta rimasta aperta: “Denying WebFetch blocks Claude’s fetch tool, but if Bash is allowed, curl and wget can still reach any URL.” Permessi e sandboxing coprono strati diversi, e l’allowlist di dominio applicata dal sistema operativo chiude quel varco.

Sugli MCP la posizione di partenza è permissiva — “By default, anyone running Claude Code can connect any MCP server they choose” — e Anthropic “doesn’t security-audit or manage any MCP server”. I pattern vanno dal disattivare tutto al catalogo approvato:

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" },
    { "serverCommand": ["python", "/usr/local/bin/approved-server.py"] }
  ],
  "deniedMcpServers": [{ "serverName": "dangerous-server" }]
}

Con due avvertimenti per chi scrive la policy. Un’entrata serverName “is not a security control”, perché il nome è l’etichetta che assegna l’utente: solo serverCommand e serverUrl fanno enforcement. E quando una restrizione entra in vigore, un server già configurato scompare in silenzio da /mcp senza spiegazioni, quindi avvisare gli utenti fa parte del rollout.

Ciò che invece si standardizza senza vietare: un CLAUDE.md di policy nei percorsi gestiti, che non può essere escluso da nessuna impostazione individuale, e i plugin, cioè skill, agenti, hook e server MCP in un pacchetto versionato, distribuibile da un marketplace ospitato in un repository privato.

Misurare l’adozione senza esporre il contenuto

Due superfici con scopi diversi. OpenTelemetry esporta verso il tuo collector metriche ed eventi: sessioni, righe di codice, commit, pull request, costo, token, decisioni di permesso. Si accende con CLAUDE_CODE_ENABLE_TELEMETRY=1 più un exporter, e si segmenta per team con attributi di risorsa.

OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform"

Il punto che tranquillizza una revisione privacy: prompt, argomenti dei tool e corpi delle richieste sono disattivati per default e si abilitano solo con variabili dedicate, una per categoria.

Il cruscotto di analytics serve invece il discorso sull’adozione, e dichiara da solo il proprio limite: le metriche di contribuzione “are deliberately conservative and represent an underestimate”, non sono disponibili con Zero Data Retention attivo, e il codice riscritto dagli sviluppatori oltre il 20% non viene attribuito. Usarle come stima prudente è corretto; presentarle come misura esatta della produttività no.