MCP e FastAPI: i token di contesto che nessuno controlla nel tuo repo

Il Model Context Protocol sposta i tuoi dati sensibili in un servizio che devi mettere in sicurezza da solo

Una guida tecnica pubblicata su dev.to, "Model Context Protocol Examples: How to Run MCP with FastAPI", spiega come collegare un server MCP a un backend FastAPI per passare contesto agli LLM tramite token invece di gonfiare ogni prompt. Un passaggio è particolarmente onesto: l'autore ricorda che il servizio MCP non ripulisce i dati al posto tuo e che i token bearer vanno tenuti corti, ruotati e scoperti da un secret manager, non scritti nei Dockerfile.

È un dettaglio piccolo, ma è esattamente il punto in cui molti repository generati con AI si rompono in produzione. L'architettura funziona in demo, risponde in meno di 300 ms, supera l'health check. E intanto un token che dovrebbe vivere due minuti resta valido per ore, oppure un documento pieno di dati personali finisce caricato su un servizio esterno senza uno straccio di redazione.

Cosa significa se il tuo codice l'ha scritto Cursor

Quando chiedi a Cursor di "integrare un server di contesto con FastAPI e OpenAI", ottieni codice che compila e gira. Cursor riproduce fedelmente il pattern che ha visto migliaia di volte: crea il client HTTP, richiede il token, lo passa nella metadata. Tutto corretto sul piano sintattico.

Quello che Cursor non decide per te è la postura di sicurezza intorno a quel token. Nel codice generato trovi spesso:

• il segreto MCP scritto in chiaro come stringa ("Bearer prod-secret"), perché nel prompt di esempio era così;
• expires_in fissato a un valore generoso o assente, quindi token che sopravvivono molto oltre la singola richiesta;
• nessun controllo sull'audience: un token pensato per una singola organizzazione può leggere il contesto di un'altra;
• il contenuto caricato su MCP senza alcun filtro sui dati personali dell'utente.

Nessuna di queste cose fa fallire un test. Il tuo repository sembra sano perché fa quello che gli hai chiesto. Il problema è che nessuno ha mai dato un verdetto su quello che l'AI ha effettivamente scritto: hai un servizio che maneggia contesto sensibile e credenziali, ma non sai in che stato è la sua superficie di attacco.

Perché ora ti serve un audit

Un repository nato con l'AI cresce per accumulo. Aggiungi un endpoint, colleghi un servizio esterno, incolli un altro pezzo di esempio, e ogni passaggio introduce una decisione di sicurezza implicita che nessuno ha preso consapevolmente. Con MCP la decisione critica è chiara: chi può ottenere un token, per quanto tempo vale, cosa può leggere e cosa carichi verso l'esterno.

Un audit serve proprio a rispondere a queste domande con evidenze, non con sensazioni. Non ti serve "più codice": ti serve sapere dove il tuo repo espone segreti hardcoded, dove i token hanno una scadenza troppo lunga, dove manca un controllo di autorizzazione tra tenant diversi.

VibeInspect nasce per questo. Comprimi il repository in uno ZIP, lo carichi, degli specialisti AI lo analizzano e ricevi un PDF con un verdetto. Nessun server da configurare, il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non è un linter e non corregge il codice al posto tuo: ti dice in che stato è, così puoi decidere cosa sistemare prima.

Con il piano Diagnostic di VibeInspect ottieni file, riga ed evidenze: sai esattamente dove il segreto MCP è finito in chiaro, quale endpoint accetta un token senza verificarne lo scope, quale funzione carica contenuto senza ripulire i dati personali.

Cosa un linter non vede

Un linter è utile, ma ragiona sulla forma del codice, non sul suo significato di sicurezza. Prende una decisione locale su una singola riga: indentazione, import non usati, tipi incoerenti.

Quello che un linter non può dirti sul tuo servizio MCP:

• che quel "prod-secret" è una credenziale reale e non una costante innocua;
• che un token con expires_in alto amplia la finestra in cui una fuga diventa sfruttabile;
• che manca la verifica dell'audience, quindi un utente può leggere il contesto di un'altra organizzazione (un classico IDOR applicato al recupero di contesto);
• che il contenuto caricato su MCP contiene dati personali che avrebbero dovuto essere redatti prima dell'invio.

Queste sono decisioni di architettura e di autorizzazione. Richiedono di seguire il flusso dei dati attraverso più file: da dove arriva il documento, chi genera il token, chi lo consuma, cosa succede se scade troppo tardi. Un linter non attraversa quel percorso. Un audit sì, ed è la differenza tra "il codice è pulito" e "il codice è al sicuro".

Cosa fare questa settimana

Se hai un servizio che passa contesto a un LLM, dedica un'ora a queste verifiche concrete:

1. Cerca i segreti in chiaro. Fai un grep per Bearer, secret, api_key, token nel repository. Ogni risultato scritto direttamente nel codice va spostato in variabili d'ambiente o in un secret manager.
2. Controlla la scadenza dei token. Trova ogni expires_in (o equivalente) e chiediti se quel valore ha davvero senso per la durata di una singola richiesta. Se non lo imposti, impostalo.
3. Verifica lo scope. Ogni token che recupera contesto deve essere legato a una singola organizzazione o caso d'uso. Aggiungi un controllo che rifiuti l'accesso a contesto di un tenant diverso.
4. Guarda cosa carichi. Prima di inviare un documento a un servizio esterno, verifica che non contenga dati personali che avrebbero dovuto essere rimossi.

Se dopo queste verifiche non hai la certezza dello stato del tuo repo, chiedi un verdetto. Carica lo ZIP su VibeInspect e scegli Diagnostic per ottenere file, riga ed evidenze sui token esposti e sulle autorizzazioni mancanti. Aver usato l'AI per costruire non è il problema: il problema è pubblicare senza sapere cosa ha scritto davvero.