Agenti dentro gli IDE: se hai usato v0, controlla i segreti

Google sta portando il suo agente Antigravity dentro VS Code, Visual Studio, JetBrains e Zed. L’agente può leggere piani, proporre diff e gestire attività multi-step direttamente nell’editor. La stessa sessione eredita identità, progetto, policy e accesso ai servizi collegati. La notizia originale è qui.

Per chi ha costruito con v0, il punto non è stabilire se gli agenti siano buoni o cattivi. Il punto è molto più concreto: quando il prototipo diventa prodotto, sai davvero quali segreti possono finire nel browser, nel bundle JavaScript o nel repository?

L’agente entra nell’IDE, ma il segreto può uscire dal backend

La notizia su Antigravity mostra un passaggio importante: l’agente non vive più in un ambiente separato. Entra nel flusso quotidiano dello sviluppatore, con accesso al progetto e alle integrazioni che quel progetto usa.

Questa comodità aumenta il valore dell’automazione, ma rende più importante il confine tra codice client e codice server. Se una chiave API, un token o una credenziale viene trattata come una normale variabile dell’applicazione, può finire nel posto sbagliato senza che l’interfaccia lo renda evidente.

Il buco tecnico di oggi è l’esposizione di segreti nel client o nel repository.

Un esempio tipico: v0 genera una pagina che chiama un servizio esterno. Per far funzionare rapidamente il prototipo, la chiave viene inserita in una variabile NEXT_PUBLIC_*, in un file .env committato o direttamente in un componente. La UI funziona. La chiamata restituisce il risultato. Il deploy passa.

Ma tutto ciò che viene incluso nel bundle client può essere visto dall’utente. Un segreto consegnato al browser non è più un segreto. E un token finito nella storia Git può restare recuperabile anche dopo essere stato rimosso dal file corrente.

Cosa significa se il tuo codice l’ha scritto v0

Non significa che v0 sia inadatto alla produzione. Significa che la velocità con cui passa da idea a interfaccia può nascondere una decisione architetturale: quali operazioni devono vivere sul server e quali possono essere esposte al client.

Nel repo cerca questi percorsi:

• variabili d’ambiente con prefissi pubblici o accessibili dal browser;
• chiavi presenti in componenti React, file JSON, script di test o configurazioni di deploy;
• chiamate dirette dal client verso provider che richiedono autenticazione privata;
• route server-side che inoltrano richieste senza proteggere il token;
• file .env, log, fixture e snapshot inclusi nella cronologia Git;
• webhook o endpoint interni che accettano una credenziale statica senza rotazione;
• configurazioni diverse tra sviluppo, staging e produzione.

Il caso più frequente non è una chiave scritta in modo plateale. È una chiave spostata in un punto che il framework considera pubblico. Oppure un token corretto per un ambiente di sviluppo riutilizzato in produzione. Oppure ancora una credenziale inserita in un esempio perché “tanto il repository è privato”.

Quando un agente lavora dentro l’IDE, può attraversare rapidamente questi file, copiarne il contenuto in una configurazione o proporre una modifica che amplia il perimetro. Il problema non è che l’agente abbia letto una stringa: è che il repo non distingua con chiarezza ciò che può essere letto dal client da ciò che deve restare confinato al server.

Perché ora ti serve un audit sul repo

Qui sta il passaggio tra “il prototipo funziona” e “posso affidargli credenziali reali”. Un audit VibeInspect serve a ricostruire dove nasce il segreto, dove viene trasferito e quale percorso può renderlo visibile.

Per un possibile secret exposure, l’analisi deve collegare più livelli:

1. il componente o la route che avvia la richiesta;
2. il bundler e le convenzioni sulle variabili d’ambiente;
3. il codice server-side che dovrebbe custodire la credenziale;
4. le configurazioni di deploy e CI;
5. la cronologia e i file di esempio del repository;
6. i log e le risposte che possono riflettere token o header;
7. le chiamate a provider esterni e i meccanismi di rotazione.

Il valore non è ricevere un avviso generico come “controlla le API key”. Ti serve un verdetto: c’è un segreto esposto, dove passa, quali file lo dimostrano e quanto è urgente intervenire.

Con VibeInspect carichi lo ZIP del repo e ottieni un PDF con un verdetto. Nel piano Diagnostic, il report indica file, riga ed evidenze del problema. Non modifica il codice e non è un pentest: è un’analisi del repository per togliere ambiguità prima del prossimo deploy.

Se invece vuoi soltanto una prima fotografia del rischio, Snapshot restituisce uno score senza file o riga. Ma quando il sospetto è tecnico — per esempio una chiave nel bundle client o una credenziale committata — Diagnostic è il piano coerente.

Cosa un linter non vede

Un linter può segnalare una stringa sospetta, un pattern insicuro o un file non ignorato da Git. Sono controlli utili, ma non bastano a emettere un verdetto sul percorso reale del segreto.

Per capire se una chiave è davvero esposta devi sapere:

• se il file viene incluso nel build client;
• se il prefisso della variabile la rende pubblica;
• se il server usa una credenziale privata o una copia accessibile al browser;
• se la route autorizza correttamente chi può invocare l’operazione;
• se il token è presente nella cronologia Git;
• se il deploy usa valori diversi da quelli locali;
• se esistono log, errori o response body che lo restituiscono.

Una riga può sembrare corretta isolatamente. Una variabile chiamata API_KEY può essere sicura in un modulo server e pubblica in un componente client. Un .env può essere escluso dal prossimo commit ma restare nella storia del repository. Un test può passare perché usa una chiave fittizia, mentre la configurazione di produzione concede accesso illimitato.

Il linter vede il pattern. L’audit ricostruisce il comportamento.

Cosa fare questa settimana

Scegli una sola integrazione esterna del prodotto creato con v0: pagamenti, email, storage, AI o analytics. Poi segui la credenziale dall’origine alla richiesta finale.

Fai questi controlli:

• cerca chiavi e token nella cronologia Git, non solo nei file attuali;
• verifica che le credenziali private siano usate esclusivamente lato server;
• controlla tutti i prefissi di variabili esposte al client;
• sposta le chiamate privilegiate dietro una route server-side autenticata;
• limita gli scope del token al solo servizio necessario;
• revoca e rigenera ogni chiave che sia stata committata o inviata al browser;
• controlla log, errori e risposte per evitare riflessi di segreti;
• separa credenziali di sviluppo, staging e produzione;
• aggiungi un controllo CI che blocchi nuovi segreti nel repository;
• ottieni un verdetto sul repo prima di collegare altre integrazioni.

Se hai spedito con v0 e vuoi sapere se una credenziale può uscire dal server, carica il repo su VibeInspect. Per un rischio tecnico come un segreto esposto, scegli Diagnostic: ti servono file, righe ed evidenze per revocare la chiave giusta e correggere il percorso prima del prossimo go-live.