Cursor e MCP: il tuo repo sa davvero chi può cambiare cosa?

Gli agenti non si limitano più a suggerire: ora modificano ambienti vivi

Spline ha rilasciato V2 con un MCP Server che permette a strumenti come Cursor, Claude Code, Codex, Google Antigravity e VS Code di lavorare direttamente su scene 3D aperte nell’editor. L’agente può leggere lo stato del progetto, modificare la scena e intervenire sul comportamento mantenendo tutto editabile.

La parte interessante è anche quella che dovrebbe farti fermare un minuto: il server gira localmente, permette di scegliere quali client possono accedere, ma la documentazione non chiarisce come attribuire e revisionare ogni modifica quando più sessioni agentiche lavorano sullo stesso progetto. La notizia completa è su The New Stack.

Per chi sta costruendo un prodotto con Cursor, il punto non è Spline. È il passaggio da “l’agente mi propone una modifica” a “l’agente può chiamare strumenti che cambiano lo stato di un sistema”. Nel tuo repo questo può voler dire un endpoint MCP, un webhook, un’integrazione con GitHub o un servizio interno capace di scrivere dati, pubblicare contenuti o modificare configurazioni.

Cosa significa se il tuo codice l’ha scritto Cursor

Quando hai usato Cursor per collegare un’app a strumenti esterni, probabilmente hai pensato a due cose: far funzionare il flusso e rendere l’esperienza fluida. L’agente genera il codice, tu provi il caso principale, il risultato sembra corretto e si va online.

Il problema nasce nei confini.

Un’integrazione MCP o un sistema equivalente espone funzioni operative. Alcune leggono dati. Altre li modificano. Altre ancora possono inviare richieste verso servizi esterni. Se il codice distingue solo tra “utente autenticato” e “utente non autenticato”, ma non verifica cosa quell’utente possa fare su quella specifica risorsa, hai un problema di autorizzazione.

L’esempio concreto è semplice: un utente autorizzato a usare un’integrazione può chiamare un tool previsto per modificare un progetto, passando l’ID di un altro progetto. Se il server si fida dell’ID ricevuto dal client senza verificare la relazione tra identità, workspace e risorsa, l’errore è un IDOR. Non serve che l’agente sia malevolo. Basta una chiamata costruita con parametri validi ma riferiti all’oggetto sbagliato.

Cursor può aver scritto un handler perfettamente funzionante. Il linter può approvarlo. I test possono coprire il progetto corretto. Eppure il confine tra “puoi modificare il tuo progetto” e “puoi modificare qualunque progetto di cui conosci l’ID” può non esistere.

Perché ora ti serve un audit

Il passaggio a strumenti che eseguono azioni rende insufficiente la domanda “il codice funziona?”. La domanda utile è: qual è il verdetto sul perimetro delle operazioni che questo repo espone?

Un audit tecnico deve ricostruire il percorso completo di una richiesta: da chi la invia, come viene autenticata, quali parametri controlla, quale risorsa raggiunge e quale effetto produce. Nel caso di un’integrazione costruita con Cursor, questo significa cercare i punti in cui il codice registra tool, endpoint o callback e verificare se ogni operazione applica autorizzazioni coerenti con la risorsa coinvolta.

Il controllo non si ferma alla presenza di middleware come auth, session o requireUser. Quello è solo l’inizio. Bisogna capire se il controllo viene eseguito prima della query o della mutazione, se usa l’identità della sessione e non un valore fornito dal client, se considera workspace e tenant, se separa operazioni di lettura da operazioni di scrittura e se impedisce escalation attraverso parametri manipolati.

Il risultato che ti serve non è una lista infinita di avvisi. È una risposta operativa:

• il server verifica davvero il possesso o l’accesso alla risorsa?
• i tool più potenti hanno autorizzazioni più strette?
• un client può invocare direttamente un’azione distruttiva?
• esistono controlli diversi tra ambiente di sviluppo e produzione?
• il codice lascia evidenze sufficienti per capire chi ha eseguito una modifica?

Con VibeInspect carichi lo ZIP del repo e ottieni un verdetto sull’area analizzata. Con il piano Diagnostic puoi vedere file, righe ed evidenze del problema. Non è un pentest e non sistema il codice: serve a togliere l’ambiguità prima del go-live, quando “sembra protetto” non è una risposta difendibile.

Il punto cieco: configurare l’accesso non significa applicare l’autorizzazione

Nel caso descritto da The New Stack, Spline lega il server locale a 127.0.0.1, usa un’allowlist di origini e permette di selezionare i client autorizzati. Sono controlli utili sul canale di connessione. Ma non rispondono da soli alla domanda più importante per il tuo backend: cosa può fare ogni chiamante dopo essere entrato?

Questa distinzione è spesso persa nei repo generati rapidamente. Un’app può limitare le origini del browser e avere comunque un endpoint che accetta projectId, sceneId, workspaceId o userId senza verificare che appartengano all’identità autenticata. Può anche proteggere l’accesso alla pagina di configurazione, ma lasciare scoperto il tool che esegue la mutazione.

Un linter vede sintassi, tipi, import inutilizzati, pattern sospetti e alcune classi di bug. Non sa quale utente dovrebbe poter modificare quella scena. Non conosce il contratto di business tra account e workspace. Non può emettere un verdetto affidabile sul fatto che un’azione MCP sia autorizzata per quella specifica risorsa solo perché il codice compila.

L’audit serve proprio a collegare il flusso tecnico al rischio reale: autenticazione, autorizzazione, dati e side effect nello stesso percorso.

Cosa un linter non vede

Un linter può segnalare che una variabile non viene usata. Non può dirti che il valore usato per autorizzare una richiesta arriva dal body invece che dalla sessione.

Può riconoscere una chiamata a un ORM. Non può stabilire che la query filtra per workspace_id in un punto e lo dimentica in un altro.

Può trovare una funzione chiamata deleteScene. Non può capire se quella funzione è raggiungibile da un tool esposto a un agente senza approvazione aggiuntiva, audit log o controllo del ruolo.

Può verificare che un endpoint risponde con 200. Non può dimostrare che il comportamento resta corretto quando l’utente cambia l’ID della risorsa, ripete la richiesta o usa un account appartenente a un altro tenant.

Per questo il nemico non è Cursor. Cursor ha ridotto il costo di scrivere integrazioni e collegare sistemi. Il nemico è spedire senza un verdetto sul confine di fiducia.

Cosa fare questa settimana

1. Elenca ogni tool, endpoint, webhook e callback che può modificare dati o chiamare servizi esterni.
2. Per ciascuno, scrivi chi può invocarlo e su quali risorse può agire.
3. Cerca handler che ricevono ID dal client e verifica dove viene applicato il controllo di ownership o membership.
4. Se usi MCP o un’integrazione simile, separa chiaramente operazioni di lettura, scrittura e cancellazione.
5. Aggiungi test negativi: utente corretto con risorsa sbagliata, tenant diverso, ruolo insufficiente, richiesta ripetuta.
6. Carica il repo su VibeInspect.ai e ottieni un verdetto prima di chiamare “pronta” l’integrazione.

Se il dubbio è “non so quanto sia esposto il mio repo”, parti da Snapshot: score sintetico, senza file o righe. Se hai già un’integrazione con MCP, tool operativi o accesso multi-tenant e vuoi capire esattamente dove sta il buco, scegli Diagnostic: €499 per evidenze file/riga, senza fix e senza revisione umana.

Il punto non è dimostrare che hai usato bene Cursor. Il punto è sapere se il codice che hai spedito può cambiare solo ciò che deve cambiare. Carica il repo e ottieni il verdetto.