Non fa notizia quanto i modelli linguistici. Non genera hype quanto le demo di nuove funzionalità. Ma il Model Context Protocol — e gli standard simili che stanno emergendo nel 2026 — potrebbe essere la scelta infrastrutturale più importante che un team di sviluppo fa quest’anno.
Il motivo è semplice: quando un agente inizia a “fare cose”, il collo di bottiglia non è più il modello. È l’integrazione.
Il problema che MCP risolve
Immagina di dover connettere un LLM a dieci strumenti diversi: un repository Git, un’API aziendale, un database, un sistema di ticketing, una casella email. Senza uno standard, ogni connessione è un progetto a sé: prompt personalizzati, wrapper specifici, permessi improvvisati. Scala male, si rompe spesso, ed è impossibile da governare.
MCP risponde a questo con un’idea semplice ma potente: definisci un protocollo per descrivere capacità, input/output, policy e contesto. L’agente scopre gli strumenti in modo standardizzato, li chiama, riceve risposte tipate, e ogni operazione può essere osservata. In teoria, è la differenza tra una demo e una piattaforma.
La standardizzazione porta con sé nuovi rischi
In pratica, però, c’è un rovescio della medaglia che vale la pena guardare in faccia: standardizzare le integrazioni significa standardizzare anche la superficie d’attacco.
Se un agente può leggere una repository, aprire issue, eseguire comandi o consultare email tramite un connettore, allora una prompt injection non è più un trucco da conferenza: è un vettore di attacco operativo. Nel 2025–2026 abbiamo già documentazione di casi in cui contenuti “innocenti” — una pagina web, un documento, un’issue GitHub — hanno manipolato agenti per attivare tool o esfiltrare dati.
Il problema non è MCP in sé. È usarlo come se fosse un plug-in invece di trattarlo come infrastruttura critica.
Le regole che separano un’integrazione da un incidente
Queste non sono novità concettuali. Sono pratiche consolidate di security engineering applicate agli agenti, e sono tutte necessarie:
Privilegi minimi. Ogni server MCP deve avere scope ristretto: read-only di default, write solo quando esplicitamente richiesto, mai accesso al filesystem senza sandbox.
Separazione delle identità. Un agente che opera su Git non dovrebbe avere automaticamente le credenziali del tuo account cloud.
Allowlist per le azioni. Non basta “chiedere al modello di stare attento”. Serve un layer separato che blocchi comandi e chiamate fuori policy.
Conferme esplicite per azioni ad alto impatto: deploy, cancellazioni, pagamenti, invio di email verso l’esterno.
Classificazione delle fonti. Se il tool legge dal web o da documenti esterni, quel contenuto è “non fidato” finché non passa un filtro. Non può diventare un’istruzione operativa.
Audit trail. Ogni tool call deve essere tracciata: chi, quando, perché, cosa è stato letto e cosa è stato scritto.
Il vero vantaggio strategico
Al di là della sicurezza, c’è un argomento business che vale la pena considerare. Chi investe oggi nella standardizzazione delle integrazioni sta costruendo un layer di indipendenza: la possibilità di cambiare modello domani senza riscrivere tutto, di evitare il lock-in totale su un singolo provider, di costruire un catalogo di capability riusabili su progetti diversi.
È un investimento poco appariscente. Ma è quello che permette di scalare l’agentic AI senza trasformare ogni progetto in un prototipo fragile.