Nel giro di dodici mesi MCP è passato da specifica aperta a strato di connessione predefinito per gli agenti AI. Anthropic ha pubblicato lo standard a novembre 2024; a dicembre 2025 contava più di 10.000 server MCP pubblici attivi, con il supporto di AWS, Google Cloud e Azure. ChatGPT, Gemini, Microsoft Copilot, Cursor e Visual Studio Code lo usano. È una velocità di adozione rara anche in un settore abituato a cicli rapidi come quello degli LLM.
Uno standard cresciuto più in fretta dei controlli
La crescita non è casuale. MCP risolve un problema reale: consente ad agenti e coding assistant di usare una sola interfaccia per collegarsi a più strumenti e fonti dati, evitando connettori su misura. Ma questa standardizzazione ha spostato il rischio. Prima la sicurezza poteva concentrarsi sul modello e sulle credenziali delle singole integrazioni; ora deve presidiare un livello intermedio che, per definizione, media tra l'agente e i sistemi esterni.
Il punto non è la rete. Le minacce descritte da OWASP mostrano che la debolezza sta nei metadati e nelle descrizioni degli strumenti. Il tool poisoning porta la prompt injection al livello successivo: le istruzioni malevole vengono inserite nelle descrizioni, negli schemi o nei valori restituiti da un tool, per manipolare il comportamento dell'agente. Gli attacchi rug pull sono ancora più insidiosi: un aggressore modifica la definizione di uno strumento dopo che una persona l'ha già approvato, sfruttando la fiducia generata da quell'approvazione. Il tool shadowing e la cross-origin escalation usano la descrizione di un server malevolo per alterare il modo in cui un agente impiega i tool di un server fidato.
I numeri citati dalla fonte rafforzano il framework: un'analisi di Lakera, società di sicurezza acquisita da Check Point nel 2025, ha esaminato 10.000 server MCP e ha rilevato debolezze sfruttabili nel 40% dei casi. Non stiamo parlando di vulnerabilità teoriche, ma di una superficie che combina codici pronti all'uso, automazione e accesso a dati sensibili.
La minaccia vive nei metadati, non nei pacchetti
Qui sta la differenza rispetto ai firewall tradizionali. Un firewall di rete vede connessioni, firme e volumi. Un tool poisoning viaggia dentro una risposta semanticamente normale: l'agente riceve un'istruzione, non un malware. L'esfiltrazione dei dati può avvenire inserendo informazioni sensibili in chiamate altrimenti legittime, come ricerche o invii di email. L'accesso sovradimensionato è un altro vettore: un server MCP con permessi più ampi del necessario aumenta la superficie esposta. In tutti questi casi, il traffico può apparire regolare.
Check Point ha presentato la sua risposta a luglio 2026 con AI Network Firewall, un prodotto che si inserisce nell'infrastruttura firewall esistente. Scopre i server MCP, ispeziona il traffico e applica policy sull'accesso degli agenti. TrueFoundry adotta un approccio diverso con AI Gateway, orientato a governance, controllo degli accessi e auditing delle interazioni tra tool e agenti. Cisco ha esteso AI Defense con guardrail per gli agenti, scansione MCP e ispezione in tempo reale del traffico MCP. Il termine "AI firewall" in realtà copre due significati: da un lato i firewall potenziati dall'AI contro minacce convenzionali, dall'altro i firewall costruiti per difendere l'AI stessa. I prodotti citati appartengono alla seconda categoria.
Il perimetro si sposta: vince chi controlla il connettore
La competizione tra fornitori non è solo una questione di funzionalità. È una lotta per definire dove va collocato il punto di controllo della fiducia: sulla rete, sull'infrastruttura dei tool o sull'agente. Chi controlla il connettore MCP controlla anche la visibilità su cosa un agente può fare davvero. Questo spiega perché Check Point punta sul firewall di rete, TrueFoundry sul gateway e Cisco sull'agente. Non sono risposte intercambiabili.
Per chi gestisce sistemi self-hosted, la posta in gioco è ancora più alta. Un server MCP locale riduce la dipendenza da servizi esterni ma crea un ponte interno verso database, file system e applicazioni. Se l'agente ottiene permessi larghi su quel server, una descrizione avvelenata può trasformare una normale operazione di ricerca in un canale di uscita per dati sensibili. In un contesto di sovranità dei dati, il problema non è solo il server pubblico: è anche la fiducia che accordiamo alle descrizioni dei tool che girano dentro il perimetro.
La sicurezza MCP, del resto, non è la stessa cosa della sicurezza degli agenti. Gli agenti possono raggiungere strumenti e dati senza passare da MCP. Proteggere i connettori serve a ridurre tool poisoning, accessi non autorizzati e perdita di dati, ma non basta. Serve una combinazione di controlli: versioni firmate e bloccate dei tool, principio del privilegio minimo, auditing delle chiamate e integrazione con lo stack di sicurezza esistente. Per chi valuta deployment on-premise, AI-RADAR offre su /llm-onpremise un framework analitico per confrontare questi trade-off.
La domanda finale non è se un firewall specializzato sia utile. È se riuscirà a vedere la minaccia prima che l'agente l'abbia già trasformata in una chiamata del tutto legittima.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!