API key, token e segreti nel codice generato da AI: il rischio più sottovalutato

Un assistente AI può scrivere in pochi minuti codice che si collega a database, API di pagamento, bucket cloud, repository, sistemi SaaS, servizi email e ambienti di deploy. Per far funzionare tutto subito, però, il percorso più breve passa spesso da una chiave incollata in un file, una variabile stampata nei log, un .env creato al volo o un token copiato in chat durante il debug.

Il rischio dei segreti nel codice generato da AI non si riduce al classico hardcoding. API key, token, connection string e credenziali possono finire in prompt, cronologia chat, issue, log di build, artifact, source map, container image, test, README, file temporanei, configurazioni locali e workspace remoti usati dagli agenti. Il repository può sembrare pulito mentre una chiave resta esposta altrove.

Per developer, founder tecnici e DevOps, la domanda concreta prima del deploy è: quali segreti ha visto l’AI, dove sono stati salvati, quali sono arrivati nel repository, quali sono finiti in pipeline e quali devono essere ruotati prima che l’app tocchi dati reali o servizi di produzione.

Perché gli agenti AI aumentano il rischio sui segreti

Gli strumenti di AI coding lavorano dentro un contesto più ampio del singolo file: possono leggere porzioni di repository, generare file di configurazione, proporre script, modificare test, avviare comandi, spiegare errori e aiutare a collegare servizi esterni. In molti workflow, soprattutto con agent mode, terminale o ambienti remoti, l’assistente non si limita a suggerire codice ma partecipa attivamente al processo operativo.

Questo crea una nuova superficie per i segreti. Durante una sessione di debug, un developer può incollare una connection string per chiedere perché il database non risponde; l’agente può creare un .env.local per far passare un test; un comando può stampare variabili ambiente nei log; una build può includere una chiave nel bundle frontend. La velocità rende il problema meno visibile: quando il codice finalmente funziona, il team tende a concentrarsi sulla feature, ma una chiave esposta può dare accesso a pagamenti, cloud, database, repository, servizi SaaS, sistemi di produzione o dati cliente.

Che cosa conta come segreto

Un segreto non è solo una password. In un progetto moderno rientrano nel perimetro API key, token OAuth, personal access token, JWT secret, webhook secret, chiavi private, certificati, file .pem, service account, database URL, connection string, cookie di sessione, refresh token, deploy token, chiavi di firma, token GitHub o GitLab, credenziali cloud, password SMTP, token Slack, chiavi Stripe e chiavi di provider LLM.

Alcune chiavi sembrano “pubbliche” perché vengono usate nel frontend o nella documentazione del provider, ma anche in quei casi vanno compresi restrizioni, scope e possibilità di abuso. Una anon key Supabase non è la stessa cosa di una service role key, e un token di test può comunque leggere dati di staging, inviare email, consumare credito o aprire un percorso verso sistemi interni.

Prima di pubblicare, ogni segreto dovrebbe avere almeno quattro informazioni: a cosa serve, in quale ambiente vale, quali privilegi concede e dove è conservato. Se una chiave non ha owner, scadenza o scope chiaro, diventa difficile decidere cosa fare quando compare in un diff generato dall’AI.

Dove finiscono i segreti durante il vibe coding

Il primo luogo da controllare è il codice stesso: sorgenti, configurazioni, test, script, esempi e file generati. Gli agenti possono inserire valori reali in config.ts, settings.py, docker-compose.yml, workflow CI/CD, migration, seed, fixture, script di deploy o file di test, trasformando un esempio temporaneo in una configurazione che arriva al commit.

Il secondo luogo è il repository intorno al codice: file .env nelle varie varianti, backup, file .pem, chiavi scaricate da cloud provider, credenziali CLI, cartelle nascoste del tool, output di debug e file temporanei. Un .gitignore incompleto basta per trasformare una scorciatoia locale in un leak permanente nella history Git.

Il terzo luogo, spesso il più sottovalutato, è fuori dal repository: prompt, chat, ticket, issue, commenti di PR, log CI/CD, artifact, container image, source map, report di test, screenshot, crash reporting e sistemi di osservabilità. Cancellare una chiave dal file non rimuove la chiave dalla chat in cui è stata incollata o dal log in cui è stata stampata.

Hardcoding: quando il codice funziona subito ma espone troppo

Il pattern più semplice è anche il più frequente: per collegare un servizio, l’AI suggerisce una chiave direttamente nel codice o in un esempio copiabile. In una demo locale sembra innocuo, ma in una PR, in un repository condiviso o in un deploy automatico diventa un accesso reale. I casi più comuni includono database URL in file server-side, token API in funzioni di integrazione, chiavi di pagamento nei test, password SMTP in configurazioni, JWT secret hardcoded, webhook secret copiati in handler e service key usate per aggirare un problema di autorizzazione.

La correzione non è solo “sposta in variabile ambiente”. La variabile deve essere gestita in un secret manager o nel sistema di deploy con permessi corretti, separata per ambiente, non stampata nei log e non accessibile al frontend. Se la chiave è stata committata o condivisa, va ruotata.

File .env, ignore file e configurazioni locali

I file .env sono utili per lo sviluppo, ma diventano rischiosi quando l’AI li crea o li modifica senza una convenzione chiara. Un agente può generare .env.example con valori reali, suggerire .env.production per semplificare il deploy o inserire un file di credenziali nel progetto perché un SDK lo richiede.

È importante controllare .gitignore, .dockerignore, i file ignore del tool AI e quelli usati dall’IDE o dall’agente, perché in alcuni workflow serve impedire che cartelle locali, file .env, chiavi private, output di build o directory di configurazione entrino nel contesto dell’assistente. L’obiettivo non è solo evitare il commit: è ridurre ciò che l’agente può leggere e riutilizzare.

Un buon pattern è mantenere .env.example con nomi di variabili e valori fittizi, documentare dove ottenere le chiavi reali e usare secret manager o impostazioni protette della piattaforma per staging e produzione. Ogni file con valori reali dovrebbe restare fuori dal repository e fuori dai prompt.

Prompt, chat e cronologia dell’agente

Molti leak non nascono dal codice, ma dalla conversazione. Durante il debug è facile incollare un errore completo con header, token, URL firmati, payload, connection string o screenshot di dashboard: l’assistente risponde, la chat resta salvata e il team dimentica che quel segreto è uscito dal perimetro del progetto.

La regola operativa è semplice: non incollare segreti nei prompt. Quando si chiede aiuto su un errore, è sufficiente sostituire token e chiavi con placeholder, usare dati sintetici e ridurre i payload al minimo. Se una chiave reale è già stata condivisa in chat, va trattata come esposta: occorre verificare il provider, ruotarla e controllare eventuali accessi anomali.

Privacy Mode, piani enterprise o impostazioni di retention possono ridurre alcuni rischi, ma non trasformano un segreto incollato in chat in una buona pratica. Anche quando il dato non viene usato per training, può restare in cronologia, log, esportazioni, sistemi di supporto o contesto operativo del tool secondo le impostazioni del servizio.

Log di build, test e deploy

Gli script generati dall’AI possono stampare troppo. Un console.log(config), un printenv, un errore di inizializzazione, un test fallito o un comando di debug possono esporre variabili ambiente nei log CI/CD, che sono spesso visibili a più persone del repository, conservati per settimane o copiati in artifact.

Vale la pena controllare workflow GitHub Actions, GitLab CI, Vercel, Netlify, Replit, Docker build, script npm, test runner e sistemi di deploy, cercando output che mostri configurazioni, header, token, URL completi, connection string o payload. È importante verificare anche il masking dei secret, perché non tutti i token custom vengono mascherati automaticamente e alcune trasformazioni possono aggirare le protezioni. Ogni modifica a build, test e deploy dovrebbe essere revisionata come parte della sicurezza dei segreti, anche quando l’AI interviene solo per “aiutare il debug”.

Artifact, bundle frontend e source map

Un segreto può uscire anche dopo la build. Se una variabile privata viene usata in codice client-side può finire nel bundle JavaScript; se le source map sono pubbliche possono rivelare dettagli che il team pensava restassero interni; se un container image include file .env o credenziali in layer precedenti, rimuoverli in uno step successivo può non bastare.

Questo passaggio è particolarmente importante per app generate con v0, Lovable, Bolt.new, Replit Agent o altri strumenti che collegano rapidamente frontend, API e deploy. Nel frontend occorre distinguere con precisione variabili pubbliche e private: prefissi come NEXT_PUBLIC_ o equivalenti rendono una variabile disponibile al browser, quindi se l’AI sposta una chiave privata in una variabile pubblica per risolvere un errore, il deploy può esporla a chiunque apra DevTools.

Agenti con terminale, filesystem e MCP

Quando un agente può leggere file, eseguire comandi o usare tool esterni, il rischio cambia natura. Il problema non è che l’agente “voglia” rubare segreti, ma che il contesto operativo può includere file e output sensibili: un comando può leggere .env, un tool MCP può accedere a repository o ticket, una sessione remota può contenere credenziali di ambiente.

Prima di dare a un agente accesso operativo, è utile separare i segreti runtime dal workspace di sviluppo, usando ambienti dedicati, credenziali a scope minimo, file di esclusione, approvazione per comandi sensibili e account di servizio non riutilizzati in produzione. Per MCP e tool esterni, occorre mappare quali sistemi possono essere letti o modificati — repository, issue tracker, database, cloud, file storage, CI/CD, secret manager — perché se un tool può accedere a un segreto, quel segreto deve essere governato come parte del perimetro dell’agente.

Repository privato non significa segreto protetto

Un repository privato riduce l’esposizione, ma non è un secret manager. Le credenziali nel codice possono essere lette da collaboratori, fork interni, CI/CD, strumenti di analisi, app installate, backup, mirror, agenti e account compromessi. Se il repository diventa pubblico per errore o viene condiviso con un fornitore, i segreti nella history diventano immediatamente critici.

Il problema della history Git è particolarmente rilevante: anche se si rimuove la chiave dall’ultimo commit, può restare in commit precedenti, branch, tag, pull request, cache o fork. Riscrivere la history può ridurre la visibilità, ma non garantisce che nessuno abbia già letto il segreto, quindi la rotazione resta necessaria. Prima di aprire un repository a nuovi collaboratori, pubblicare un template, condividere una demo o collegare agenti esterni, è indispensabile eseguire una scansione su history, branch e tag, non solo sul working tree.

Secret scanning: necessario, non sufficiente

Secret scanning e push protection sono controlli fondamentali che bloccano molti errori prima che arrivino nel repository remoto e aiutano a rilevare chiavi note già presenti nella codebase. GitHub, provider cloud e diversi strumenti di sicurezza offrono controlli utili su pattern riconosciuti.

Il limite è che non ogni segreto ha una firma nota: token interni, stringhe custom, credenziali spezzate, secret composti, valori codificati, file proprietari o chiavi generate da sistemi aziendali possono sfuggire agli scanner standard. Anche un token vero ma scaduto può segnalare un problema di processo, perché se è arrivato lì una volta può succedere di nuovo. Per progetti AI-generated, la strategia più solida combina scanner automatici, pattern custom, review manuale e controlli sugli output: uno scanner pulito è un buon segnale, non una prova definitiva.

Rotazione: quando cancellare non basta

Se una chiave è stata esposta, la domanda non è “l’abbiamo rimossa?” ma “è ancora valida?”. Un segreto committato, stampato in un log, incollato in chat, incluso in un artifact o condiviso in un ticket deve essere considerato compromesso finché non viene ruotato o revocato.

La rotazione deve seguire una sequenza ordinata: identificare il servizio, capire privilegi e consumer, creare una nuova chiave, aggiornare ambienti e pipeline, verificare che l’app funzioni, revocare la vecchia chiave e controllare i log di accesso per uso anomalo. Nei sistemi critici occorre anche verificare se il segreto dava accesso a dati cliente, pagamenti, cloud o repository.

Per ridurre l’impatto futuro, è utile usare scope minimi e chiavi separate per ambiente: una chiave di sviluppo non dovrebbe poter leggere produzione, un token usato da una pipeline non dovrebbe avere privilegi amministrativi globali e un webhook secret non dovrebbe essere riutilizzato tra servizi diversi.

Cosa fare quando trovi un segreto esposto

Quando emerge una chiave in una PR generata dall’AI, in un log o in una chat, la prima domanda non è come pulire il file ma quale capacità concede quella credenziale: può leggere un database, modificare cloud e IAM, inviare pagamenti o email, fare deploy, accedere a repository o dati cliente?

Il passo successivo è delimitare l’esposizione cercando lo stesso valore in working tree, history Git, branch, tag, PR, log CI/CD, artifact, container image, source map, issue, ticket, prompt e chat. Se compare in più luoghi, la rotazione deve coprire tutti i consumer e la bonifica deve includere i sistemi che conservano copie.

La sequenza corretta è: creare una nuova chiave con scope minimo, aggiornare applicazione e pipeline, verificare che il servizio funzioni, revocare la vecchia chiave e controllare gli access log del provider. Se la credenziale riguardava produzione, dati cliente, pagamenti, repository o cloud, il finding dovrebbe bloccare il rilascio finché la rotazione non è completata.

Anche una chiave “di test” va verificata, perché molti ambienti di staging condividono dati, webhook, bucket o account di servizio più ampi del previsto. Prima di classificare l’incidente come minore, occorre controllare ambiente, privilegi, limiti di spesa, dati accessibili e integrazioni collegate.

Checklist di bonifica prima del deploy

Prima di pubblicare codice generato o modificato con AI, esegui almeno questi controlli:

• Scansiona repository, history Git, branch, tag e pull request.
• Cerca file .env, .pem, .key, .p12, file di credential, backup e configurazioni CLI.
• Controlla script di build, test, deploy e workflow CI/CD.
• Verifica log recenti, artifact, container image, bundle frontend e source map.
• Rivedi prompt, chat, ticket e issue usati per debug.
• Separa chiavi dev, staging e produzione.
• Sposta segreti in secret manager, vault o variabili protette della piattaforma.
• Abilita secret scanning e push protection dove disponibili.
• Aggiungi pattern custom per token interni o formati proprietari.
• Ruota ogni chiave esposta, sospetta o passata in un sistema non previsto.

Questa checklist va eseguita anche se la repo è privata e anche se l’app non è ancora pubblica, perché un segreto può essere sfruttato prima del go-live se concede accesso a cloud, database, pagamenti, email o repository.

Come ISGroup può verificare segreti e configurazioni

ISGroup può supportare una verifica mirata su codice generato o modificato con AI, concentrandosi su hardcoding, file sensibili, configurazioni, pipeline, log, artifact, dipendenze e modalità con cui gli agenti hanno interagito con il progetto. L’obiettivo è capire se esistono credenziali esposte, se vanno ruotate e quali controlli inserire prima del prossimo deploy.

Se nel progetto AI-generated trovi…	Rischio principale	Controllo consigliato
API key, token, file .env, connection string o file sensibili nel repository	Esposizione diretta di credenziali	Code Review
Servizi, host, pannelli o API raggiungibili tramite credenziali sospette	Superfici sfruttabili o configurazioni esposte	Vulnerability Assessment
Agent mode, CI/CD, build artifact, secret scanning e processi di merge non governati	Rischio ripetibile su release successive	Software Assurance Lifecycle
Cloud, bucket, database, IAM o service account legati a chiavi esposte	Privilegi eccessivi o misconfiguration cloud	Cloud Security Assessment
App o API già online con possibile chiave compromessa	Abuso reale dall’esterno	Web Application Penetration Testing

La scelta del controllo dipende da cosa consente di fare il segreto: leggere dati, modificare cloud, inviare pagamenti, accedere a repository, usare API esterne o pubblicare deploy. Eliminare i segreti dal codice prima del rilascio e ridurre il danno possibile in caso di nuova esposizione sono i due obiettivi concreti da raggiungere prima del go-live.

Evidenze da preparare per una review

Per una review efficace è utile preparare repository, branch interessati, PR generate da AI, elenco dei tool usati, workflow CI/CD, sistemi di deploy, ambienti, file ignore, secret manager, lista delle variabili critiche e alert di secret scanning già ricevuti.

È altrettanto importante raccogliere indizi fuori dal codice: chat in cui sono stati incollati errori, ticket di debug, log di build, artifact, container image, source map, screenshot, prompt condivisi, README e script temporanei. Se una chiave è stata ruotata, è utile conservare quando, da chi, dove era usata e quali access log sono stati controllati, perché queste informazioni permettono di distinguere tra segreto realmente esposto, falso positivo, chiave di test senza privilegi, credenziale di produzione da revocare subito e problema di processo da correggere nel ciclo di sviluppo.

Decisione prima della pubblicazione

Blocca il deploy se trovi chiavi di produzione nel repository, service role key nel frontend, database URL con privilegi reali, token cloud con scope ampio, segreti nei log pubblici, artifact scaricabili con credenziali o token incollati in chat senza rotazione.

Puoi pianificare dopo il rilascio solo miglioramenti con rischio residuo chiaro: rafforzare il naming delle variabili, aggiungere pattern custom agli scanner, completare la documentazione, ridurre lo scope di chiavi non critiche o migliorare l’onboarding del team. La rotazione di una chiave esposta non dovrebbe mai essere rimandata.

La decisione finale deve essere verificabile: quali segreti sono stati trovati, quali sono stati ruotati, quali scanner sono attivi, quali file sono esclusi, quali log sono stati controllati e quale processo impedisce che lo stesso errore torni nella release successiva.

Domande frequenti

• Se il repository è privato, devo comunque rimuovere le API key?
• Sì. Un repository privato non è un secret manager. Collaboratori, CI/CD, agenti, app installate, backup e account compromessi possono comunque accedere alle credenziali.
• Se ho cancellato la chiave dal codice, devo ruotarla?
• Sì, se la chiave è stata committata, stampata in log, inclusa in artifact o incollata in prompt. La cancellazione dal file non invalida il segreto.
• Il secret scanning basta per essere tranquilli?
• No. È un controllo necessario, ma può non riconoscere token custom, segreti parziali, formati interni o credenziali presenti fuori dal repository, come log e chat.
• Posso mettere chiavi nel frontend se il framework lo consente?
• Solo se sono chiavi progettate per essere pubbliche e limitate. Service key, database URL privati, token amministrativi, JWT secret e credenziali cloud non devono finire nel bundle.
• Cosa faccio se ho incollato una chiave in una chat AI?
• Trattala come esposta: ruotala, verifica gli access log del provider, controlla dove era usata e aggiorna il team su come condividere errori senza credenziali reali.
• Quali segreti sono più urgenti da ruotare?
• Chiavi cloud, token GitHub/GitLab, service role key, database URL di produzione, API key di pagamento, webhook secret, JWT secret, chiavi private e token con accesso a dati cliente.

Approfondimenti utili

• OWASP Secrets Management Cheat Sheet — linee guida pratiche per gestire segreti in modo sicuro lungo tutto il ciclo di sviluppo.
• OWASP Logging Cheat Sheet — indicazioni su cosa registrare nei log e cosa escludere per evitare esposizioni involontarie.
• GitHub secret scanning e push protection — documentazione ufficiale per configurare il rilevamento automatico di segreti nei repository.
• AWS Secrets Manager best practices — raccomandazioni AWS per la gestione centralizzata e sicura delle credenziali.
• Cursor ignore files — come configurare i file di esclusione per limitare il contesto accessibile all’agente AI.
• Claude Code settings — impostazioni di sicurezza e contesto per l’uso di Claude in ambienti di sviluppo.