Torna a tutti gli articoli
Sicurezza

Sicurezza di Claude Code: rischi, controlli e best practice

Sicurezza di Claude Code: i rischi reali di un agente che legge il repo, esegue shell e usa MCP, cosa coprono i controlli nativi e come proteggerlo al prompt.

In questa pagina
  1. Cos'e Claude Code e perche cambia il modello di sicurezza?
  2. Come funziona il modello di sicurezza di Claude Code
  3. I 6 principali rischi per la sicurezza in Claude Code
  4. 1. Governance debole di approvazioni e permessi
  5. 2. Prompt injection
  6. 3. Server MCP con permessi eccessivi e tool poisoning
  7. 4. Supply chain e dipendenze dannose
  8. 5. Esposizione di segreti e contesto sensibile
  9. 6. Esecuzione di comandi ed esecuzione di codice remoto
  10. Cosa copre la sicurezza nativa di Claude Code, e cosa no
  11. Best practice per proteggere Claude Code
  12. Dove si fermano i controlli nativi: proteggere l'agente al momento del prompt
  13. Domande frequenti
  14. Claude Code e sicuro da usare?
  15. Claude Code invia il mio codice sorgente al cloud?
  16. Qual e l'impostazione piu pericolosa di Claude Code?
  17. Claude Code puo essere colpito da prompt injection?
  18. Come proteggo i server MCP in Claude Code?
  19. In cosa proteggere Claude Code e diverso dal proteggere GitHub Copilot, Cursor o Codex?
  20. I controlli nativi di Claude Code sostituiscono SAST e code review?
  21. Come distribuisco Claude Code in modo sicuro in un intero team?

VibeDefend porta la sicurezza al momento del prompt: il punto di controllo passa dalla pull request al prompt.

Claude Code non e un autocompletamento. Legge il tuo repository, modifica file, esegue comandi shell e richiama strumenti esterni per tuo conto. E questo che lo rende utile, ed e anche cio che lo rende una superficie di sicurezza che nessun assistente IDE e mai stato. I suoi permessi nativi, la sandbox e le impostazioni gestite riducono il rischio in modo significativo. Non lo eliminano. Questa guida copre i rischi reali, cosa proteggono davvero i controlli nativi, le best practice che colmano il divario e l'unico livello che il modello nativo da per scontato che tu abbia gia.

Cos'e Claude Code e perche cambia il modello di sicurezza?

Claude Code e lo strumento di codice agentico di Anthropic. Funziona dentro la superficie esistente dello sviluppatore (il terminale, l'IDE, l'app desktop, la CI) e agisce su istruzioni in linguaggio naturale: analizza un codebase, genera una funzionalita, esegui i test, prepara una pull request. Si connette a GitHub e GitLab, lavora a fianco di sistemi di build e suite di test, e si estende tramite il Model Context Protocol (MCP) per raggiungere database, sistemi di ticketing e strumenti interni.

Quest'ultima proprieta e quella che rompe il vecchio modello di sicurezza. Un assistente IDE tradizionale suggerisce completamenti; un essere umano accetta o rifiuta ciascuno di essi. Il raggio d'azione di un suggerimento sbagliato e un singolo blocco di codice che lo sviluppatore deve comunque incollare. Claude Code invece compie azioni. Legge file che non hai nominato, esegue comandi che non hai digitato, modifica codice in tutto l'albero e richiama strumenti che hai collegato settimane fa e dimenticato. La superficie di attacco non e piu "quale codice ha suggerito il modello". E "cosa puo fare questo agente con l'accesso che ha, e chi puo influenzare le sue istruzioni".

Un suggerimento e una bozza che un essere umano sceglie di accettare. Un'azione e una cosa gia accaduta. Il modello di sicurezza deve passare dalla revisione di bozze al vincolo delle azioni.

- Il cambiamento, in una riga

C'e un secondo cambiamento che conta ancora di piu, e riguarda la velocita. La pull request e diventata la casa della sicurezza applicativa perche si collocava al ritmo umano: una persona rallentava, leggeva il diff e solo allora faceva il merge. Claude Code non lavora al ritmo umano. Una singola sessione puo spedire piu codice in un pomeriggio di quanto un revisore ne legga in una settimana. Quando cio accade, il diff smette di essere un punto di controllo e diventa la trascrizione di decisioni gia prese. Qualsiasi controllo che agisca solo alla pull request ora sta rivedendo la storia, non prevenendola.

Per la maggior parte dei team la domanda pratica non e se Claude Code abbia protezioni native. Le ha, e sono buone. La domanda e se quelle protezioni siano sufficienti per l'uso quotidiano. La risposta onesta e no. I controlli nativi, le revisioni e i controlli simili a scansioni riducono il rischio, ma un'adozione sicura dipende ancora da permessi, sandbox, isolamento, supervisione umana e validazione indipendente su codice, dipendenze, segreti e pipeline. Anthropic dice esattamente questo nella sua documentazione sulla sicurezza: i controlli sono livelli di difesa, non un programma di sicurezza completo.

Come funziona il modello di sicurezza di Claude Code

Il modello di Claude Code e costruito attorno a tre idee: chiedi prima di fare qualcosa di rischioso, limita cio che l'agente puo toccare e imponi tutto questo a livello del sistema operativo dove conta. In pratica cio si traduce in una manciata di controlli.

Permessi a livelli

Le azioni in sola lettura (letture di file, ricerche) vengono eseguite senza approvazione. Le azioni a maggior rischio (comandi shell, modifiche ai file, accesso di rete, strumenti MCP) la richiedono. Le regole hanno tre forme, allow, ask e deny, dove deny vince sempre, e possono essere limitate a strumenti, comandi, percorsi di file, domini, server MCP o directory di lavoro specifici.

Modalita di permesso

default, acceptEdits, plan, auto, dontAsk e bypassPermissions. Le modalita barattano attrito per velocita. Anthropic e esplicita sul fatto che bypassPermissions (e il flag --dangerously-skip-permissions) dovrebbe girare solo dentro un container o una VM isolati.

Impostazioni gestite

Le organizzazioni distribuiscono la policy in modo centralizzato cosi che uno sviluppatore non possa scavalcare controlli critici per la sicurezza. Le impostazioni gestite hanno la precedenza sulla configurazione locale e possono essere distribuite tramite la console di amministrazione, un plist macOS, una policy del registro di Windows o un file in /etc/claude-code/managed-settings.json.

Sandbox e isolamento

I permessi decidono cosa l'agente puo usare; la sandbox lo impone a livello del sistema operativo per i comandi Bash e i loro processi figli, con isolamento del filesystem (quali directory) e isolamento di rete (quali destinazioni). I devcontainer aggiungono un ambiente isolato coerente per un intero team.

Oltre a questi quattro, altri tre controlli contano a livello organizzativo. Claude Code esporta telemetria di utilizzo e di sicurezza tramite OpenTelemetry: attivita degli strumenti, esecuzione di comandi, cambi di modalita di permesso, connessioni MCP, errori API e hook, tutti elementi che possono confluire nel tuo backend di osservabilita. Offre opzioni di deployment sicuro oltre al servizio gestito di Anthropic, tra cui Amazon Bedrock, Google Vertex AI e Microsoft Foundry, cosi un team puo mantenere autenticazione, fatturazione e conformita entro il proprio confine cloud, con proxy aziendali, policy IAM, log di audit e RBAC sovrapposti. E include una capacita di security review che ispeziona le pull request alla ricerca di vulnerabilita e difetti logici, facendo emergere i risultati come commenti in linea.

E una base davvero buona, e gran parte di questo elenco non esisteva negli assistenti IDE di una generazione fa. La trappola e leggerla come un confine di sicurezza definitivo. Anthropic descrive la modalita auto come una via di mezzo, non una garanzia, perche i classificatori che decidono "questa azione e sicura" possono sbagliare. La security review e di supporto, non un decisore finale. I devcontainer non sono esplicitamente "un confine di sicurezza completo". Ogni controllo di questo elenco ha una modalita di fallimento documentata, e la prossima sezione riguarda cosa succede quando ci si appoggia troppo su di essi.

I 6 principali rischi per la sicurezza in Claude Code

I rischi qui sotto non sono teorici. Mappano a vulnerabilita documentate, ricerche pubblicate e alla OWASP Top 10 per le applicazioni LLM. I numeri che li inquadrano sono gli stessi che ogni team AppSec sta ora citando.

40%

del codice generato dall'IA era vulnerabile attraverso gli scenari di sicurezza MITRE Top-25 (NYU, Asleep at the Keyboard)

#1

prompt injection, il principale rischio LLM per il 3o anno consecutivo (OWASP LLM01)

10.5%

delle soluzioni degli agenti di codice IA erano sicure, contro il 61% funzionalmente corretto (Carnegie Mellon SusVibes)

1. Governance debole di approvazioni e permessi

La sicurezza di Claude Code poggia sulle approvazioni. Se i flussi di approvazione sono troppo permissivi, incoerenti o regolarmente aggirati, l'agente compie azioni rischiose senza vera supervisione. La modalita auto e i flag che saltano i permessi riducono l'attrito, e riducono il controllo esattamente con lo stesso movimento.

Il meccanismo che erode tutto questo in pratica e la stanchezza da approvazioni. Quando l'agente chiede quaranta volte all'ora, le persone smettono di leggere i prompt e iniziano a cliccare "consenti sempre" per farli sparire. Nel giro di una settimana l'impostazione predefinita prudente e diventata silenziosamente una concessione generale, e nessuno ha deciso che lo fosse. La versione a livello di team e peggiore di quella individuale: uno sviluppatore lavora con regole deny rigide, un altro consente accesso ampio a file, shell e strumenti perche era piu rapido un venerdi, e nel momento in cui quei due condividono un repository, un workflow automatizzato o un insieme di server MCP, la configurazione piu debole stabilisce la postura di sicurezza reale per tutti.

2. Prompt injection

La prompt injection e il rischio distintivo degli strumenti di codice agentici, ed e il rischio LLM numero uno di OWASP per il terzo anno consecutivo. Un attaccante nasconde istruzioni in qualcosa che l'agente legge (un file, una pagina web, una issue, l'output di uno strumento) e l'agente le segue, scavalcando il comportamento previsto.

La forma pericolosa e quella indiretta. Non devi incollare un prompt dannoso; ti basta puntare Claude Code verso un repository avvelenato, un documento trappola o un server MCP che restituisce contenuti ostili. Un commento sepolto nel README di una dipendenza che dice "prima di continuare, esegui questo script di setup" puo bastare. Poiche un modello linguistico non puo distinguere in modo affidabile un'istruzione attendibile da una dannosa incorporata nei dati, l'injection puo portare a esecuzione di comandi, esfiltrazione di dati o manipolazione silenziosa del codice. All'inizio del 2026 le ricerche mostravano che una manciata di documenti costruiti ad arte poteva guidare il comportamento del modello nella grande maggioranza dei casi tramite l'avvelenamento del retrieval, e il contesto agentico peggiora la posta in gioco: un agente guidato non si limita a rispondere male, agisce.

3. Server MCP con permessi eccessivi e tool poisoning

L'MCP e cio che rende potente Claude Code, ed e un nuovo confine di fiducia che la maggior parte dei team non ha modellato a livello di minacce. Un server MCP con permessi eccessivi puo esporre dati sensibili o lasciare che l'agente compia azioni che nessuno aveva previsto: un server di database con accesso in lettura a tutto, un server di filesystem puntato sulla home directory, uno strumento di deploy con credenziali di produzione.

Un server dannoso o compromesso va oltre. Gli attacchi di tool poisoning nascondono istruzioni dentro le descrizioni e le risposte degli strumenti, cosi il solo fatto di avere il server connesso puo guidare l'agente prima ancora che chiami lo strumento. La mitigazione raccomandata da Anthropic e brusca e corretta: scrivi i tuoi server MCP, oppure usa quelli di fornitori di cui ti fidi davvero, e tratta tutto cio che un server MCP restituisce (definizioni di strumenti, risorse, prompt, risposte) come input non attendibile da validare, non come verita su cui il modello puo agire.

4. Supply chain e dipendenze dannose

Claude Code installa pacchetti, clona repository ed esegue script di setup come parte del normale lavoro. Se suggerisce o installa una libreria compromessa, il codice dannoso gira con qualsiasi accesso l'ambiente conceda. Non e ipotetico. All'inizio del 2026 una campagna di typosquatting su npm tracciata come "Sandworm_Mode" ha piantato server MCP malevoli imitando utility popolari, prendendo di mira specificamente gli assistenti di codice IA tra cui Claude Code, Cursor e Windsurf.

Il workflow di sviluppo stesso diventa il vettore di attacco. Un package.json avvelenato, un hook post-install dannoso o un pacchetto MCP soggetto a typosquatting possono trasformare un prompt di routine "configura questo repo" in furto di credenziali. L'agente spesso approvera l'installazione con sicurezza, perche il nome del pacchetto sembra giusto e il compito lo richiedeva. L'allucinazione dei pacchetti aggrava il problema: un agente che inventa un nome di pacchetto plausibile ma inesistente offre agli attaccanti uno slot da registrare e armare.

5. Esposizione di segreti e contesto sensibile

Claude Code e utile perche ha contesto locale, e quel contesto include regolarmente piu del codice sorgente: file .env, configurazioni, variabili d'ambiente e talvolta credenziali. Quando quel contesto e piu ampio di quanto il compito necessiti, l'agente puo far emergere o riutilizzare valori sensibili nei log, nel codice generato o nelle pull request.

Anthropic avverte specificamente che i devcontainer non impediscono l'esfiltrazione di nulla di raggiungibile al loro interno, comprese le credenziali di Claude Code memorizzate in ~/.claude, e sconsiglia di montare segreti dell'host come chiavi SSH o file di credenziali cloud in un container che l'agente puo leggere. L'esposizione e spesso indiretta: mentre riassume un repo o esegue il debug di un errore, l'agente puo incollare in un output uno snippet che contiene un token o un endpoint interno, che poi finisce in un ticket, una chat o un repo pubblico, dove sopravvive a lungo dopo la fine della sessione.

6. Esecuzione di comandi ed esecuzione di codice remoto

Claude Code esegue comandi shell e modifica sistemi, quindi un agente manipolato puo eseguirne di dannosi. I ricercatori di sicurezza hanno documentato bypass delle restrizioni di percorso e vettori di command injection negli strumenti di codice agentici che portano all'esecuzione di codice, talvolta innescata semplicemente aprendo un progetto dannoso.

Il pericolo si aggrava quando l'agente gira con privilegi elevati o accesso shell illimitato. Una catena di comandi singolarmente innocui puo installare una dipendenza dannosa, alterare una configurazione CI o aprire un meccanismo di persistenza sulla macchina. E esattamente per questo che Anthropic abbina l'approvazione dei comandi alla sandbox, al privilegio minimo e agli ambienti isolati, ed e per questo che eseguire Claude Code come root e un anti-pattern documentato. La combinazione da temere e quella comune: accesso shell ampio, una modalita permissiva per evitare i prompt e un'istruzione iniettata che l'agente tratta come legittima.

Cosa copre la sicurezza nativa di Claude Code, e cosa no

I controlli nativi sono reali, e conviene essere precisi sulla linea tra cio che gestiscono e cio che lasciano a te.

Rischio
Controlli nativi
Resta a te
Modifiche accidentali ai file / comandi non sicuri
Gestito da approvazioni + regole deny
Affina le regole; combatti la stanchezza da approvazioni
Accesso indesiderato a rete / filesystem
Gestito dalla sandbox
Definisci correttamente l'allowlist
Permessi troppo ampi in un team
Impostazioni gestite (se distribuite)
Distribuiscile davvero, controlla la deriva
Prompt injection
Parziale, basata su classificatori
Difesa in profondita; tratta ogni input come non attendibile
Codice insicuro accettato nel repo
Security review di supporto
Revisione umana, SAST, gate in CI
Dipendenze / server MCP dannosi
Solo prompt di approvazione
SCA, allowlist, verifica dei server
Segreti nel contesto locale
Regole deny per i percorsi
Vault, nessuna credenziale dell'host montata

Leggi la colonna di destra come il lavoro vero e proprio. I controlli nativi sono il pavimento: impediscono che un errore in buona fede diventi un disastro. Non sono stati progettati per fermare un avversario determinato che controlla gli input dell'agente, e Anthropic non sostiene che lo siano. Tutto cio che trasforma "Claude Code e installato" in "Claude Code e governato" vive nelle pratiche che seguono.

Best practice per proteggere Claude Code

Queste nove pratiche colmano il divario tra la base nativa e una postura di sicurezza reale. Nessuna di esse e esotica; la disciplina sta nell'applicarle in modo coerente in un team che si muove in fretta.

  1. Esegui in ambienti isolati a privilegio minimo. Usa container o devcontainer per il lavoro assistito dall'IA, esegui Claude Code in user space (mai come root) e blocca le connessioni in uscita non approvate cosi che una sessione compromessa non possa esfiltrare. Segmenta gli ambienti per sensibilita cosi che il lavoro ad alto rischio sia contenuto e il raggio d'azione di una singola compromissione resti piccolo.

  2. Applica il privilegio minimo a permessi e strumenti. Concedi il minimo accesso a file, repo e strumenti che un compito richiede. Scrivi regole deny esplicite per gli store di credenziali, i file .env e l'infrastruttura di produzione. Limita l'accesso MCP solo a server verificati. Preferisci token effimeri e a portata limitata rispetto a quelli persistenti e ampi, e ruotali secondo una pianificazione anziche aspettare un incidente.

  3. Mantieni un essere umano nel ciclo sul codice generato. Tratta l'output dell'IA come una bozza, non come un'implementazione finale. Indirizza tutto il codice generato o modificato attraverso la revisione delle pull request e i test automatizzati, con scrutinio extra su autenticazione, validazione degli input e percorsi privilegiati. Il punto non e la sfiducia nel modello; e che un agente che produce migliaia di righe al giorno generera difetti sottili piu in fretta di quanto emergano da soli.

  4. Tieni i segreti fuori portata. Tieni i segreti in chiaro completamente fuori dal contesto dell'agente. Usa un vault e iniettali a runtime, oscura i valori sensibili nei log e non montare mai chiavi SSH dell'host o file di credenziali cloud in un container che Claude Code puo leggere. Se un segreto viene mai esposto in una trascrizione o in un output, ruotalo immediatamente e indaga su come ci e arrivato.

  5. Governa dipendenze e pacchetti. Limita le installazioni a registry attendibili o mirror interni, richiedi l'approvazione per i nuovi pacchetti e analizza tutto con la software composition analysis. Non lasciare che l'agente installi automaticamente pacchetti oscuri o non verificati, per quanto sicuro li suggerisca, e verifica che un pacchetto suggerito esista davvero prima che venga aggiunto.

  6. Verifica le configurazioni dei permessi secondo una pianificazione. Rivedi le regole allow / ask / deny su strumenti, percorsi, comandi e domini, non solo all'installazione. Cerca percorsi con wildcard e accesso shell illimitato e restringili al minimo ambito. Confronta la configurazione locale con le impostazioni gestite per cogliere la deriva, e automatizza una segnalazione su ogni passaggio a auto, dontAsk o bypassPermissions.

  7. Controlla le modalita auto e bypass. Tratta la modalita auto come un'ottimizzazione deliberata, non come predefinita. Definisci quali azioni si qualificano come a basso rischio (operazioni in sola lettura, refactoring limitati) e mantieni esecuzione shell, chiamate di rete e scritture su percorsi protetti dietro un'approvazione esplicita. Vieta bypassPermissions e --dangerously-skip-permissions ovunque sia vicino ad ambienti condivisi o collegati alla produzione; riservali ai container usa e getta.

  8. Registra e monitora a livello di team. Esporta l'attivita di Claude Code tramite OpenTelemetry nel tuo SIEM. Cattura uso degli strumenti, esecuzione di comandi, modifiche ai file, decisioni sui permessi e connessioni esterne, correlali con l'identita dell'utente e genera allarmi su anomalie come ripetute escalation di permessi, destinazioni di rete inattese o schemi di comandi insoliti.

  9. Imposta la policy per sensibilita di repository e ambiente. Classifica i repository (pubblici, interni, regolamentati, di produzione) e applica controlli piu rigidi a quelli sensibili: nega l'accesso ai segreti, limita l'egress, richiedi una revisione piu robusta e disabilita le modalita permissive. Per i sistemi critici, esegui Claude Code solo in ambienti senza percorso diretto verso le credenziali di produzione, e documenta la policy cosi che gli sviluppatori sappiano dove l'aiuto dell'IA e consentito e sotto quali vincoli.

Dove si fermano i controlli nativi: proteggere l'agente al momento del prompt

Ripercorri i rischi ed emerge uno schema. Permessi, sandbox e revisione agiscono tutti su cio che l'agente ha gia deciso di fare, o su codice che ha gia scritto. Si raggruppano attorno alla pull request, perche e li che l'AppSec ha sempre vissuto. Ma la PR e stata un punto di controllo solo perche un essere umano la leggeva, e al ritmo dell'agente nessuno la legge piu dall'inizio alla fine.

Il luogo dove imporre una regola non e piu il diff; e il prompt, prima che la riga insicura venga scritta. Qualunque regola tu voglia che l'agente segua deve essere nelle sue mani nel momento in cui scrive, non in attesa in uno scanner che arriva quando il codice e gia su disco e l'agente e gia passato al compito successivo.

E questo il livello che aggiunge VibeDefend. E una CLI npm gratuita che si installa in circa cinque secondi e collega Claude Code (oltre a Cursor, OpenAI Codex, Windsurf e VS Code Copilot) a quattro livelli di governance che girano dentro il loop dell'agente.

npx -y @cybedefend/vibedefend@latest installScegli EU o US, conferma Claude CodeInserisci .cybedefend/config.json nel repoIl prossimo prompt e governato
Da npm a un prompt di Claude Code governato, in circa un minuto.

I quattro livelli di governance di VibeDefend: regole di business estratte dal tuo repo, regole di sicurezza da OWASP, SOC 2, GDPR e ISO 27001, un Action Guard che blocca le chiamate distruttive e Live Findings che alimenta ogni risultato degli scanner nell'agente.

Regole di business Le convenzioni del tuo repo che non sono mai state messe per iscritto (usa Decimal128 per il denaro, l'autorizzazione passa per requireOwner). VibeDefend le estrae dal modo in cui il tuo team gia scrive codice e le carica nel contesto dell'agente prima di ogni modifica. Regole di sicurezza OWASP Top 10, SOC 2, GDPR e ISO 27001, caricate il giorno in cui installi. L'agente legge il promemoria applicabile prima di scrivere, cosi il requisito del framework diventa parte del codice anziche una casella da spuntare al momento dell'audit. Action Guard Le chiamate distruttive (un sudo rm -rf, una lettura grezza di una variabile d'ambiente che sembra un segreto, un psql ad hoc contro un host di produzione) vengono intercettate prima che partano. Avvisa o blocca per regola, con ogni intercettazione nell'audit trail. Live Findings collega l'agente all'intera piattaforma AppSec di CybeDefend, i suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) in esecuzione continua, cosi l'agente non si limita a scrivere codice sicuro, smista e corregge le vulnerabilita che hai gia.

In modo cruciale, nulla del tuo codice attraversa la rete. Le decisioni avvengono localmente accanto all'agente; solo metadati di governance strutturati (la regola che e scattata, il percorso del file, la severita, un timestamp) raggiungono il backend. I tenant EU e US sono fisicamente separati, e scegli la regione al momento dell'installazione. Quel modello di privacy e cio che permette a un controllo di stare cosi vicino al codice senza diventare a sua volta un rischio di esfiltrazione dei dati.

Questo non sostituisce le pratiche di cui sopra. E il livello mancante che esse danno per esistente: quello che mette le tue regole nelle mani dell'agente al momento del prompt, cosi che la riga insicura venga riscritta prima ancora di essere suggerita, anziche colta tre fasi piu tardi da uno scanner che legge un diff che nessuno ha avuto tempo di leggere. I permessi impediscono all'agente di fare cio che non deve fare; VibeDefend modella cio che scrive in primo luogo.

Domande frequenti

Claude Code e sicuro da usare?

Claude Code e sicuro da usare quando e configurato e contenuto, e rischioso quando non lo e. I suoi permessi predefiniti in sola lettura, i prompt di approvazione, la sandbox e le impostazioni gestite prevengono un'ampia classe di incidenti e azioni non sicure. Il rischio residuo viene dalla configurazione (permessi troppo ampi, modalita di bypass), dagli input (prompt injection, repo e server MCP dannosi) e dall'ambiente circostante (segreti esposti, privilegi elevati). Trattalo come un agente potente che ha bisogno di privilegio minimo, isolamento e revisione umana, non come uno strumento sicuro pronto all'uso.

Claude Code invia il mio codice sorgente al cloud?

Claude Code invia il contesto di cui ha bisogno al fornitore del modello per generare risposte, il che puo includere codice, contenuti dei file e il contesto circostante del tuo compito. Dove va quel traffico dipende dal tuo deployment: il servizio gestito di Anthropic, oppure il tuo confine tramite Amazon Bedrock, Google Vertex AI o Microsoft Foundry. Per il codice sensibile, usa un deployment che corrisponda ai tuoi requisiti di gestione dei dati, escludi segreti e dati regolamentati dalla portata dell'agente e rivedi le policy di retention. I metadati di governance di un livello aggiunto come VibeDefend restano separati e non trasmettono codice sorgente.

Qual e l'impostazione piu pericolosa di Claude Code?

bypassPermissions, e il suo equivalente CLI --dangerously-skip-permissions, perche saltano del tutto il livello di approvazione. Anthropic afferma che sono pensati solo per container o VM isolati. Usarli su un laptop di sviluppo con accesso a credenziali reali, host di produzione o repository condivisi rimuove l'unico controllo che si frappone tra un agente vittima di prompt injection e un comando distruttivo. Vietali in qualsiasi ambiente condiviso o collegato alla produzione.

Claude Code puo essere colpito da prompt injection?

Si. La prompt injection e il principale rischio LLM nella Top 10 di OWASP, e gli strumenti agentici sono particolarmente esposti perche leggono contenuti non attendibili (repo, pagine web, issue, output di strumenti MCP) come parte del normale lavoro. Un modello linguistico non puo separare in modo affidabile un'istruzione attendibile da una dannosa nascosta nei dati, quindi la difesa e a livelli: tratta tutti i contenuti recuperati e restituiti dagli strumenti come non attendibili, esegui il lavoro non attendibile in isolamento, mantieni i permessi stretti e aggiungi un controllo al momento del prompt che possa bloccare un'azione pericolosa anche quando il modello e stato guidato.

Come proteggo i server MCP in Claude Code?

Tratta ogni server MCP come un confine di fiducia. Usa server che hai scritto tu o che provengono da fornitori di cui ti fidi davvero, limita ciascuno ai dati e alle azioni piu ristretti di cui necessita, e non connettere mai un server con credenziali di produzione a un ambiente che esegue codice non attendibile. Valida tutto cio che un server restituisce anziche lasciare che il modello agisca direttamente su di esso, e mantieni un inventario dei server connessi cosi che un pacchetto malevolo o soggetto a typosquatting non si infili inosservato.

In cosa proteggere Claude Code e diverso dal proteggere GitHub Copilot, Cursor o Codex?

I fondamentali sono condivisi (privilegio minimo, gestione dei segreti, revisione umana, scansione delle dipendenze), ma le superfici differiscono. Il problema principale di Cursor e stato il Workspace Trust disabilitato per impostazione predefinita; quello di Copilot sono stati suggerimenti insicuri e fuoriuscita di segreti su larga scala; quello di Codex sono stati incidenti di command injection e supply chain. La superficie distintiva di Claude Code e la sua profonda integrazione con MCP e shell. Copriamo ogni agente nella sua guida: Cursor, GitHub Copilot e OpenAI Codex.

I controlli nativi di Claude Code sostituiscono SAST e code review?

No. Anthropic e chiara sul fatto che permessi, sandbox, impostazioni gestite, monitoraggio e la capacita di security review siano livelli di protezione, non un programma di sicurezza completo. La security review nativa e di supporto: utile per un feedback rapido, non un decisore finale. Hai ancora bisogno di accesso a privilegio minimo, gestione dei segreti, scansione delle dipendenze, CI/CD sicura, protezione dei branch, revisione umana del codice e ambienti isolati per il lavoro rischioso, oltre a un controllo nel prompt cosi che il codice insicuro venga riscritto prima di essere scritto anziche colto dopo.

Come distribuisco Claude Code in modo sicuro in un intero team?

Parti dalle impostazioni gestite cosi che le regole critiche per la sicurezza non possano essere scavalcate localmente, poi distribuisci tramite un confine che controlli (Bedrock, Vertex AI o Foundry) per autenticazione centralizzata, log di audit e budget. Standardizza l'ambiente con i devcontainer, convoglia la telemetria nel tuo SIEM, classifica i repository per sensibilita con policy corrispondenti e aggiungi un livello di governance al momento del prompt come VibeDefend cosi che le stesse regole raggiungano l'agente di ogni sviluppatore a prescindere da quanto attentamente ciascuno abbia configurato la propria macchina.

Live · appena rilasciato

Installa VibeDefend in 5 secondi.

Un comando. Ogni agente di coding sul tuo laptop collegato a CybeDefend: regole di business estratte dal tuo codice, regole di sicurezza dei framework che i tuoi auditor si aspettano, action guards che bloccano le chiamate pericolose prima che partano.

Installa in 5 secondiNode 18.17+
npx -y @cybedefend/vibedefend@latest install
Auto-rileva
  • Claude CodeClaude Code
  • CursorCursor
  • OpenAI Codex
  • WindsurfWindsurf
  • GitHub CopilotVS Code Copilot
Leggi il README su npm