Blindare un server MCP per l'enterprise: SSO, audit, gateway

Blindare un server MCP per l'enterprise significa portarlo da demo che si fida di chiunque abbia l'URL a servizio che verifica un'identità reale a ogni chiamata, registra cosa ha fatto ogni agente e applica il privilegio minimo su un gateway. Alla fine di questa guida avrai un server MCP che valida un token di accesso OAuth 2.1 a ogni richiesta, instrada il login attraverso l'identity provider aziendale, scrive una riga di audit per ogni invocazione di tool e sta dietro un gateway che limita ogni agente ai soli tool che gli servono. È la differenza tra un proof of concept e qualcosa che un team di sicurezza approverà.

Il divario non è teorico. Una review del 2026 su 1.000 server MCP pubblici ha trovato vulnerabilità critiche nel 33% dei casi. Endor Labs ha analizzato 2.614 implementazioni MCP: l'82% espone operazioni su file soggette a path traversal, il 67% chiama API legate a code injection e il 34% tocca API vulnerabili a command injection. Il primo server malevolo documentato pubblicamente, postmark-mcp, ha raggiunto circa 300 organizzazioni prima della scoperta. E CVE-2025-6514, una command injection nel client mcp-remote molto usato, ha ottenuto punteggio 9.6 su un pacchetto con oltre 437.000 download. Un server MCP è una superficie di esecuzione remota puntata sui tuoi tool interni. Trattalo come tale.

Cosa serve prima di iniziare

• Un server MCP remoto su HTTP (i server locali solo stdio hanno un threat model diverso e restano fuori da qui).
• Un identity provider enterprise che parli OAuth 2.1 / OIDC: Okta, Microsoft Entra ID, Auth0 o Keycloak vanno tutti bene.
• Un posto dove mandare i log: un SIEM o un sink come Microsoft Sentinel, Splunk o un bucket S3 con retention.
• La possibilità di mettere un reverse proxy o un gateway davanti al server. Può essere un API gateway esistente o un gateway MCP dedicato.

Passo 1: rendi il server un resource server OAuth 2.1

La spec di autorizzazione MCP attuale (revisione 2026-07-28) si basa su OAuth 2.1. Il server MCP agisce da resource server OAuth: non gestisce il login, valida i token di accesso emessi da un authorization server separato. In concreto, il server deve rifiutare ogni richiesta senza un bearer token valido, validare il token secondo la Sezione 5.2 di OAuth 2.1 e pubblicare i Protected Resource Metadata perché i client scoprano quale authorization server usare. Tutti gli endpoint di autorizzazione girano su HTTPS e i client devono usare PKCE con SHA-256. L'accesso anonimo è l'errore più comune che vediamo in giro, quindi si parte da qui.

Passo 2: instrada il login attraverso il tuo identity provider (SSO)

Non costruire il login da zero. Punta i metadata dell'authorization server sull'IdP aziendale, così autenticarsi al server MCP significa autenticarsi a Okta, Entra o Auth0, con la stessa MFA, gli stessi conditional access e lo stesso offboarding che la tua organizzazione già usa. È questo che ti dà l'SSO: quando un dipendente se ne va e l'IT disabilita il suo account, l'accesso del suo agente al server MCP muore con lui. Evita le API key statiche in produzione. Sono difficili da ruotare, difficili da attribuire a una persona e trasformano ogni riga di log in una riga anonima. Token a vita breve con rotazione sono lo standard enterprise, e si abbinano al pattern TTL che usiamo per gli URL del server stesso.

Passo 3: lega ogni token al tuo server, e non passarli mai in pass-through

È il passo che la maggior parte dei tutorial salta, ed è quello che ferma gli attacchi peggiori. Un agente AI in una singola sessione può toccare molti resource server, e questo rende acuto il problema OAuth del confused deputy: un token pensato per un server viene rigiocato contro un altro. La spec chiude la falla in due modi. Primo, i client DEVONO usare i Resource Indicators (RFC 8707): il client nomina il tuo server nella richiesta di token e l'authorization server emette un token la cui audience è il tuo server e nient'altro. Il tuo server poi rifiuta ogni token non emesso per sé. Secondo, la spec dice che il server MCP NON DEVE passare il token del chiamante a un'API a valle. Il token passthrough è l'anti-pattern del confused deputy, per nome. Quando il tuo server deve chiamare qualcosa a valle per conto dell'utente, usa il Token Exchange (RFC 8693): scambia il token in ingresso con uno nuovo, legato all'audience, che conserva l'identità dell'utente in un actor claim. Stesso utente, audience corretta, nessun replay.

Passo 4: metti un gateway davanti e limita i tool al privilegio minimo

Quando hai più di un server MCP, o più di una manciata di tool, centralizza i controlli. Un gateway MCP si mette tra agenti e server e applica autenticazione, permessi per singolo tool e logging in un punto solo, trasformando lo sprawl di tool non governato in infrastruttura gestita. Il gateway è dove applichi il privilegio minimo: un agente di supporto ottiene i tool di sola lettura, un agente di billing ottiene il tool di rimborso, e nessun agente ottiene tutti i tool solo perché si è autenticato. Il gateway è anche il posto giusto per fare il Token Exchange del Passo 3 e per validare gli schemi di input dei tool prima che una chiamata raggiunga il server, il che smorza le classi di injection segnalate dai dati di Endor Labs.

Passo 5: attiva l'audit logging strutturato verso il tuo SIEM

L'approvazione enterprise richiede di rispondere a chi ha avuto accesso a cosa, quando e perché. Emetti una riga di log strutturata per ogni chiamata a un tool: il soggetto autenticato, il nome del tool, gli argomenti (oscurati dove sensibili), la risorsa toccata e il risultato. Manda quelle righe al SIEM esistente invece che a un file locale, così ereditano retention, alerting e ricerca. Export su Microsoft Sentinel, forwarding su Splunk e archiviazione su S3 sono i percorsi comuni, ed è quello che un audit SOC 2 o ISO 27001 chiederà. I log ti danno anche il rilevamento delle anomalie: un picco nelle chiamate di un singolo agente, o un tool invocato alle 3 di notte da una posizione nuova, è un segnale che vedi solo se lo hai registrato.

Passo 6: fissa e scansiona le definizioni dei tool

Il tool poisoning e i rug pull sfruttano il fatto che gli agenti si fidano delle descrizioni dei tool. Un server può spedire una descrizione innocua, farsi approvare e poi ridefinire silenziosamente il tool per esfiltrare dati. Difenditi fissando le definizioni dei tool a una versione, trattando un cambio di descrizione come un cambiamento che richiede revisione e scansionando i server MCP di terze parti prima di collegarci un agente. Cura un registro interno di server approvati invece di lasciare che qualsiasi agente si colleghi a qualsiasi URL. È governance, non codice, ma è il controllo che avrebbe fermato l'integrazione MCP di WhatsApp che a fine 2025 avvelenava le descrizioni dei tool per estrarre le cronologie dei messaggi.

Verificare che funzioni

Fai questi controlli prima di dire che il server è blindato:

1. Una richiesta senza token restituisce 401 e la risposta pubblicizza l'authorization server via Protected Resource Metadata.
2. Un token emesso per un'altra risorsa viene rifiutato (testa il tuo controllo di audience RFC 8707).
3. Disabilitare un utente nell'IdP annulla l'accesso del suo agente entro la vita del token.
4. Ogni chiamata a un tool produce esattamente una riga di audit nel SIEM, con il soggetto autenticato presente.
5. Un agente autorizzato per il tool A non può invocare il tool B attraverso il gateway.

Errori comuni e correzioni

• Il server accetta qualsiasi token valido. Validare non basta. Controlla l'audience. Un token emesso per un altro servizio che condivide il tuo IdP validerà, ma non è per te.
• Token passati diretti alle API a valle. È l'anti-pattern del confused deputy che la spec vieta. Inserisci il Token Exchange nel gateway.
• Audit log su disco locale. Spariscono con il container e nessuno ci fa alerting. Mandali al SIEM.
• Uno scope unico e ampio per tutti i tool. Se autenticarsi concede ogni tool, hai autenticazione senza autorizzazione. Separa gli scope per tool o gruppo di tool.
• Fidarsi dei server di terze parti per URL. Una RCE con CVSS 9.6 è arrivata in un pacchetto con 437.000 download. Verifica prima di collegarti.

Andare oltre

Se il server non l'hai ancora costruito, parti dalla nostra guida su come costruire un server MCP per un SaaS Next.js esistente, poi applica sopra questa passata di hardening. Per i pattern di sicurezza a livello di richiesta che questi passi danno per scontati, vedi la sicurezza delle server actions in Next.js. Il filo conduttore è lo stesso che governa il resto dello stack: autentica ogni chiamante, limita ogni permesso, registra ogni azione e non fidarti di alcun input per default.