Lovable ha spedito il tuo agente: ma quali dati può leggere?

Gli agenti entrano nel lavoro di squadra, ma i permessi restano il punto cieco

Slack ha lanciato Slack Code, un tipo di canale pensato per coordinare agenti di coding e sviluppatori. Un agente può ricevere una richiesta, aprire uno spazio dedicato, mostrare piano, repository, branch, diff e anteprima HTML. Il canale resta ricercabile anche dopo l’archiviazione e può funzionare come traccia del lavoro svolto.

La notizia è raccontata da Slack is launching collaborative vibe-coding channels, pubblicato da The Verge il 20 agosto 2026.

Il punto interessante non è soltanto il nuovo canale. È il passaggio da agente personale ad agente dentro un ambiente condiviso: dati aziendali, conversazioni, repository e strumenti iniziano a stare nello stesso flusso operativo.

Se hai costruito il tuo prodotto con Lovable, questa evoluzione ti riguarda direttamente. Il tuo repo può avere un’interfaccia convincente e un’integrazione OAuth funzionante, ma concedere all’agente — o all’utente che lo invoca — più accesso di quello necessario.

Il buco tecnico di oggi è l’OAuth over-scoping: token e autorizzazioni troppo ampi rispetto all’azione richiesta.

Cosa significa se il tuo codice l’ha scritto Lovable

Immagina una web app costruita con Lovable che collega workspace, repository, ticket e documenti tramite OAuth. Il flusso è semplice:

1. l’utente clicca “Connetti Slack” o “Connetti GitHub”;
2. il provider restituisce un authorization code;
3. il backend lo scambia per un access token;
4. l’app usa quel token per leggere dati e avviare azioni.

Il problema non è che OAuth sia presente. Il problema è quali scope vengono richiesti e come vengono usati dopo il consenso.

Per esempio, una funzione che deve soltanto leggere il nome di un canale potrebbe chiedere permessi per leggere tutti i messaggi, modificare contenuti o creare integrazioni. Una funzione che deve aprire una pull request potrebbe ricevere un token con accesso di scrittura all’intero repository, invece che a una singola operazione controllata.

In un’app generata rapidamente, è facile vedere una configurazione simile:

scope = read_channels, read_messages, write_messages, repo_admin

La demo funziona. Il login funziona. L’agente risponde. Ma il confine tra “può svolgere questo compito” e “può leggere o modificare tutto” non è stato davvero verificato.

Il rischio cresce quando il token viene trattato come una proprietà generica dell’utente e non come una delega limitata a uno scopo preciso. Se il frontend conserva dati sensibili, se il backend espone endpoint riutilizzabili o se un agente può scegliere liberamente quale strumento chiamare, un singolo access token troppo potente allarga il danno possibile.

Lovable non è il problema. Il problema è spedire un’integrazione prima di avere un verdetto sui suoi confini.

Perché ora ti serve un audit: non basta che il login funzioni

Un audit serve a verificare se la catena completa dell’autorizzazione è coerente, dal consenso dell’utente fino alla chiamata al provider.

Nel caso di OAuth over-scoping, l’analisi deve rispondere a domande precise:

• quali scope vengono richiesti a ogni provider;
• quali scope vengono effettivamente usati dal prodotto;
• dove vengono salvati access token e refresh token;
• se i token finiscono nel browser, nei log o nei messaggi di errore;
• se il backend verifica quale utente ha autorizzato l’azione;
• se un token ottenuto per un workspace può essere riutilizzato su un altro;
• se l’agente può invocare strumenti non necessari per il compito corrente;
• se revocare l’integrazione interrompe davvero l’accesso residuo.

Questa non è una ricerca di una singola stringa sospetta. È una verifica del percorso tra identità, consenso, token, endpoint e dati.

Un audit VibeInspect prende il repository ZIP, ricostruisce questi flussi e restituisce un verdetto leggibile. Se rileva che la tua app chiede write quando serve solo read, oppure che un endpoint accetta un token senza verificare workspace e azione, il risultato deve collegare il problema al codice e all’evidenza tecnica.

Per questo scenario il piano adatto è Diagnostic. Non ti serve soltanto sapere che esiste una superficie OAuth: ti serve sapere quali file, righe e flussi rendono l’autorizzazione eccessiva o riutilizzabile fuori contesto.

Il report non applica fix e non include una revisione umana ordinaria. Ti consegna però una base concreta per ridurre gli scope, separare i token e correggere gli endpoint prima di dare accesso a dati reali.

Cosa un linter non vede

Un linter può trovare import inutilizzati, errori di sintassi, tipi incoerenti e alcuni pattern rischiosi. È utile per la qualità locale del codice.

Non può però stabilire se un permesso OAuth è coerente con il prodotto. La stringa dello scope può essere perfettamente valida. La richiesta al provider può avere una risposta corretta. Il token può essere memorizzato senza errori. Il difetto può stare nella relazione tra azione richiesta e potere concesso.

Un linter non sa che “mostrare il titolo dell’ultimo ticket” non richiede accesso a tutti i messaggi privati. Non sa che un agente incaricato di preparare una pull request non dovrebbe poter cancellare branch o modificare impostazioni del repository. Non sa che un refresh token salvato senza isolamento per workspace può diventare una chiave riutilizzabile da un altro flusso.

Anche i test di integrazione possono dare falsa sicurezza. Un test che verifica “l’utente collega GitHub e l’app legge il repository” dimostra il percorso felice. Non dimostra che:

• un utente non possa usare il token di un altro workspace;
• un agente non possa chiamare un endpoint amministrativo;
• un token con scope di sola lettura non venga accettato da una rotta di scrittura;
• la revoca dell’integrazione blocchi davvero le richieste successive;
• un errore del provider non riversi token o dettagli sensibili nei log.

Il problema non è soltanto se l’integrazione funziona. È se funziona entro il perimetro giusto.

Cosa fare questa settimana

Se hai spedito con Lovable, non partire da una riscrittura. Parti dall’inventario dei poteri concessi.

1. Elenca ogni integrazione OAuth presente nel prodotto.
2. Scrivi per ciascuna funzione quali dati deve leggere e quali azioni deve eseguire.
3. Confronta questi requisiti con gli scope richiesti al provider.
4. Riduci gli scope al minimo: lettura dove basta la lettura, scrittura solo dove è indispensabile.
5. Verifica che i token siano gestiti dal backend e isolati per utente, organizzazione e ambiente.
6. Controlla che ogni endpoint verifichi identità, workspace, azione e risorsa prima di usare il token.
7. Aggiungi test negativi: token revocato, scope insufficiente, workspace errato, azione non consentita.
8. Controlla log, errori e callback OAuth per evitare che token o codici di autorizzazione vengano esposti.
9. Se un agente può usare più strumenti, definisci quali strumenti sono ammessi per ogni attività.
10. Revoca e rinnova le autorizzazioni di prova, poi verifica che l’accesso precedente non resti attivo.

La domanda finale è semplice: puoi dimostrare che ogni token può fare soltanto ciò che serve?

“Il collegamento OAuth funziona” non è un verdetto. “L’integrazione Slack legge solo i canali autorizzati, l’integrazione GitHub non può scrivere oltre l’azione prevista e il token revocato non è più utilizzabile” è un verdetto.

Se non sai ancora quanto è ampia la superficie del tuo repo, parti da VibeInspect.ai con Snapshot. Se hai già individuato un’integrazione OAuth troppo permissiva o un token riutilizzato tra workspace, scegli Diagnostic per ottenere evidenze su file, righe e flussi.

Lovable ti ha aiutato a spedire più velocemente. Adesso serve verificare che il tuo agente non abbia ricevuto le chiavi di tutta la casa quando gli serviva soltanto aprire una porta.