Model Context Protocol (MCP): come colleghi un agente IA ai tuoi dati senza aprire falle

Ti hanno detto che l’agente IA “si collega ai tuoi dati”. Ok, ma come? E soprattutto: chi decide cosa quell’agente può leggere, cosa può modificare, e chi risponde se legge qualcosa che non doveva?

Il Model Context Protocol (MCP) è lo standard emergente che risponde a queste domande. Te lo spiego senza gergo, perché è una decisione di architettura e di sicurezza, non un dettaglio da lasciare “agli sviluppatori”.

In breve:

• MCP è uno standard aperto che definisce come un agente IA accede ai tuoi sistemi (CRM, ERP, database, file), sostituendo integrazioni ad hoc con una “presa” comune.
• Non è né sicuro né insicuro di suo: sposta la sicurezza in un punto centrale dove decidi permessi, scope e audit una volta sola invece che dieci.
• Conviene quando hai più agenti sugli stessi dati o più sistemi collegati allo stesso agente. Per 1-2 integrazioni semplici, un connettore diretto costa meno.
• La falla non è mai il protocollo: è esporre troppo (accesso in scrittura dove serviva solo lettura, nessun log, credenziali larghe).
• Fatto bene, un server MCP dà meno superficie d’attacco e rende più semplice dimostrare compliance GDPR e AI Act.

Cos’è MCP, senza gergo

Immagina che ogni tuo sistema (il gestionale, il CRM, la cartella delle fatture) abbia una porta. Finora, per far entrare un agente IA, si costruiva una chiave su misura per ogni porta: un pezzo di codice diverso per TeamSystem, uno per il CRM, uno per il file server. Dieci porte, dieci chiavi, dieci punti che si possono rompere o essere forzati.

MCP dice: mettiamo una serratura standard su tutte le porte. L’agente parla un solo linguaggio; ogni sistema espone un piccolo “server MCP” che dichiara due cose: quali dati l’agente può leggere e quali azioni può eseguire. Niente di più.

È un protocollo aperto, quindi non ti leghi a un singolo fornitore di IA. Lo stesso server MCP che oggi usi con un agente Soraia domani funziona con un altro modello o un altro agente.

Perché conta per la tua azienda

Tre motivi concreti, in ordine di importanza.

1. Riduci la superficie d’attacco. Dieci integrazioni scritte a mano significano dieci posti dove qualcuno ha copiato una credenziale in un file, ha dato più permessi del necessario, ha dimenticato di loggare. Un server MCP centralizza autenticazione, scope e logging. Un punto solo da presidiare, non dieci.

2. Scali senza riscrivere. Il secondo agente che vuoi costruire (magari sul finance dopo quello sul recruitment) riusa gli stessi server MCP. Non ripaghi l’integrazione da zero.

3. Rendi la compliance dimostrabile. GDPR chiede minimizzazione dei dati e tracciabilità; l’AI Act, in vigore da agosto 2026, chiede di sapere come un sistema è arrivato a un output. Con gli accessi centralizzati in MCP, applicare questi principi diventa una configurazione, non un’archeologia su dieci codebase diverse.

Come si collega un agente ai dati senza aprire falle

La falla non è mai MCP in sé. È esporre troppo. Ecco i quattro principi che applichiamo in ogni sprint agenti IA.

1. Least privilege, sempre

L’agente riceve i permessi minimi per il suo task. Se deve leggere fatture per generare un report, ha accesso in sola lettura alla cartella fatture. Punto. Nessun accesso in scrittura, nessun accesso ad altre cartelle. Ogni permesso in più è una falla in più.

2. Scope esplicito, non “tutto il database”

Un server MCP mal fatto espone l’intero gestionale e lascia decidere all’agente. Un server fatto bene espone solo le entità e i campi che servono: “le fatture degli ultimi 90 giorni”, non “la tabella clienti completa con IBAN e dati sensibili”. Lo scope si definisce a monte, in fase di scoping.

3. Audit log immutabile su ogni chiamata

Ogni volta che l’agente legge o scrive via MCP, resta traccia: cosa ha chiesto, cosa ha ricevuto, quando. È lo stesso audit log immutabile che includiamo di default e che ti serve per rispondere a un revisore o a un cliente sul “perché l’IA ha fatto X”.

4. Umano nel loop sulle azioni che contano

Lettura via MCP: l’agente procede da solo. Scrittura che impatta qualcosa (inviare, approvare, modificare un record contabile): passa a un umano o resta sotto soglia definita. Come facciamo negli agenti finance, dove l’agente estrae e riconcilia ma l’umano valida le anomalie.

Quando NON serve MCP

Te lo dico chiaro, perché non vendiamo complessità dove non serve.

• Agente con 1-2 integrazioni semplici e stabili → un connettore diretto va benissimo e costa meno. MCP sarebbe over-engineering.
• Sistemi che non cambieranno → se colleghi un solo sistema che non tocchi da anni, lo standard aggiunge un layer che non ti ripaga.
• Nessuna intenzione di scalare a più agenti → il valore di MCP è nel riuso. Un agente solo, per sempre, non lo giustifica.

MCP conviene quando prevedi più agenti sugli stessi dati o più sistemi collegati. È esattamente il caso di chi parte da un agente e nei 12 mesi successivi ne aggiunge altri due o tre. Se sei in questo scenario, l’architettura giusta oggi ti fa risparmiare mesi domani, ed è il tipo di decisione che valutiamo in fase di scoping insieme allo sviluppo custom.

Il punto

MCP non è magia e non è un obbligo. È una serratura standard che, usata bene, ti dà meno falle e più capacità di scalare. Usata male (accesso largo, nessun log), è pericolosa quanto qualsiasi integrazione fatta di fretta. La differenza la fa chi definisce lo scope, non il protocollo.

Vuoi capire se ha senso per il tuo caso? Parliamone in 20 minuti, oppure inizia dal check-up di 3 minuti.