Revisione di un server MCP prima di dare i tool all'agente AI

Un server MCP va trattato come codice di terze parti che agisce con le Sue credenziali, e va sottoposto a revisione prima che l'agente possa invocarlo. I controlli che seguono si basano sulla specifica di autorizzazione MCP (revisione 2025-06-18) e sulle best practice di sicurezza MCP (revisione 2025-11-25). Le revisioni differiscono tra loro, quindi conviene consultare la specifica corrente prima di fare affidamento su un qualsiasi requisito.

L'autorizzazione è opzionale, quindi verifichi che esista

I server con trasporto HTTP dovrebbero seguire la specifica di autorizzazione. I server STDIO no: prelevano invece le credenziali dall'ambiente. Per un server STDIO locale, elenchi le variabili d'ambiente che la configurazione del client passa al processo e si chieda se ciascuna sia davvero necessaria.

Per un server HTTP, invii una richiesta non autenticata:

curl -i https://mcp.example.com/mcp

Dovrebbe ricevere un 401 Unauthorized con un header WWW-Authenticate che indica l'URL dei metadati della risorsa. Lo scarichi e verifichi che il documento contenga authorization_servers con almeno una voce. Se il server risponde con dei dati, si fermi qui.

Poi confermi i punti che la specifica indica come obbligatori:

• Il client invia Authorization: Bearer <access-token> a ogni richiesta HTTP e il token non compare mai nella query string dell'URI.
• Gli endpoint dell'authorisation server usano HTTPS, e i redirect URI sono localhost oppure HTTPS.
• L'authorisation server confronta i redirect URI con corrispondenza esatta rispetto ai valori preregistrati.
• I client implementano PKCE.

I client dovrebbero inoltre verificare il parametro state, e gli authorisation server dovrebbero emettere access token di breve durata.

Audience e scope del token

Il client deve inviare il parametro resource (RFC 8707) sia nelle richieste di autorizzazione sia in quelle di token, e il server deve verificare che ogni token sia stato emesso specificamente per lui. In caso contrario, i token emessi per altri servizi funzionano anche contro di esso.

Il token passthrough è peggio: il server accetta un token non emesso per lui e lo inoltra invariato a valle. Controlli come il rate limiting e il monitoraggio possono dipendere dall'audience del token, e i log a valle possono attribuire le richieste all'identità sbagliata, rendendo più difficili le indagini.

Per testare il vincolo di audience, usi un client registrato per richiedere un token per una risorsa diversa al token_endpoint indicato nei metadati dell'authorisation server. Lo riproponga poi al server MCP:

curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcp

Il risultato atteso è 401. Un token valido ma privo dei permessi necessari dovrebbe ricevere 403. Se l'authorisation server non emette un token di questo tipo, chieda al fornitore come il server MCP controlli l'audience.

Chieda anche dove il server conserva i token. I public client devono ruotare i refresh token, e i token memorizzati in cache o nei log sul server sono un bersaglio per il furto.

Server proxy e consenso

Se il server MCP fa da front-end a un'API di terze parti con un unico client ID statico, legga la sezione sul confused deputy nelle best practice. L'attacco richiede un client ID statico, la dynamic client registration, un cookie di consenso dell'authorisation server di terze parti e l'assenza di consenso per singolo client sul proxy. Quest'ultimo punto spetta a Lei correggerlo: il proxy dovrebbe mantenere un registro dei valori client_id approvati per ciascun utente e mostrare nome del client, scope e redirect URI nella propria pagina di consenso, che deve impedire l'inserimento in iframe tramite frame-ancestors oppure X-Frame-Options: DENY.

Allowlist dei tool, poi riduzione

Chieda al server l'elenco dei suoi tool e lo confronti con ciò che serve al compito. Tutto ciò che eccede è funzionalità eccessiva nei termini di OWASP LLM06:2025. Lo rimuova, oppure impedisca all'agente di invocarlo.

Salvi l'elenco come baseline e ne faccia il diff dopo ogni aggiornamento del server, in modo che un tool aggiunto con un aggiornamento venga esaminato prima che l'agente possa chiamarlo. Poi controlli ciascun tool rimasto:

• È a finalità aperta, come "esegui un comando di shell" o "recupera un URL"? Lo sostituisca con un tool mirato. L'esempio di OWASP è un tool di scrittura file al posto dell'accesso alla shell.
• Quale identità usa a valle? Un tool che legge dati dovrebbe connettersi solo con SELECT, non con UPDATE, INSERT e DELETE.
• Agisce per conto di un singolo utente? Allora dovrebbe autenticarsi tramite OAuth con lo scope minimo, non tramite un account generico privilegiato.

I limiti vanno applicati nel sistema a valle. OWASP lo chiama complete mediation: non ci si deve affidare al modello per decidere se un'azione sia consentita.

Approvazione umana per le azioni di scrittura

Allucinazioni e prompt injection sono inneschi frequenti di azioni dannose, quindi le azioni ad alto impatto richiedono una persona nel ciclo. OWASP descrive un assistente di posta che riassume i messaggi in arrivo. Un'email iniettata lo induce a cercare nella casella informazioni sensibili e a inoltrarle all'attaccante.

Un'estensione in sola lettura, uno scope OAuth in sola lettura o la revisione manuale di ogni email redatta prima dell'invio avrebbero ciascuno interrotto quell'attacco. Conviene sovrapporli dove possibile.

Tutto ciò che elimina, invia o pubblica deve rientrare nell'elenco delle azioni da approvare. L'approvazione va collocata nell'estensione o nel sistema a valle. Logging e rate limiting non prevengono l'agency eccessiva, ma rendono più facile accorgersi delle azioni indesiderate.

Se il client viene eseguito lato server

Durante l'OAuth discovery il client recupera URL forniti dal server, tra cui resource_metadata, authorization_servers e token_endpoint. Un server malevolo può puntarli verso indirizzi interni o verso l'endpoint dei metadati cloud su 169.254.169.254.

In produzione si richieda HTTPS, si blocchino gli intervalli privati e riservati, e si validino le destinazioni dei redirect oppure si disabilitino i redirect automatici. Non scriva a mano la validazione degli IP, perché i trucchi con notazione ottale, esadecimale e IPv6 mappato su IPv4 aggirano i parser personalizzati. Valuti un egress proxy come Smokescreen.

Poi lo verifichi con un test. Allestisca un server di test ostile che restituisca un 401 il cui header WWW-Authenticate contenga un URL resource_metadata che punta a http://169.254.169.254/, quindi ripeta il test con un URL che reindirizza a un indirizzo interno. Il client dovrebbe rifiutare entrambi, e un listener sulla destinazione interna non dovrebbe vedere alcuna richiesta.

Da dove cominciare

1. Elencare ogni server MCP usato dai Suoi agenti, con il relativo trasporto e operatore. Rimuovere quelli di cui non si sa rendere conto.
2. Eseguire curl -i su ogni server HTTP e confermare il 401 con un header WWW-Authenticate. Poi riproporre un token emesso per un'altra risorsa.
3. Per i server proxy con client ID statico, rivedere il flusso di consenso: registro per singolo client, contenuto della pagina di consenso, protezione dal framing.
4. Definire la baseline dell'elenco dei tool di ciascun server, ridurlo a ciò che il compito richiede, assegnare a ogni tool l'identità con i privilegi minimi e richiedere l'approvazione umana per i tool di scrittura e cancellazione.
5. Per i client lato server, eseguire il test SSRF con un server di test ostile.
6. Ripetere i passi da 2 a 5 ogni volta che un server si aggiorna, aggiunge un tool o modifica i propri scope.

Per una revisione esterna, consulti il nostro servizio di consulenza. Il nostro servizio di penetration test può eseguire i controlli su token e consenso sulla Sua configurazione.