Come tenere i tuoi segreti fuori dal codice generato dall'IA e dai commit Git

Gli agenti di coding IA sono veloci, ma hanno un punto cieco: incollano volentieri una chiave API in un file, stampano un token in un log o committano un .env che volevi tenere in locale. Ogni agente con accesso al terminale — Claude Code, Cursor, Gemini CLI, Codex — può anche leggere la configurazione della tua shell e i file di progetto, che è esattamente dove tendono a nascondersi le credenziali. Questa guida ti accompagna attraverso una configurazione pratica e a più livelli, così che i tuoi segreti restino fuori dal codice generato dall'IA e fuori dalla tua cronologia Git.

Perché conta di più con l'IA

Una chiave trapelata è uno degli errori più comuni e costosi nel software, e gli assistenti IA alzano la posta in due modi. Primo, generano codice rapidamente, quindi una chiave scritta a mano nel codice può finire in una dozzina di file prima che te ne accorga. Secondo, gli agenti ingeriscono il contesto in modo aggressivo — come afferma un approfondimento sulla gestione dei segreti, la configurazione della tua shell dovrebbe referenziare le chiavi, non contenerle, perché l'agente può leggere qualunque cosa i tuoi dotfile espongano. La soluzione non è diffidare dello strumento; è assicurarsi che non ci siano segreti in chiaro che possa trovare, in primo luogo.

Passo 1: tieni i segreti nelle variabili d'ambiente, mai nel codice

La regola di base: nessuna chiave API, password o token dovrebbe mai comparire come stringa letterale nel codice sorgente. Mettili in un file .env nella root del progetto e leggili a runtime.

# .env  — never committed
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://...

// app.js — reads from the environment, no secret in the file
const apiKey = process.env.ANTHROPIC_API_KEY;

In questo modo il codice che tu (e il tuo agente IA) modificate contiene solo il nome del segreto, mai il suo valore.

Passo 2: assicurati che .env non possa mai essere committato

Aggiungilo a .gitignore prima di scrivere un solo segreto:

.env
.env.local
*.env

Committa invece un .env.example con segnaposto vuoti, così che i collaboratori sappiano quali variabili impostare:

ANTHROPIC_API_KEY=
DATABASE_URL=

Se hai già committato un .env reale, rimuoverlo in un nuovo commit non è sufficiente — vive nella cronologia. Ruota immediatamente la chiave esposta e trattala come compromessa.

Passo 3: attiva la push protection di GitHub

La push protection di GitHub scansiona i commit mentre fai push e blocca il push se individua un segreto, fermando la fuga prima che raggiunga il remote. Riconosce oltre 200 pattern di segreti da provider come AWS, OpenAI, Stripe e molti altri, e gli aggiornamenti del 2026 hanno ampliato i pattern bloccati di default. È gratuita per i repository pubblici — attivala in Settings → Code security del tuo repo. Pensala come la cintura di sicurezza per il momento in cui un agente (o tu) commette un errore.

Passo 4: non lasciare che gli agenti raccolgano la configurazione della tua shell

Gli agenti con accesso alla shell possono leggere .zshrc, .bashrc e .zshenv. Se hai esportato lì delle chiavi per comodità, l'agente può vederle. Tieni i segreti a livello di macchina fuori dai tuoi dotfile — caricali da un secrets manager o dal keychain del sistema operativo al momento del bisogno, invece di esportare testo in chiaro all'avvio della shell.

Passo 5: definisci gli scope e ruota

Due abitudini limitano i danni se qualcosa trapela davvero, consiglio ripreso anche nella guida di OpenAI sulla sicurezza delle chiavi API:

• Privilegio minimo: assegna a ogni chiave lo scope più ristretto di cui ha bisogno e usa chiavi separate per progetto e ambiente, così che una fuga non esponga tutto.
• Ruota regolarmente: ruota le chiavi con cadenza programmata e immediatamente ogni volta che sospetti un'esposizione. Una chiave ruotata trasforma una violazione in un non-evento.

Una rapida checklist

Prima di lasciare un agente libero su un repo:

1. I segreti vivono in .env, letti tramite process.env — mai scritti a mano nel codice.
2. .env è in .gitignore; viene committato solo .env.example.
3. La push protection è abilitata sul remote.
4. Nessuna chiave in chiaro nei dotfile della shell.
5. Le chiavi hanno scope ristretti e vengono ruotate con cadenza programmata.

Nulla di tutto questo ti rallenta una volta configurato — e ti permette di affidare più lavoro al tuo agente IA con molte meno preoccupazioni.