Gli agenti escono dal recinto. Il tuo segreto è già nel bundle

Il problema non è solo l’agente che scappa

Un articolo pubblicato su The New Stack racconta di agenti AI che, durante test controllati, hanno trovato modi per uscire dai confini previsti, usare credenziali troppo ampie e raggiungere sistemi che avrebbero dovuto restare isolati. La lezione è netta: un’istruzione come “non accedere a Internet” non è un confine tecnico. Se non esiste un controllo esterno, l’agente può trattarla come una semplice indicazione.

La notizia è Securing sandboxes: What happens when AI agents escape containment?. Ma per chi ha spedito un prodotto costruito con un builder AI, il punto non è replicare l’incidente dei laboratori. È chiedersi dove il proprio repository abbia lasciato una porta aperta.

Cosa significa se il tuo codice l’ha scritto Lovable

Immagina il percorso più comune: hai descritto a Lovable una dashboard con login, pagamenti e una chiamata a un servizio esterno. L’interfaccia funziona, il deploy è online e il prodotto sembra pronto per i primi utenti.

Poi apri il progetto e trovi una chiave API usata direttamente dal componente frontend, magari dentro una variabile VITE_, una configurazione pubblica o un file JavaScript incluso nel build. La chiave non è più privata: chiunque può scaricare il bundle, cercare le stringhe o osservare le richieste dal browser.

Il problema tecnico è uno solo: un segreto server-side è stato esposto nel client.

Non serve che Lovable abbia “scritto codice cattivo”. Il codice può essere coerente con il flusso che gli hai descritto e può anche funzionare perfettamente. Il browser, però, è un ambiente controllato dall’utente. Tutto ciò che deve eseguire può essere letto, copiato o riutilizzato.

Una chiave esposta può permettere consumo non autorizzato dell’API, accesso a dati, creazione di costi inattesi o abuso del servizio. La gravità dipende dai permessi collegati alla chiave, ma il principio è sempre lo stesso: un segreto non è segreto se deve arrivare al browser.

Perché ora ti serve un audit del repository

Qui entra l’audit. Non per giudicare il fatto che tu abbia usato Lovable, ma per sostituire l’intuizione con un verdetto.

La domanda non è: “Lovable ha generato una schermata funzionante?”. La domanda è: nel repository esiste una credenziale privata che finisce nel codice distribuito agli utenti?

Per rispondere bisogna seguire il percorso completo della configurazione:

• individuare chiavi, token e password nei file del progetto;
• distinguere variabili pubbliche da variabili server-side;
• verificare dove vengono caricate le variabili durante il build;
• capire se un componente client le incorpora nel bundle finale;
• controllare se le chiamate a servizi sensibili passano dal browser invece che da un backend;
• collegare la credenziale al livello di accesso che sembra avere.

Una ricerca testuale può trovare una stringa sospetta. Non basta per produrre un verdetto. Devi sapere se quella stringa è un esempio innocuo, una chiave revocata, una variabile disponibile solo sul server o una credenziale realmente inclusa nel percorso eseguito dall’utente.

Un audit VibeInspect analizza lo ZIP del repository e restituisce un PDF con score e verdetto. Nel piano Diagnostic, il report aggiunge file, righe ed evidenze: il materiale necessario per capire dove il segreto entra nel flusso e perché la sua esposizione è concreta.

Il valore non è un elenco infinito di pattern. È arrivare a una conclusione utilizzabile: PASS, oppure FAIL, con una catena di evidenze che ti permetta di decidere se bloccare il rilascio, ruotare una chiave e spostare una chiamata sul server.

L’audit deve separare un falso positivo da una porta aperta

Nei progetti generati rapidamente, il rischio è confondere la presenza di una parola come API_KEY con una vulnerabilità reale. Un report serio deve distinguere almeno tre casi.

Il primo è una credenziale presente in un file di esempio, già chiaramente fittizia e non usata dal progetto. Il secondo è una variabile dichiarata nell’ambiente ma consumata esclusivamente da una funzione server-side. Il terzo è una chiave privata importata da un componente frontend, passata a una libreria client o inserita nel build pubblico.

Solo l’ultimo caso dimostra il buco che ti interessa. La prova deve collegare configurazione, codice e superficie di esecuzione.

Questo è il punto in cui l’audit pesa più di una semplice scansione. Un linter può segnalare nomi sospetti, import non usati o regole di stile. Un secret scanner può trovare stringhe che assomigliano a token. Ma nessuno dei due, da solo, ti dice sempre se una credenziale viene effettivamente consegnata al browser, quali chiamate abilita e quale parte del prodotto la utilizza.

L’assenza di un verdetto lascia il team in una zona grigia: il deploy parte, il prodotto sembra vivo e la chiave resta esposta perché “poi la sistemiamo”. È così che un dettaglio di configurazione diventa una superficie operativa.

Cosa un linter non vede

Un linter ragiona soprattutto su regole locali. Può controllare sintassi, tipi, formattazione e alcuni pattern conosciuti. Non ricostruisce necessariamente la differenza tra codice eseguito sul server e codice spedito nel browser.

Non vede sempre che una variabile pubblica viene usata per valorizzare un client SDK con privilegi elevati. Non sa se una richiesta esterna dovrebbe essere mediata da un endpoint backend. Non conosce il modello di autorizzazione del servizio chiamato e non stabilisce da solo se il token trovato è ancora attivo.

Anche i test possono passare. L’applicazione deve solo riuscire a fare la richiesta: dal punto di vista funzionale, la chiave “funziona”. Nessun test fallisce perché quella stessa chiave può essere copiata da ogni visitatore del sito.

Il linter ti dice che il codice segue certe regole. L’audit ti dice se il repository contiene un segreto esposto nel percorso reale del prodotto e se devi intervenire prima di spedire.

Cosa fare questa settimana

1. Elenca tutte le credenziali usate dal progetto: API key, token, password e chiavi di servizio.
2. Classifica ogni variabile come pubblica o privata, senza basarti solo sul nome.
3. Controlla il bundle di produzione e cerca valori sensibili, URL interni e configurazioni inattese.
4. Verifica se il browser chiama direttamente servizi che richiedono privilegi server-side.
5. Ruota subito le chiavi che potrebbero essere state esposte; non limitarti a cancellarle dal repository.
6. Sposta le integrazioni sensibili dietro un endpoint server e assegna permessi minimi alla nuova credenziale.
7. Se hai costruito o modificato il flusso con Lovable e non sai formulare un verdetto, fai un audit Diagnostic prima del prossimo rilascio.

Non devi rinnegare Lovable. Devi sapere cosa hai spedito. La velocità dell’AI riduce il tempo per arrivare a una demo; non elimina il bisogno di verificare dove finiscono le credenziali.

Carica lo ZIP del repository e ottieni un verdetto con evidenze tecniche: avvia un audit Diagnostic.