Lovable e MCP: il repo può fare più di quanto immagini

Google sta portando il suo agente Antigravity dentro VS Code, Visual Studio, JetBrains e Zed: conversazioni, diff, piani e task multi-step entrano direttamente nell’IDE. È un segnale chiaro: l’agente non è più un pannello separato, ma una parte stabile del flusso di sviluppo. La notizia originale è qui.

La stessa direzione vale per chi ha costruito con Lovable. Puoi partire da un prompt, collegare servizi esterni, aggiungere autenticazione, database e automazioni, poi arrivare rapidamente a un prodotto che sembra pronto. Il passaggio delicato arriva quando il repo concede a un’integrazione più potere di quanto serva davvero.

L’agente entra nell’IDE, il perimetro deve entrare nel repo

La notizia su Antigravity mette in evidenza due elementi: l’agente lavora dentro strumenti già usati dagli sviluppatori e le sue sessioni ereditano identità, progetto, policy e accesso ai servizi collegati. Questo rende l’esperienza più fluida, ma aumenta il peso delle configurazioni.

Se il tuo prodotto è nato in Lovable e usa un server MCP, una funzione serverless o un’integrazione con il provider cloud, la domanda non è solo “l’agente riesce a chiamare il tool?”. Devi chiederti: “quali dati e quali azioni diventano disponibili quando quel tool viene chiamato?”.

Il buco tecnico concreto di oggi è l’eccesso di privilegi nelle integrazioni MCP.

Un esempio: hai collegato al prodotto un tool per leggere gli ordini e aggiornare lo stato di una spedizione. Per velocizzare il primo prototipo, il token usato dal server può avere accesso a tutte le tabelle, a più ambienti o a operazioni distruttive. L’interfaccia espone solo “aggiorna spedizione”, ma il backend possiede permessi molto più ampi.

Il risultato è un confine fragile: se una richiesta male interpretata, un prompt injection o un endpoint interno riutilizza quel token, l’agente può leggere dati non necessari oppure eseguire azioni fuori dal caso d’uso originale.

Cosa significa se il tuo codice l’ha scritto Lovable

Non significa che Lovable sia il problema. Significa che la velocità del builder può farti saltare una decisione che normalmente avresti preso con più calma: la separazione tra ciò che l’integrazione deve fare e ciò che tecnicamente può fare.

Nel repo cerca soprattutto questi percorsi:

• chi crea il client MCP o il collegamento al servizio esterno;
• dove vengono caricati token, chiavi e variabili d’ambiente;
• quali tool sono registrati e con quali parametri;
• quali ruoli possono invocare ogni tool;
• quali controlli vengono eseguiti prima di una scrittura o cancellazione;
• se il backend verifica nuovamente l’utente e l’organizzazione;
• se esistono endpoint alternativi che usano lo stesso token con più privilegi.

Un pattern frequente nei progetti generati rapidamente è questo: l’autenticazione dell’utente funziona, il tool risponde, il caso felice passa. Ma il server non applica un vero principio di least privilege. Il token può leggere tutto il workspace invece di una singola organizzazione; può aggiornare ordini senza verificare che l’utente abbia quel ruolo; può chiamare un’azione irreversibile senza una conferma strutturata.

Il rischio non è teorico solo perché il tool è “interno”. Un’integrazione interna è comunque una superficie di esecuzione: riceve input, consulta dati e può produrre effetti.

Perché ora ti serve un audit sul repo

Qui sta il passaggio che manca tra “l’app funziona” e “posso affidarle dati e azioni reali”. Un audit VibeInspect serve a emettere un verdetto sul comportamento del repository, non a giudicare chi ha usato Lovable.

Nel caso di un’integrazione MCP troppo privilegiata, l’analisi deve ricostruire il percorso completo:

1. quale identità arriva dalla sessione;
2. quale token viene usato dal server;
3. quali scope o ruoli sono associati a quel token;
4. quali tool sono esposti al modello o all’utente;
5. quali controlli impediscono di passare da una lettura a una modifica;
6. se l’organizzazione o il proprietario della risorsa vengono verificati anche lato server;
7. quali operazioni possono essere eseguite senza approvazione esplicita;
8. quali dati finiscono nei log, nelle risposte o nel contesto dell’agente.

Il risultato che ti serve non è “sembra sicuro”. È sapere se esiste un confine mancante, dove si trova e con quali evidenze lo puoi correggere.

Con VibeInspect carichi lo ZIP del repo e ricevi un PDF con un verdetto. Il piano Diagnostic è quello coerente quando hai un rischio tecnico preciso: indica file, riga ed evidenze. Non modifica il codice, non è un pentest e non sostituisce una revisione umana fuori dal piano Assurance. Fa una cosa più semplice e concreta: toglie ambiguità dal prossimo intervento.

Cosa un linter non vede

Un linter può trovare import inutilizzati, tipi errati, pattern sospetti o configurazioni formalmente non valide. Può persino segnalare una chiave hardcoded, se il pattern è riconoscibile.

Non può però stabilire da solo se il permesso concesso a un tool è proporzionato all’azione richiesta.

Per capirlo devi collegare più livelli:

• configurazione dell’integrazione;
• middleware di autenticazione;
• ruoli e policy;
• query al database;
• schema dei tool;
• gestione degli errori;
• flussi di conferma;
• operazioni di lettura, modifica e cancellazione.

Un linter vede spesso la singola riga. Il problema nasce dalla combinazione di dieci file corretti localmente ma incoerenti come sistema.

Può anche succedere che il tool abbia un nome innocuo, come update_order, ma accetti un orderId senza verificare che appartenga all’organizzazione dell’utente. Oppure che la UI nasconda il pulsante di cancellazione, mentre l’endpoint resta invocabile direttamente. Il codice compila e il test con l’account admin passa. Il confine reale, invece, è più largo di quello dichiarato dall’interfaccia.

Cosa fare questa settimana

Prendi una sola integrazione del tuo prodotto Lovable, preferibilmente quella che legge o modifica dati reali. Non provare a revisionare tutto il repo in una volta.

Poi:

• elenca i tool esposti e l’azione concreta di ciascuno;
• riduci gli scope del token al minimo indispensabile;
• separa lettura, scrittura e cancellazione in permessi distinti;
• verifica lato server utente, ruolo e organizzazione;
• aggiungi approvazione esplicita per le azioni irreversibili;
• controlla che i log non contengano token o dati sensibili;
• prova richieste con ruoli diversi e organizzazioni diverse;
• registra quale identità, tool e risorsa sono stati coinvolti;
• fai emettere un verdetto sul repo prima del prossimo go-live.

Se hai costruito con Lovable e vuoi capire se una connessione MCP o un’integrazione cloud ha più potere del necessario, carica il repo su VibeInspect. Per questo caso scegli Diagnostic: ti servono file, righe ed evidenze per restringere i permessi e correggere il confine tecnico.