Cursor e MCP: il tuo repo può cambiare senza lasciare traccia

Il vero salto non è l’AI: è darle le chiavi del progetto

Spline ha rilasciato V2 con un MCP Server che permette a strumenti come Claude Code, Cursor, Codex e VS Code di lavorare direttamente dentro una scena 3D aperta. L’agente non produce soltanto un file da esportare: può leggere il progetto vivo, modificarlo e lasciare il risultato ancora editabile.

La notizia completa è Spline rebuilt its entire 3D editor. Then it handed the keys to Claude Code.

È un passaggio importante perché sposta l’agente da generatore di codice a operatore con accesso a un ambiente reale. E quando un sistema può modificare un progetto, la domanda non è più soltanto “il risultato funziona?”. Diventa: chi ha potuto cambiare cosa, attraverso quale collegamento e con quale autorizzazione?

Cosa significa se il tuo codice l’ha scritto Cursor

Cursor è spesso il punto in cui il developer incontra per la prima volta MCP: aggiungi un server, dai accesso a uno strumento e l’agente può interagire con servizi esterni, repository, database o ambienti di sviluppo.

Immagina un progetto con un server MCP che permette di creare file, modificare configurazioni, aggiornare record o pubblicare un asset. L’integrazione funziona. Cursor invia la richiesta. Il server esegue l’azione.

Il buco concreto arriva quando il controllo si ferma alla connessione iniziale: “questo client è autorizzato”. Da quel momento, ogni tool call viene eseguita senza distinguere abbastanza tra utente, sessione, progetto o tipo di operazione.

Il risultato può essere un problema di privilegi e tracciabilità delle azioni MCP:

• più sessioni Cursor condividono la stessa credenziale;
• il server verifica l’origine della richiesta, ma non il ruolo dell’utente;
• un tool di sola lettura può invocare indirettamente un’azione di modifica;
• le operazioni vengono applicate al progetto aperto senza un controllo esplicito sul target;
• i log registrano “MCP updated scene”, ma non chi ha autorizzato l’azione;
• una modifica automatica non è collegata a commit, richiesta o identità verificabile.

Non significa che Cursor o MCP siano insicuri per definizione. Significa che l’integrazione crea un nuovo confine di fiducia. Se lo hai configurato in fretta, potresti avere un server che sa fare molto più di quanto il tuo modello di autorizzazione sappia governare.

Perché ora ti serve un audit: il verdetto sul confine MCP

Quando l’agente entra nel progetto, il permesso non è più astratto. Diventa operativo: leggere, creare, aggiornare, cancellare o pubblicare.

Per questo il tuo repo ha bisogno di un verdetto su una domanda precisa:

ogni azione eseguita tramite MCP è limitata al progetto e al ruolo corretti, e può essere ricostruita dopo l’esecuzione?

Un audit VibeInspect serve a collegare elementi che spesso vivono in file diversi:

1. configurazione del client o del server MCP;
2. autenticazione e gestione delle credenziali;
3. elenco degli strumenti esposti;
4. controllo dei parametri ricevuti dalla richiesta;
5. verifica del progetto o della risorsa target;
6. autorizzazione specifica per lettura, modifica e pubblicazione;
7. logging dell’attore, della sessione e dell’azione effettuata.

Il punto non è trovare una stringa come mcp o allowedOrigins. Il punto è ricostruire il percorso completo. Un origin allowlist può ridurre le richieste arbitrarie dal browser, ma non dimostra che il server sappia distinguere Alice da Bob, né che una sessione possa operare soltanto sul workspace previsto.

Il verdetto utile è concreto: il server applica controlli coerenti prima di ogni operazione sensibile, oppure esiste un percorso in cui una richiesta autenticata può modificare una risorsa senza un vincolo sufficiente su identità, progetto o permesso.

VibeInspect prende il tuo repository ZIP, lo analizza e restituisce un PDF con score e verdetto. Nel piano Diagnostic trovi evidenze riferite a file e righe. Non modifica il codice e non sostituisce una verifica live dell’infrastruttura: ti aiuta però a capire se il confine di autorizzazione è davvero implementato nel repo o soltanto presunto dalla configurazione.

Le evidenze che distinguono un controllo reale da una connessione “protetta”

Un’integrazione MCP può apparire ben configurata e avere comunque un problema di privilegi. Le evidenze da cercare sono combinazioni, non singole righe.

• Credenziale condivisa e identità assente. Se tutte le sessioni usano lo stesso token, il sistema potrebbe non riuscire ad attribuire un’azione a una persona o a un workspace.
• Autorizzazione solo all’avvio. Controllare il client quando apre la connessione non basta se ogni chiamata successiva può agire su qualunque risorsa.
• Target controllato dal client. Un parametro come projectId, sceneId o workspace deve essere verificato lato server, non accettato perché arriva da Cursor.
• Tool troppo ampi. Un server che espone un unico comando generico come execute o updateProject rende difficile applicare il principio del minimo privilegio.
• Modifica senza controllo di stato. Se l’azione usa il progetto attualmente aperto o un riferimento memorizzato in sessione, verifica che quel riferimento non possa cambiare in modo inatteso.
• Log senza contesto. Un timestamp e un messaggio di successo non sono sufficienti: servono almeno attore, sessione, tool, target e risultato dell’operazione.

L’audit non deve produrre una lista infinita di avvisi. Deve stabilire se esiste una catena verificabile tra identità, permesso, risorsa e modifica.

Cosa un linter non vede

Un linter può segnalare una variabile inutilizzata, un tipo errato o una chiamata non gestita. Può anche individuare alcune API rischiose. Ma non dimostra che una richiesta MCP sia autorizzata per quella specifica risorsa.

Non vede, da solo, che:

• due utenti diversi operano con lo stesso token;
• il server accetta un projectId inviato dal client senza confrontarlo con la sessione;
• un tool descritto come “edit” può modificare anche configurazioni fuori dal progetto;
• il controllo sull’origine della richiesta viene scambiato per un controllo sull’identità;
• il log non collega la modifica a una persona o a una richiesta approvata;
• una sessione può restare valida dopo il cambio di workspace o di ruolo.

Nemmeno i test felici bastano. Un test può confermare che Cursor aggiorna correttamente il progetto di Alice. La domanda importante è cosa succede quando la stessa sessione prova a indicare il progetto di Bob, quando il token è condiviso o quando il progetto aperto cambia tra lettura e modifica.

Il linter controlla la forma del codice. L’audit verifica se i privilegi seguono davvero identità, risorsa e operazione.

Cosa fare questa settimana

Scegli una sola integrazione MCP che può modificare qualcosa: repository, scena, database, file o ambiente di deploy.

Poi costruisci una tabella semplice:

• identità che avvia la sessione;
• credenziale usata;
• tool disponibili;
• risorsa target;
• operazioni consentite;
• log prodotto;
• controllo che impedisce di uscire dal perimetro.

Verifica in particolare se il server ricava l’identità dalla sessione verificata, se il target viene autorizzato lato backend e se le operazioni sensibili hanno permessi separati. Controlla anche se puoi ricostruire una modifica dopo qualche giorno: chi l’ha eseguita, con quale sessione, su quale progetto e con quale risultato.

Se non sai rispondere indicando file, funzione e regola, non aggiungere un altro tool MCP. Ti manca prima un verdetto sul repo.

Carica lo ZIP su VibeInspect.ai. Per questo caso sceglierei il piano Diagnostic, perché il problema è tecnico e hai bisogno di evidenze su autorizzazioni, target e tracciabilità.

L’obiettivo non è dimostrare che Cursor abbia scritto codice “sbagliato”. È sapere se il tuo progetto può essere modificato soltanto da chi deve farlo e se, quando succede, puoi dimostrarlo.