Google porta gli agenti nell’IDE: il rischio segreti nel tuo repo v0

L’agente entra nell’IDE: il confine di sicurezza si sposta

Google sta portando il proprio agente di coding Antigravity dentro Visual Studio Code, Visual Studio, gli IDE JetBrains e Zed. L’obiettivo è permettere agli sviluppatori di chattare con l’agente, delegare attività multi-step e rivedere i diff senza spostare il progetto in un’app separata. La notizia è raccontata in “Google’s AI coding agent just escaped its own IDE”, pubblicato il 20 agosto 2026.

Il dettaglio che conta per un founder non è soltanto la comodità. Quando un agente entra nel flusso quotidiano, eredita credenziali, workspace, progetti cloud e integrazioni. L’articolo cita policy IAM, confini regionali, accesso a MCP e la possibilità di raggiungere sistemi di produzione: una configurazione sbagliata può trasformare un normale progetto in un punto di accesso privilegiato.

La stessa domanda vale per il tuo prodotto: non “l’agente ha scritto codice funzionante?”, ma “quali segreti può vedere il codice che ho spedito?”.

Cosa significa se il tuo codice l’ha scritto v0

Immagina di aver usato v0 per costruire una dashboard con autenticazione, pagamenti e una chiamata a un servizio esterno. Il prototipo funziona. L’interfaccia è pulita. La demo passa.

Poi aggiungi una funzione che genera report, invia notifiche o interroga un provider AI. Per farlo, inserisci una chiave API in una variabile d’ambiente e chiedi a v0 di collegarla al componente React. Il rischio nasce se quella variabile viene esposta nel bundle client, passata a una route pubblica o stampata nei log durante il debug.

Il buco tecnico è l’esposizione di segreti nel client: una chiave, un token o una credenziale che dovrebbe restare sul server diventa leggibile dal browser, dagli strumenti di sviluppo, dal bundle JavaScript o da una risposta API.

Non serve che qualcuno “rompa” il sistema. Basta aprire la pagina, ispezionare le richieste o scaricare gli asset pubblici. Se la chiave consente di consumare API a pagamento, leggere dati, modificare risorse o accedere a un ambiente cloud, il problema supera il confine della singola pagina.

v0 non è il nemico. Ti permette di arrivare rapidamente a un’interfaccia e a un primo flusso applicativo. Ma quando il progetto passa da demo a prodotto, la differenza tra codice server-side e codice eseguito nel browser deve essere verificata, non data per scontata.

Perché ora ti serve un audit: il verdetto prima della prossima integrazione

Un audit VibeInspect serve a trasformare il dubbio in un verdetto tecnico sul repository. Nel caso dei segreti esposti, l’analisi deve ricostruire il percorso completo della credenziale:

1. dove viene definita;
2. come viene caricata dall’applicazione;
3. quali moduli possono importarla;
4. se finisce nel codice eseguito dal browser;
5. quali route API la ricevono o la restituiscono;
6. se viene scritta nei log, nei messaggi di errore o nelle risposte JSON;
7. quali permessi ha sul provider esterno;
8. se esistono ambienti diversi per sviluppo, staging e produzione;
9. se una chiave compromessa può essere revocata e sostituita senza fermare il servizio.

Questa ricostruzione è importante perché un segreto non è esposto soltanto quando compare in chiaro in un file chiamato config. Può diventare accessibile anche attraverso una variabile pubblica, una configurazione di build, un endpoint proxy troppo permissivo o una funzione server chiamata direttamente dal client.

Un audit utile deve separare i casi. Una chiave pubblica pensata per un SDK browser non equivale a un token amministrativo. Un identificatore senza privilegi non ha lo stesso impatto di una credenziale che consente rimborsi, accesso al database o gestione dell’infrastruttura. Il verdetto deve quindi considerare sia la presenza del segreto sia il potere che quel segreto concede.

Per un buco tecnico di questo tipo, il piano coerente è il Diagnostic da €499: restituisce file, righe ed evidenze. Lo Snapshot da €49 può dirti se il repo merita attenzione, ma non localizza il percorso della credenziale. L’audit produce un PDF con il verdetto: non modifica il codice e non è una revisione umana.

Cosa un linter non vede

Un linter può segnalare una variabile non usata, un import sospetto o una regola di stile violata. Non può stabilire se NEXT_PUBLIC_API_KEY sia una chiave innocua o un token con accesso a dati sensibili.

Non conosce automaticamente il confine tra browser e server. Per lui una stringa è una stringa, una variabile è una variabile e una chiamata HTTP è una chiamata HTTP. Il rischio dipende dal contesto operativo:

• il codice viene incluso nel bundle pubblico oppure gira solo sul server;
• la route valida l’utente o inoltra qualsiasi richiesta;
• il provider limita la chiave per dominio, ambiente o permessi;
• i log conservano header, query string o payload completi;
• gli errori mostrano configurazioni interne;
• la pipeline di deploy copia segreti nel posto sbagliato.

Anche uno scanner di pattern può fallire in entrambe le direzioni. Può segnalare una chiave di test non sensibile e ignorare un token passato dinamicamente tramite configurazione. Il problema non è soltanto trovare una stringa che “sembra” un segreto: è capire se quella credenziale è raggiungibile da un attore non autorizzato e cosa può fare una volta ottenuta.

La differenza è tra controllo locale e comportamento reale del sistema. Un audit collega frontend, API, configurazione, build e provider esterni. È lì che emerge il verdetto che manca: la chiave è davvero confinata al server, oppure il browser può leggerla?

Cosa fare questa settimana

Prima di collegare un altro provider AI, sistema di pagamento o servizio cloud al tuo progetto v0, fai queste verifiche:

1. Cerca le variabili pubbliche. Controlla prefissi e configurazioni che includono valori nel bundle client.
2. Mappa le chiamate esterne. Per ogni API indica se la richiesta parte dal browser o dal server.
3. Controlla il contenuto del bundle. Cerca token, URL interni, header di autorizzazione e messaggi di debug.
4. Riduci i permessi. Una chiave usata per una sola operazione non dovrebbe amministrare l’intero account.
5. Verifica i log. Assicurati che errori e richieste non registrino credenziali o payload sensibili.
6. Prova la revoca. Simula la sostituzione di una chiave e verifica che il deploy possa aggiornare il secret senza interventi improvvisati.
7. Fai un controllo pre-go-live. Se non sai dire quali credenziali sono pubbliche, il repo non ha ancora un verdetto.

Se hai spedito con v0 e vuoi capire se il tuo repository espone chiavi API, token o configurazioni sensibili, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con verdetto in PDF e il sorgente verrà cancellato a fine analisi.

Scegli il Diagnostic se vuoi evidenze file/riga sul percorso del segreto. Il problema non è aver usato l’AI per costruire il prodotto: è lasciare che una configurazione non verificata decida chi può usare le tue credenziali.