Stack AI in locale: comodo, ma i file di config finiscono nel repo

Spostare l'AI in locale non basta: la configurazione resta nel repository

Una guida tecnica pubblicata su dev.to descrive come costruire un ambiente di sviluppo AI completamente offline, unendo LM Studio, Ollama e un layer di orchestrazione per avere completamento di codice e refactoring senza inviare nulla al cloud. L'idea di fondo è chiara: come scrive l'autore, "your code never leaves your machine" (Building a Complete Offline AI Development Stack).

È un obiettivo sensato. Chi lavora in ambiti regolamentati o su progetti sensibili vuole tenere il sorgente lontano da server esterni. Ma nella stessa guida compare un dettaglio che vale la pena guardare da vicino: un file config.json con baseUrl, nome del modello e parametri del provider. Un file di configurazione come questo, insieme a .env, chiavi API e URL di servizi interni, quasi sempre finisce dentro il repository. E lì rimane, anche quando il modello gira comodamente sulla tua macchina.

Il punto non è l'AI in locale. Il punto è che la promessa "il codice non lascia il tuo computer" riguarda l'inferenza, non il tuo Git. Un endpoint interno, un token dimenticato in un file tracciato o una credenziale in chiaro possono viaggiare esattamente dove non vuoi: nella cronologia dei commit, in un fork, in un branch pubblico.

Cosa significa se il tuo codice l'ha scritto Cursor

Se hai messo insieme il tuo progetto con Cursor, probabilmente hai lasciato che l'assistente generasse anche i file di setup: configurazioni del provider AI, connessioni a servizi, variabili d'ambiente di esempio. Cursor è bravo a produrre codice che funziona subito, e proprio questa fluidità è il rischio. Un file config scritto "al volo" tende a contenere valori reali invece di segnaposto, e un .env di esempio spesso viene copiato con dentro credenziali vere.

Il problema tecnico ricorrente qui sono i segreti esposti: chiavi API, URL di database, token di servizio finiti in file versionati. Non serve un attaccante sofisticato. Basta che il repository sia pubblico, o che un collaboratore con accesso ampio esporti la cronologia, perché quei valori diventino utilizzabili. E rimuovere un segreto da un commit non lo cancella dalla storia di Git: resta recuperabile finché non riscrivi la cronologia e ruoti la chiave.

Con un flusso di lavoro AI, questo accade più spesso di quanto pensi, perché tu leggi il risultato come "codice pronto" e non come "bozza da ripulire". La macchina ti ha dato qualcosa che gira. Chi ti dice se è anche qualcosa che puoi pubblicare senza esporti?

Perché ora ti serve un audit

Quando spedisci un progetto costruito con l'AI, non hai un momento formale in cui qualcuno guarda il codice e dice "questo è pronto, questo no". Nel lavoro di team tradizionale c'è la revisione tra colleghi; nel vibe coding spesso c'è solo il fatto che l'app parte. Sono due cose diverse: "funziona" non equivale a "è sicuro".

Un audit serve a produrre un verdetto. Non a riscriverti il codice, ma a dirti in che stato è davvero: dove ci sono segreti in chiaro, quali file di configurazione contengono valori sensibili, quali endpoint interni sono finiti nel repository. È la differenza tra sperare che sia tutto a posto e sapere se lo è.

VibeInspect funziona così: carichi lo ZIP del repository, degli specialisti AI lo analizzano e ricevi un PDF con il verdetto. Nessun server da configurare, e il sorgente viene cancellato al termine dell'analisi. Non è un pentest e non ti garantisce sicurezza assoluta: è un modo rapido per avere un giudizio strutturato prima di andare in produzione. Con il piano Diagnostic ottieni file, riga ed evidenze dei punti critici, così sai esattamente dove intervenire — per esempio quale file di configurazione contiene la chiave che credevi ancora al sicuro.

Cosa un linter non vede

È facile pensare: "ho il linter attivo, quindi sono coperto". Un linter controlla stile, formattazione, variabili non usate, qualche pattern rischioso di sintassi. È utile, ma lavora sulla forma del codice, non sul suo significato in termini di rischio.

Un linter non ti dice che quel baseUrl punta a un servizio interno che non dovrebbe essere versionato. Non capisce che la stringa in config.json è una credenziale valida e non un placeholder. Non ricostruisce che una chiave, rimossa dal file corrente, è ancora presente in un commit precedente. Non valuta se un endpoint esposto in configurazione può essere raggiunto senza autorizzazione.

Sono proprio queste le domande che contano quando pubblichi un progetto nato da un assistente AI. La sintassi è pulita — l'AI la scrive bene. Ciò che manca è il giudizio sul contesto: cosa è sensibile, cosa non dovrebbe stare in un file tracciato, cosa succede se qualcuno legge la cronologia. Un audit guarda queste evidenze, un linter le attraversa senza vederle.

Cosa fare questa settimana

Non serve una revisione infinita. Serve un passaggio mirato:

1. Cerca i segreti nei file tracciati. Apri config, .env e ogni file di setup generato dall'assistente. Se trovi chiavi, token o URL interni reali, sostituiscili con segnaposto e sposta i valori in variabili d'ambiente fuori dal repository.
2. Controlla la cronologia, non solo lo stato attuale. Un segreto rimosso oggi può essere ancora nei commit di ieri. Se ne trovi uno, ruota subito la chiave: rimuoverla dal file non la rende inutilizzabile.
3. Verifica cosa è versionato davvero. Assicurati che .gitignore escluda i file di configurazione sensibili prima del prossimo push.
4. Ottieni un verdetto sul repository. Carica lo ZIP su VibeInspect e lascia che l'analisi individui file, riga ed evidenze dei segreti esposti e delle configurazioni a rischio.

Hai fatto la cosa giusta a usare l'AI per andare veloce. Il passo che manca è sapere, con precisione, cosa hai spedito. Con il piano Diagnostic parti dalle evidenze concrete invece che dai sospetti.