Come un repository altrui può dirottare Claude Code: 7 regole di protezione

Documentazione di Ailoot: API, chiavi e configurazione.

Quattro percorsi documentati dal testo non attendibile alle azioni dell’agente#

Formalmente, si parla di prompt injection indiretta: l'istruzione malevola non arriva direttamente da te, ma attraverso i dati che l'agente elabora mentre svolge un'attività, per esempio un README di terzi, un messaggio di errore, un commento su GitHub o una risposta da un servizio esterno. Puoi dimenticare il termine subito dopo questo paragrafo: da qui in poi userò parole semplici.

Quattro esempi di ricerca discussi sotto:

1. Un repository dall'aspetto innocuo è stato mostrato trasformarsi in una reverse shell.
2. Il titolo di una Pull Request è stato mostrato dirottare tre agenti AI diversi contemporaneamente.
3. È stato mostrato che un agente accettava una falsa segnalazione di errore da Sentry al posto di una reale.
4. Una descrizione di uno strumento MCP è stata mostrata controllare il tuo agente con la stessa efficacia di un system prompt.

In che modo il README di un repository innocuo si trasforma in una reverse shell?#

Il proof of concept 0DIN del 25 giugno 2026 mostra questa catena, con passaggi apparentemente ordinari:

1. Cloni un repository dall'aspetto normale e chiedi a Claude Code di eseguirlo.
2. Il repository installa un pacchetto Python progettato per fallire al primo utilizzo.
3. Il messaggio di errore suggerisce cortesemente un comando di “correzione”: python3 -m axiom init.
4. Il comando init esegue setup.sh.
5. Lo script interroga un record DNS TXT (usato di solito per note relative a un dominio, ma il campo accetta testo qualsiasi). L'aggressore vi inserisce un comando codificato in base64 (un modo per trasformare qualsiasi dato in testo semplice senza spazi o caratteri speciali) e lo passa direttamente a bash.
6. Il valore del record DNS può essere modificato in qualsiasi momento, dando all'aggressore una reverse shell interattiva con i permessi dell'utente e accesso a tutti i segreti sulla macchina.

Nel caso dimostrato il payload era recuperato a runtime da DNS: analizzare soltanto i byte del repository non rivelava il contenuto finale. Non dimostra impotenza di ogni scanner o controllo: esame dei dati recuperati, monitoraggio dei processi e restrizioni di rete possono rilevare o interrompere la catena. La fonte è un proof of concept, non una misura degli incidenti reali.

In che modo il titolo di una Pull Request ha dirottato tre agenti AI diversi?#

Il ricercatore descrive percorsi e risposte seguenti: è un rapporto storico, non una verifica di ogni versione attuale.

Sono passati quasi cinque mesi tra la prima e l'ultima segnalazione di questo ciclo di divulgazione (la prima segnalazione su Claude Code risale al 17 ottobre 2025; l'ultima correzione di bug di GitHub Copilot è del 9 marzo 2026). Il cambio di gravità e le mitigazioni non dimostrano la chiusura completa di ogni payload. Il repository PoC del ricercatore documenta il percorso dimostrato per Claude; non eseguirne il payload contro sistemi reali. Il valore per te sta nello schema d'attacco: dati non verificati da GitHub entrano nell'agente, l'agente esegue comandi e i segreti vengono divulgati attraverso lo stesso GitHub; all'aggressore non serve alcun server esterno.

Bastano due analisi per vedere lo schema: non è praticabile correggere singolarmente ogni nuova scoperta; vulnerabilità di questo tipo emergono ogni due settimane. Scrivere esplicitamente le regole di sicurezza in CLAUDE.md e settings.json, invece di tenerle a mente, fa parte del context engineering: le imposti una volta e funzionano automaticamente in ogni nuova sessione di Claude Code, senza promemoria.

Una falsa segnalazione di errore di Sentry può prendere il controllo del tuo agente?#

Per l'attacco non serve altro che una chiave DSN di Sentry, un identificatore pubblico che molti progetti includono direttamente nel codice lato client:

Il meccanismo è semplice: uno sviluppatore chiede all'agente di esaminare gli errori Sentry aperti; l'agente li richiede tramite il server MCP, riceve un evento malevolo mescolato a quelli reali e legge il comando incorporato come un'istruzione attendibile per correggere l'errore, perché formalmente è proprio ciò che gli è stato chiesto di fare.

Tenet riferisce che i controlli esistenti non hanno generato allarmi nei suoi ambienti provati. Non dimostra esecuzione senza tracce ovunque: log di agenti/strumenti, telemetria degli endpoint e registri di rete possono rilevare le azioni successive. L’attacco parte da telemetria esterna e dipende da strumenti e permessi effettivi.

Perché la descrizione di uno strumento MCP è pericolosa quanto un system prompt?#

La formulazione di Microsoft è la più precisa che abbia trovato su questo tema:

Questa tecnica è chiamata tool poisoning: un’istruzione nascosta nella descrizione di uno strumento innocuo induce l’agente ad agire di conseguenza.

Nel test citato, Claude 3.7 Sonnet ha ottenuto i migliori risultati di resilienza, pur rifiutando l’istruzione avvelenata in meno del 3% dei casi. L’osservazione sui modelli più capaci riguarda gli strumenti e le impostazioni di quel benchmark: non è una regola universale né una probabilità per le installazioni attuali.

Cosa hanno in comune gli attacchi e cosa può sfuggire al rilevamento?#

La conclusione vale per tutte e quattro le scoperte: non ci si può fidare dell'aspetto normale del codice, perché ogni singolo passaggio dell'attacco è davvero innocuo. Limita le capacità effettive ed esamina le azioni proposte: rilevamento e contenimento coprono parti diverse dell’attacco.

Quali protezioni include già Claude Code e perché non bastano?#

Anthropic riconosce direttamente il problema nella sua documentazione, senza nasconderlo:

Secondo la documentazione, l'agente analizza l'intero prompt alla ricerca di istruzioni sospette, non approva automaticamente curl e wget, mantiene i contenuti web in una finestra di contesto separata per evitare che si mescolino con quella principale e richiede una conferma di attendibilità al primo avvio in una nuova codebase o alla connessione di un nuovo server MCP.

Ma c'è un'avvertenza netta, dichiarata senza mezzi termini da Anthropic:

Se hai mai avviato Claude Code con --dangerously-skip-permissions per esasperazione, per far sì che “smettesse di assillarti con le domande”, hai disattivato proprio tutti i meccanismi che avrebbero potuto fermare i quattro attacchi discussi sopra. Tengo deliberatamente disattivato questo flag, anche quando Claude Code me lo chiede per la decima volta in una sessione: è fastidioso, ma quelle domande sono il confine tra “l'agente ha letto un testo sospetto” e “l'agente lo ha eseguito”. Una configurazione sensata per chi non programma consiste nella modalità di autorizzazione standard (default o acceptEdits) con la sandbox attiva: le normali modifiche ai file avvengono senza richieste aggiuntive, mentre i comandi del terminale non possono uscire fisicamente dalla sandbox, anche se l'agente è stato ingannato.

Come si attiva la modalità sandbox e si colma la lacuna che lascia aperta per impostazione predefinita?#

Per attivarla in modo permanente per tutti i progetti, apporta una modifica a ~/.claude/settings.json:

{
  "sandbox": { "enabled": true }
}

Per impostazione predefinita, i comandi in sandbox possono scrivere solo nella directory di lavoro del progetto e nella directory temporanea della sessione. L'accesso alla rete passa da un proxy: nessun dominio è consentito in anticipo e Claude Code chiederà conferma al primo contatto con un nuovo dominio. Anthropic afferma che ciò riduce nettamente le richieste di autorizzazione, dell'84% secondo le misurazioni interne dell'azienda, perché la sandbox gestisce autonomamente alcuni casi sicuri invece di chiederti conferma ogni volta.

La lacuna lasciata aperta dalle impostazioni standard: per impostazione predefinita la sandbox limita la scrittura, ma non impedisce di leggere file come ~/.aws/credentials e ~/.ssh. Sono proprio i file e le variabili d'ambiente presi di mira dagli attacchi citati sopra. Colma questa lacuna con un blocco separato nello stesso file:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Il punto è che, anche se la reverse shell della prima analisi si apre dentro la sandbox, queste variabili e questi file vengono rimossi materialmente dall'ambiente del processo prima dell'avvio: non resta nulla da rubare.

Quali regole permissions.deny dovresti aggiungere oggi?#

Un insieme minimo per chi non programma, che copre contemporaneamente i principali obiettivi di tutti e quattro gli attacchi:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

Secondo la documentazione di Claude Code, le regole deny hanno sempre la precedenza sulle regole allow. Quindi, anche se tu o l'agente avete accidentalmente consentito un accesso più ampio altrove, una regola deny specifica continua ad applicarsi per prima. La precedenza vale per richieste corrispondenti. Non dimostra che un segreto sia irraggiungibile da ogni sottoprocesso o strumento: usa anche restrizioni forzate del file system e dell’ambiente.

Claude Code dispone anche di una modalità auto, in cui un modello classificatore separato controlla le azioni prima che vengano eseguite: non è lo stesso modello che conversa con te. Per impostazione predefinita blocca, tra le altre cose, proprio lo schema “scarica il codice e poi eseguilo subito” (curl | bash). Anthropic avverte esplicitamente che si tratta di una modalità sperimentale che riduce il numero di richieste ma non garantisce la sicurezza da sola: considerala un livello aggiuntivo, non un sostituto della sandbox e di permissions.deny.

Come controllare un repository e un server MCP prima di affidargli il tuo agente?#

Ecco una breve lista di controllo da seguire prima di affidare repository all'agente:

1. Non passare direttamente all'installazione da un link in un'email, un post o una recensione proveniente da una fonte sconosciuta: è così che possono essere distribuiti questi repository.
2. Se l'installazione produce un errore con l'istruzione “esegui il comando X per correggerlo”, leggi cosa fa davvero X prima di consentire a Claude Code di eseguirlo. L'istruzione nell'analisi precedente sembrava del tutto normale: era proprio questo il punto.
3. Controlla l'età del repository e la cronologia dei commit, non solo il numero di stelle: ai repository appena creati si possono facilmente assegnare stelle false proprio per questo tipo di attacco.
4. Se il repository è sconosciuto, esegui l'installazione in una macchina virtuale, non sul tuo computer di lavoro con chiavi reali. È una raccomandazione esplicita di Anthropic per lavorare con servizi esterni.

La posizione di Anthropic sui server MCP è espressa apertamente:

Questo significa che sei tu, e non la piattaforma su cui li hai installati, a dover controllare i server MCP di terzi. Alcuni team, soprattutto startup di sicurezza, stanno già sviluppando strumenti per farlo: scanner di configurazioni MCP che cercano descrizioni avvelenate e il “pinning” degli strumenti, che salva l'hash della descrizione al momento della prima installazione e segnala qualsiasi modifica successiva. Queste tecnologie sono giovani, quindi è troppo presto per affidarsi a esse come unica protezione, ma vale la pena seguirle, soprattutto se colleghi server MCP alla produzione. Per queste connessioni, puoi bloccare la versione di ogni pacchetto e registrare in un log di audit l'impronta digitale delle descrizioni degli strumenti.

7 regole di protezione: la lista di controllo di oggi#

1. Attiva la modalità sandbox (/sandbox o "sandbox": {"enabled": true} in ~/.claude/settings.json) e aggiungi un blocco credentials che impedisca di leggere ~/.ssh e ~/.aws/credentials.
2. Aggiungi regole permissions.deny per impedire la lettura di file segreti e l'esecuzione di comandi bash pericolosi (curl, wget, sudo): una regola deny prevale sempre su una allow.
3. Non eseguire mai --dangerously-skip-permissions con codice di terzi o non verificato: disattiva tutte le protezioni insieme, comprese quelle che avrebbero potuto fermare proprio questi attacchi.
4. Non lasciare che Claude Code esegua automaticamente un comando di “correzione” suggerito da un messaggio di errore: prima leggi cosa fa davvero.
5. Installa server MCP solo da fonti di cui ti fidi e ricorda che Anthropic non ne verifica la sicurezza per conto tuo.
6. Separa le sessioni in base ai permessi: una lavora con i tuoi dati personali e non vede dati esterni; una seconda esamina email, repository e ticket di altre persone, ma non ha accesso ai segreti; una terza pubblica all'esterno, e solo ciò che hai approvato personalmente. Nei miei progetti mantengo una separazione rigorosa: una sessione con accesso alle chiavi di pagamento non legge ticket o repository esterni arbitrari, e una sessione che analizza il codice di altre persone non vede affatto i segreti. Non mescolare questi ruoli in un'unica chat.
7. Mantieni aggiornati Claude Code e gli script di automazione collegati: al momento della pubblicazione di questa guida, la maggior parte delle lacune descritte era già stata chiusa con delle patch e quelle nuove vengono corrette in modo analogo.

Cosa fare ora#

Nessuno di questi livelli è una garanzia: Anthropic stessa afferma onestamente che nessuna protezione offre immunità completa. Non mi aspetto che Claude Code riconosca da solo un inganno in un messaggio di errore o in un commento su una issue. Per me, la sandbox e permissions.deny fanno parte integrante del modo in cui gestisco il contesto dei progetti: cosa vede l'agente, di cosa si fida per impostazione predefinita e cosa succede quando commette un errore.

Se ti serve accedere alle reti neurali tramite Ailoot, dai un'occhiata ad Ailoot.