BlogVersioniProblemiDocumentazioneDownloadStatoLooking GlassContatta le vendite
Security Blog

Il suo assistente di programmazione con IA ha appena letto il suo portafoglio

#111

October 2, 2026 · By Marketing team

← All posts

Gli strumenti di programmazione con IA leggono i file .env prima che Lei scriva qualsiasi cosa. Le sue chiavi API — ciascuna una carta di credito senza limite di spesa — finiscono nella finestra di contesto di qualcun altro prima che Lei scriva il suo primo prompt. Il problema non è l'IA. Il problema è che i segreti sono file.

Apra il suo assistente di programmazione con IA. Prima che Lei digiti un singolo carattere, ha già letto la directory del suo progetto. Il suo file .env. Le sue chiavi API. La password del suo database. La sua chiave segreta Stripe.

Non gliel'ha chiesto. Non lo ha approvato. È una funzionalità, non un difetto — lo strumento ha bisogno del contesto del progetto per essere utile. Quindi legge tutto ciò che uno sviluppatore può leggere.

E uno sviluppatore può leggere tutto.

La versione in greentext

Un post ha fatto il giro questa settimana, scritto come monologo interiore di uno sviluppatore:

> Apri Claude Code. Il tuo .env viene letto prima che tu scriva qualsiasi cosa. Le tue chiavi API ora sono nella chat. Aggiungi "non leggere .env" a CLAUDE.md. Non funziona.

380.000 persone hanno visto quel post. 2.700 l'hanno aggiunto ai segnalibri. Non perché fosse una novità — perché era uno specchio.

Ogni sviluppatore che lo leggeva ha avuto lo stesso pensiero: è la mia configurazione.

Le istruzioni non funzionano

La prima cosa che le persone hanno provato è stata scrivere regole. "Non leggere i file .env." In CLAUDE.md, in AGENTS.md, nei prompt di sistema. Divieti diretti ed espliciti.

Lo strumento ha letto comunque i file.

Questo ha senso se ci si riflette. Il file viene letto come parte della costruzione del contesto del progetto — prima ancora che le istruzioni vengano elaborate. Dire al modello di non leggere un file che ha già letto è come dire a qualcuno di dimenticare ciò che ha appena visto. L'informazione è nella finestra di contesto. È già stata trasmessa. L'istruzione arriva dopo il danno.

Un ricercatore ha scoperto che anche le regole di negazione a livello di file potevano essere aggirate tramite script personalizzati o catene di pipe. Un altro ha riscontrato bollette proxy gonfiate perché le sue credenziali HTTP_PROXY venivano caricate e usate automaticamente.

I soldi nel suo .env

Le persone inquadrano questo come un problema di privacy. È un problema finanziario.

Apra un tipico file .env in un progetto in produzione:

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgresql://user:pass@...

Quella chiave OpenAI è una carta di credito senza limite di spesa e senza PIN. Chi possiede quella stringa può generare 40.000 dollari di chiamate API in una notte. La chiave Stripe può emettere rimborsi, creare addebiti, accedere ai dati di pagamento dei clienti. Le credenziali AWS — a seconda della policy IAM, che è quasi certamente troppo ampia — possono avviare istanze GPU, accedere a bucket S3 o eliminare infrastruttura.

Non è un elenco di password. È un elenco di portafogli, ciascuno con un saldo diverso e nessuna serratura.

29 milioni di portafogli sul marciapiede

L'ultimo rapporto di GitGuardian ha contato 28,6 milioni di segreti esposti in commit pubblici su GitHub nel 2025. Un aumento del 34% rispetto all'anno precedente, e il più grande incremento annuo che abbiano mai misurato.

I numeri specifici per l'IA sono peggiori. 1,2 milioni di segreti di servizi IA esposti — un balzo dell'81% su base annua. I commit co-autorati da strumenti di programmazione con IA hanno fatto fuoriuscire segreti a un tasso circa doppio rispetto alla linea di base. E 24.000 segreti univoci sono stati trovati nei file di configurazione MCP — l'infrastruttura che collega gli agenti IA ai servizi esterni.

Dodici dei quindici tipi di segreti in più rapida crescita erano servizi IA. Non database. Non provider cloud. Servizi IA.

Gli strumenti che stiamo usando per scrivere codice più velocemente stanno facendo fuoriuscire le chiavi dei sistemi a cui quel codice si connette.

Il vero problema

Lo sviluppatore che ha pubblicato quel thread in greentext è arrivato a una soluzione pratica — una configurazione settings.json che blocca le letture dei file. Funziona. Per ora, per quello strumento.

Ma il vero problema non è Claude Code, né Cursor, né Copilot. Il vero problema è che i segreti sono file.

Un file .env è un documento in chiaro che giace su disco, leggibile da qualsiasi processo in esecuzione con il Suo utente. Prima degli strumenti di programmazione con IA, i processi che leggevano il Suo progetto erano git, npm, node, il Suo editor. Si fidava implicitamente di loro. Non pensava al fatto che i Suoi segreti fossero a un comando cat dall'esposizione.

Gli strumenti di programmazione con IA hanno semplicemente reso esplicito ciò che era implicito. Leggono il Suo progetto come lo fa ogni altro strumento — solo che capitagli di inviare il contesto da qualche parte dove Lei può vederlo.

Anche la Sua pipeline CI legge i file .env. Lo fa il Suo test runner. Lo fa il Suo linter. Lo fa la build Docker. Nessuno di loro ha chiesto il permesso nemmeno Lei. Semplicemente non se n'è accorto perché non Le mostravano una trascrizione di ciò che avevano trovato.

Il modello sottostante

Il 70% dei segreti fuoriusciti nel 2022 è ancora attivo oggi. Non ruotati. Non revocati. Ancora funzionanti, che concedono ancora accesso, tre anni dopo.

Questo è il numero reale. Non 29 milioni di fughe — il 70% mai sistemato. Perché ruotare una chiave significa trovare ogni sistema che la usa, aggiornare ogni deployment, testare ogni integrazione. La chiave è stata creata una volta, incollata in un file .env, e mai più presa in considerazione. Il costo della sua esposizione è istantaneo. Il costo della correzione è illimitato.

Quindi la maggior parte delle organizzazioni non lo corregge. Non può. Non sa quali chiavi sono dove, quali sono ancora attive, quali sono state copiate in altri file .env su altre macchine da altri sviluppatori che dovevano far funzionare una funzionalità un venerdì pomeriggio.

Cosa significa realmente

Ogni file .env è una scommessa. La scommessa che nessun processo lo leggerà senza averne il diritto. La scommessa che nessuno strumento lo invierà da qualche parte inaspettata. La scommessa che nessuno sviluppatore lo committerà per errore.

29 milioni di volte lo scorso anno, qualcuno ha perso quella scommessa. Solo su GitHub pubblico. I repository privati — dove GitGuardian ha trovato segreti nel 35% dei repository — non sono nemmeno conteggiati.

La soluzione non è una regola in settings.json. La soluzione non è una voce in .gitignore. La soluzione non è scrivere "DO NOT READ .ENV" in maiuscolo nel Suo file di istruzioni.

La soluzione è che il segretro non dovrebbe essere lì fin dall'inizio. Non in un file. Non in una variabile d'ambiente caricata da un file. Non in alcuna forma che un processo con i Suoi permessi possa leggere facendo ciò che fanno i processi: leggere i file nella directory del Suo progetto.

Se il segretro è su disco, verrà letto. L'unica domanda è quando, e da cosa.

---

Fonti