{"id":26613,"date":"2026-09-09T14:59:09","date_gmt":"2026-09-09T12:59:09","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=26613"},"modified":"2026-09-09T14:59:09","modified_gmt":"2026-09-09T12:59:09","slug":"quando-lai-acquisisce-le-mani-sicurezza-dellmcp-in-tre-cerchi-e-dieci-rischi","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2026\/09\/09\/quando-lai-acquisisce-le-mani-sicurezza-dellmcp-in-tre-cerchi-e-dieci-rischi\/","title":{"rendered":"Quando l\u2019AI acquisisce le mani: sicurezza dell\u2019MCP in tre cerchi e dieci rischi"},"content":{"rendered":"\n

Seconda parte degli appunti di AI security. La prima \u00e8 qui (<\/em>AI security: si protegge il sistema, non il modello<\/a>) se non l\u2019hai letta, il riassunto \u00e8 una riga: l\u2019AI security \u00e8 sicurezza di sistema, non di modello, e la domanda giusta \u00e8 cosa entra, cosa decide e cosa il sistema pu\u00f2 effettivamente raggiungere.<\/em><\/p>\n\n\n\n

Quel terzo pezzo – cosa il sistema pu\u00f2 raggiungere<\/strong> – \u00e8 rimasto astratto nel primo articolo. Il Model Context Protocol \u00e8 il punto in cui smette di esserlo.<\/p>\n\n\n\n

Fino a poco tempo fa un LLM era un cervello in un barattolo: capacissimo, e senza braccia. Se volevi che leggesse i ticket Jira o interrogasse un database, l\u2019integrazione te la scrivevi a mano. MCP standardizza quel collegamento. Anthropic lo introduce a novembre 2024, entro sei mesi arrivano protocolli concorrenti da Google e Microsoft, a dicembre 2025 il progetto passa alla Linux Foundation. Oggi si contano oltre diecimila server MCP pubblici e un centinaio di milioni di download. La metafora che circola \u00e8 \u201cUSB-C per gli agenti AI\u201d: lo colleghi e funziona, senza documentazione e senza logica di integrazione.<\/p>\n\n\n\n

\u00c8 esattamente questa assenza di attrito il problema di sicurezza.<\/p>\n\n\n\n

Patient zero: una riga di codice<\/strong><\/h2>\n\n\n\n

Ho iniziato il corso con questo caso e lo ripropongo perch\u00e9 non richiede nessuna competenza tecnica per essere capito, il che \u00e8 il punto.<\/p>\n\n\n\n

Qualcuno nella community costruisce un server MCP per Postmark<\/strong>, servizio di invio email. Non \u00e8 Postmark a pubblicarlo: \u00e8 un progetto di terzi, open source, genuinamente utile – colleghi l\u2019agente e mandi email. Migliaia di installazioni, quindici release pulite. Alla versione 1.0.16 un contributore aggiunge una riga al tool di invio: un bcc:<\/em> verso un indirizzo che controlla lui.<\/p>\n\n\n\n

Tutto qui. Nessun buffer overflow, nessuna injection, nessun CVE. Il codice fa esattamente quello che dichiara di fare, usando esattamente il permesso che gli hai concesso in fase di installazione: mandare email. Ne manda solo una copia in pi\u00f9. Ogni reset password, ogni fattura, ogni memo interno.<\/p>\n\n\n\n

Due lezioni, e la seconda \u00e8 quella che conta davvero per chi lavora in un\u2019organizzazione strutturata.<\/p>\n\n\n\n

Chiunque pu\u00f2 pubblicare un server MCP per il tuo servizio.<\/strong> Se hai delle API, documentate o meno, qualcuno pu\u00f2 avvolgerle in un MCP e distribuirlo. Postmark non c\u2019entrava nulla, e aveva ragione a dirlo. Vale per la tua azienda esattamente come valeva per loro.<\/p>\n\n\n\n

Quindi si parte sempre dal vendor.<\/strong> Se cerchi un MCP per Jira, la prima fermata \u00e8 Atlassian, non il primo risultato di ricerca. La domanda non \u00e8 \u201cesiste un MCP per X\u201d – ne esistono decine – ma \u201cquesto \u00e8 quello autorevole?\u201d.<\/p>\n\n\n\n

L\u2019architettura, in breve<\/strong><\/h2>\n\n\n\n

Quattro scatole, e vale la pena averle chiare perch\u00e9 ogni rischio si colloca su una di esse.<\/p>\n\n\n\n

L\u2019host<\/strong> \u00e8 l\u2019applicazione che usi: Claude Desktop, Cursor, VS Code con Copilot. Contiene il modello e un client MCP per ogni server collegato. Il client<\/strong> \u00e8 l\u2019idraulica, non ci penserai mai. Il server MCP<\/strong> \u00e8 il ponte verso i sistemi esterni: espone i tool che l\u2019agente pu\u00f2 chiamare, ed \u00e8 dove atterra la maggior parte degli exploit. Il backend<\/strong> sono i tuoi sistemi di sempre \u2014 database, API, filesystem. Non sono cambiati. \u00c8 cambiata una sola cosa: sono diventati raggiungibili<\/em> da un agente.<\/p>\n\n\n\n

Un dettaglio che torna utile pi\u00f9 avanti: i server si collegano in due modi. STDIO<\/strong>, cio\u00e8 il server gira come sottoprocesso locale sulla tua macchina (tipico delle integrazioni desktop e IDE), oppure HTTP streamable<\/strong>, cio\u00e8 il server \u00e8 remoto e multi-tenant, su infrastruttura di qualcun altro. Chi esegue il server e dove decide di chi ti stai fidando.<\/p>\n\n\n\n

MCP non sostituisce le API, aggiunge un consumatore<\/strong><\/h2>\n\n\n\n

Questo \u00e8 il punto che mi sembra pi\u00f9 sottovalutato, e riguarda il modello di minaccia pi\u00f9 che la tecnologia.<\/p>\n\n\n\n

Alla fine della catena ci sono sempre le API. Salesforce, Postgres, Jira non parlano linguaggio naturale: vogliono richieste strutturate, come sempre. MCP non riduce la superficie API, ci aggiunge sopra un terzo tipo di consumatore<\/strong>.<\/p>\n\n\n\n

Fino a ieri le tue API avevano due categorie di chiamanti: gli umani, che cliccano un bottone alla volta, e le macchine – cron job, integrazioni, chiamate service-to-service – ad alto volume ma perfettamente prevedibili. Entrambe ben comprese.<\/p>\n\n\n\n

Ora c\u2019\u00e8 l\u2019agente. E un\u2019API \u00e8 come un martello: fa una cosa sola, in modo deterministico. Quando integri un agente non stai integrando un martello, stai integrando un carpentiere<\/strong>: un soggetto con logica propria, che sceglie se usare il martello, il cacciavite o la mazza. Per di pi\u00f9 un soggetto progettato per essere non deterministico – quella dose di casualit\u00e0 \u00e8 ci\u00f2 che gli d\u00e0 capacit\u00e0 creativa, ed \u00e8 anche ci\u00f2 che lo rende imprevedibile e capace di allucinare.<\/p>\n\n\n\n

Per la prima volta stai introducendo nelle tue applicazioni della logica che non hai scritto tu e che non \u00e8 prevedibile. E questo carpentiere fa cose che un umano non pu\u00f2 fare: nessuna persona prover\u00e0 diecimila PIN, un agente s\u00ec.<\/p>\n\n\n\n

Quattro confini di fiducia, e l\u2019identit\u00e0 che non sopravvive<\/strong><\/h2>\n\n\n\n

Il percorso di una richiesta \u00e8: l\u2019utente chiede<\/strong>, l\u2019agente decide<\/strong> quale tool usare, il client impacchetta<\/strong> la chiamata in JSON-RPC, il server esegue<\/strong>, il backend risponde<\/strong>.<\/p>\n\n\n\n

Ognuna di quelle frecce \u00e8 un confine di fiducia. A ogni salto un componente prende per buona la parola di quello precedente: l\u2019agente si fida che l\u2019utente intendesse davvero quello, il client si fida che l\u2019agente abbia deciso bene, il server si fida che la richiesta sia legittima, il backend si fida delle credenziali del server.<\/p>\n\n\n\n

E qui c\u2019\u00e8 la parte che dovrebbe far drizzare le antenne a chiunque faccia analisi. Il salto meglio autenticato \u00e8 l\u2019ultimo<\/strong>, server-backend, perch\u00e9 \u00e8 l\u00ec che vivono le chiavi API. Ma quella credenziale dice soltanto che il server<\/em> \u00e8 autorizzato a entrare. Non dice nulla su quale utente abbia chiesto cosa<\/strong>.<\/p>\n\n\n\n

L\u2019identit\u00e0 dell\u2019utente, di norma, non sopravvive al viaggio. Che tradotto in linguaggio DFIR significa: senza controlli specifici, l\u2019attribuzione di un\u2019azione a una persona \u00e8 persa a monte del punto in cui la tua telemetria di backend inizia a guardare. Sul salto intermedio, poi, i ricercatori continuano a trovare migliaia di server MCP esposti su internet con autenticazione assente.<\/p>\n\n\n\n

I tre cerchi: la trifecta letale<\/strong><\/h2>\n\n\n\n

Prima di entrare nei dieci rischi serve il modello mentale, e per fortuna esiste ed \u00e8 semplice. Lo ha formulato Simon Willison a giugno 2025 \u2014 lo stesso ricercatore che nel 2022 aveva coniato il termine prompt injection<\/em>.<\/p>\n\n\n\n

Tre condizioni:<\/p>\n\n\n\n