Un modello AI anonimo conserva tutto: cosa rischia il tuo repository

Un modello AI “gratis” conserva ogni prompt che gli invii

Questo mese la comunità degli sviluppatori si è fissata su un modello arrivato dal nulla: contesto da oltre un milione di token, output enorme e una quantità di token gratuiti giornalieri che nessuno regalerebbe per beneficenza. Molti hanno letto le specifiche e i benchmark. Quasi nessuno ha letto le quattro righe della policy sui dati.

Come nota l'analisi di Srivatsa Kamballa in “Ox Alpha Is Free, Fast, and Run by Nobody”, il punto critico è questo: i prompt e le risposte vengono conservati dal provider, e il provider ha scelto di restare anonimo durante la preview. Non addestrato, dicono. Solo conservato. Da un soggetto senza nome, in un paese che non puoi indicare, sotto leggi che non puoi leggere.

“Gratis”, in questi casi, è sempre la trappola. Quando il prezzo non ha senso, non sei il cliente: sei il corpus. E il corpus include tutto quello che un ingegnere incolla in una casella di testo, comprese architetture interne, codice sorgente e la chiave API che qualcuno ha lasciato dentro uno stack trace.

Cosa significa se il tuo codice l’ha scritto Cursor

Col vibe coding è normale spostare interi blocchi di codice avanti e indietro tra l'editor e un modello. Chiedi a Cursor di generare un client, di sistemare un bug, di spiegarti perché una chiamata fallisce. E nel farlo, incolli file completi.

Il problema non è aver usato l'AI. Il problema è cosa finisce dentro quei file. Un .env letto per errore, una connection string dentro un commento, un token di servizio hardcoded per “far funzionare tutto in fretta”, la chiave del webhook di pagamento incollata nel messaggio insieme allo stack trace. Sono tutti segreti esposti, e se li invii a un modello che conserva ogni token, non li recuperi più.

La parte scomoda è che tu non sai davvero quali segreti sono finiti nel tuo repository. Cursor genera in fretta, tu accetti in fretta, e credenziali che dovrebbero stare in un vault restano nel codice versionato. Il modello anonimo è solo l'ultimo modo in cui quel segreto può uscire di casa. Ci sono i log, le pull request pubbliche, le history di Git, i deploy. Il vero rischio è sistemico: hai un repository e non sai in che stato è.

Perché ora ti serve un audit

Un audit serve a rispondere a una domanda che la maggior parte dei founder evita: “cosa c’è davvero dentro il mio codice, adesso?”

Quando sviluppi a colpi di prompt, il codice cresce senza che tu abbia una mappa mentale completa di ciò che è stato scritto. Le credenziali si depositano dove capita. Un endpoint di debug rimane aperto. Una chiave che doveva essere temporanea diventa permanente. Nessuno di questi problemi grida: restano silenziosi finché non causano un incidente.

Un audit on-demand come VibeInspect nasce esattamente per questo scenario. Carichi lo ZIP del repository, degli specialisti AI lo analizzano e ricevi un PDF con un verdetto. Nessun server: il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non corregge il codice e non promette sicurezza assoluta. Ti dice in che stato è il tuo repository, così smetti di procedere alla cieca.

La differenza pratica è tra “spero di non aver lasciato segreti in giro” e “ho un verdetto scritto”. Nel momento in cui un modello anonimo può trattenere per sempre ciò che gli invii, sapere quali segreti vivono nel tuo codice non è più un dettaglio: è la base per decidere cosa ruotare, cosa revocare e cosa spostare in un vault.

Quali evidenze contano davvero

Un buon verdetto non si ferma allo score. Ti indica dove guardare. Nel caso dei segreti esposti, le evidenze che contano sono concrete: quali file contengono credenziali in chiaro, quali variabili sensibili sono finite nel codice versionato invece che nella configurazione, quali chiavi compaiono in punti che non dovrebbero mai vederle, come i log o i commenti.

Con il piano Diagnostic ottieni file, riga ed evidenze: sai esattamente dove intervenire, senza dover leggere manualmente ogni cartella generata dall'AI. Con il piano Snapshot ottieni score e verdetto generale, utile quando la domanda è semplicemente “in che stato è questo repository?” senza ancora scendere al dettaglio di file e riga.

Questo conta perché un segreto esposto non è astratto: è una riga precisa, in un file preciso, che puoi ruotare oggi stesso.

Cosa un linter non vede

Un linter è utile, ma vive in un altro mondo. Controlla lo stile, le variabili inutilizzate, le convenzioni di formattazione, gli errori di sintassi. Fa passare il tuo codice se è ordinato.

Un linter non capisce che una stringa è in realtà una chiave di produzione. Non sa distinguere un placeholder da una credenziale vera. Non ti avvisa che quel token, sintatticamente perfetto e ben formattato, non dovrebbe stare lì. Per il linter una chiave hardcoded pulita e indentata correttamente è un successo, non un allarme.

Ecco come falliscono davvero le cose in questo tipo di sicurezza: non con un exploit spettacolare e un CVE, ma con un valore che nessuno ha mai messo in discussione perché gli strumenti automatici lo consideravano “valido”. Il codice compila, i test passano, il linter è verde. E intanto un segreto viaggia verso un provider di cui non conosci il nome.

Cosa fare questa settimana

Prenditi mezz'ora e agisci su tre fronti concreti.

Primo: verifica cosa hai incollato di recente in modelli o assistenti AI. Se hai passato file interi, parti dal presupposto che quei contenuti possano essere stati conservati e tratta come compromesse le credenziali coinvolte.

Secondo: ruota subito le chiavi che sospetti siano finite nel codice o nei prompt. Rigenera i token, revoca quelli vecchi, sposta le variabili sensibili fuori dal codice versionato.

Terzo: ottieni un verdetto sul tuo repository invece di procedere a intuito. Carica lo ZIP su VibeInspect e lascia che l'analisi ti dica file e riga dove i segreti sono esposti. Il codice viene cancellato al termine.

Hai usato l'AI per andare veloce. Adesso usa un audit per sapere davvero cosa hai spedito nel mondo.