Un agente AI che legge gli ordini dal gestionale e aggiorna da solo le schede clienti nel CRM fa risparmiare ore di copia e incolla ogni settimana. Lo stesso agente, configurato male, può leggere dati che non gli competono e scrivere dove non deve, magari su indicazione di un testo trovato in un'email. Il collegamento tra modello e sistemi aziendali passa sempre più spesso dal Model Context Protocol, e da lì passano anche i rischi.
Ad aprile 2026 il CERT-AgID ha pubblicato un'analisi di sicurezza su implementazioni MCP open source, ripresa da Agenda Digitale. Lo studio è una buona base per chi valuta un progetto di questo tipo, anche se copre una parte del problema: altri rischi rilevanti emergono da casi reali documentati altrove.
Cos'è il Model Context Protocol, con un esempio da ERP a CRM
MCP è uno standard aperto che definisce come un assistente AI si collega ai sistemi in cui stanno i dati: archivi di documenti, strumenti aziendali, ambienti di sviluppo. L'ha introdotto Anthropic nel novembre 2024, con specifica, SDK e una raccolta di server open source. Dal 9 dicembre 2025 è gestito dall'Agentic AI Foundation, nata nell'organizzazione che cura lo sviluppo di Linux insieme a goose di Block e AGENTS.md di OpenAI.
Il funzionamento è abbastanza semplice: il modello linguistico ragiona e decide; il client MCP, cioè l'applicazione che ospita l'agente, gli presenta gli strumenti disponibili.
Ogni server MCP espone uno o più tool, funzioni con un nome, una descrizione e dei parametri, che chiamano a loro volta le API del sistema vero.
Prendiamo uno scenario illustrativo. Un server MCP agganciato all'ERP mette a disposizione il tool leggi_ordini_del_giorno, un secondo, connesso al CRM, offre aggiorna_scheda_cliente. Ogni sera l'agente legge gli ordini, individua i clienti che hanno superato una soglia di fatturato, aggiunge una nota per il commerciale e cambia lo stato dell'opportunità. Nessuno scrive un'integrazione dedicata tra i due sistemi: è l'agente a scegliere i tool da chiamare e i parametri da passare.
Questa flessibilità è anche il problema. I parametri li genera il modello al momento, sulla base di quello che ha letto, e non un programmatore in fase di sviluppo.
Il paper di CERT-AgID lo descrive come uno spostamento del perimetro di sicurezza sulla catena prompt → tool → azione.
Cosa ha trovato il CERT-AgID nei server MCP open source
Il paper, 17 pagine, si concentra sulla SSRF (Server-Side Request Forgery), la possibilità di far partire da una macchina interna richieste di rete verso destinazioni scelte da chi attacca. Lo scenario è concreto. Un server MCP pensato per scaricare documentazione da fonti remote riceve l'URL come parametro e lo usa senza controlli. Se il modello gli passa un host interno, quel componente diventa un proxy non autorizzato dentro la rete aziendale.
La prompt injection compare come vettore: un modello manipolato da un comando malevolo genera l'URL pericoloso. Da qui la conclusione dello studio, che chiede di trattare ogni input prodotto dall'AI come intrinsecamente ostile.
Accanto alla SSRF, l'analisi segnala debolezze ricorrenti in molti progetti MCP:
- tool richiamabili senza autenticazione;
- allowlist scritte in modo da lasciare passare richieste che dovrebbero bloccare;
- connessioni esterne senza controlli TLS, con dati esposti a intercettazione;
- nessun limite al numero di richieste, quindi esposizione ad attacchi DoS.
Le raccomandazioni seguono di conseguenza. Ogni parametro va verificato prima dell'esecuzione con filtri bloccanti, senza meccanismi di riserva che li aggirino, e le allowlist vanno limitate a domini, protocolli e formati predefiniti. Lo studio chiede poi di assegnare a ogni tool una sola operazione, rendere obbligatoria l'autenticazione, applicare il rate limiting e registrare le chiamate per scoprire anomalie in tempo reale.
Gli altri rischi: dati esterni, server di terze parti, esfiltrazione
Lo studio guarda soprattutto al singolo server. Quando un agente lavora su ERP e CRM, parecchi problemi arrivano da fuori.
Il primo è la prompt injection indiretta. L'agente legge contenuti che nessuno controlla a monte: la nota di un ordine, un'email, un PDF allegato. Invariant Labs l'ha mostrato con il server MCP ufficiale di GitHub: una issue scritta ad arte ha spinto un agente a rivelare informazioni private. Il server non aveva bug, è bastato il contenuto letto. Nel nostro scenario l'equivalente sarebbe una nota d'ordine che chiede all'agente di inviare l'elenco clienti a un indirizzo esterno.
Poi ci sono i server di terze parti installati senza verifiche. A settembre 2025 è emerso postmark-mcp, un pacchetto npm che si spacciava per l'integrazione di un noto servizio di invio posta: dalla versione 1.0.16, pubblicata il 17 settembre, copiava di nascosto i messaggi che passavano dal tool. Secondo The Hacker News era stato scaricato 1.643 volte, e l'azienda ha chiarito di non avere alcun legame con il pacchetto.
L'esfiltrazione, spesso, nasce dalla somma di questi due fattori con permessi troppo larghi. Credenziali da amministratore sul CRM, un tool che può contattare qualsiasi dominio e un testo malevolo letto al momento sbagliato: i dati escono senza che nessuno abbia violato una password. L'OWASP Top 10 for Agentic Applications 2026 dà un nome a questi scenari, tra cui dirottamento degli obiettivi (ASI01), uso improprio dei tool (ASI02), abuso di identità e privilegi (ASI03), catena di fornitura (ASI04) e avvelenamento di memoria e contesto (ASI06).
I controlli da prevedere in un progetto
Permessi minimi per ogni tool
Ogni tool fa una cosa sola, con le credenziali strettamente necessarie. Nell'esempio, leggi_ordini_del_giorno usa un utente ERP in sola lettura limitato agli ordini; aggiorna_scheda_cliente scrive note e cambia lo stato dell'opportunità, senza poter cancellare contatti o esportare liste. Se serve un'operazione nuova si crea un tool nuovo con il suo perimetro, invece di allargare quello esistente. I parametri si validano lato server: un ID cliente deve avere il formato di un ID cliente, un dominio deve stare nell'allowlist.
Conferma umana sulle azioni irreversibili
L'analisi dell'agenzia non ne parla, ma per noi è una regola di progetto. Cancellare un record, emettere una nota di credito, scrivere a un cliente, modificare un prezzo: l'agente prepara l'azione, la mostra con i dati che userà e una persona approva. Le operazioni reversibili e a basso impatto, come aggiungere una nota, possono girare in autonomia.
Ambienti separati
Sviluppo e test si fanno su copie di ERP e CRM con dati anonimizzati o sintetici e credenziali diverse da quelle di produzione. Nei prototipi capita di collegarsi subito al sistema vero perché è più rapido, ed è proprio lì che un errore di configurazione diventa un incidente.
Log, monitoraggio e alert
Ogni chiamata dell'agente va registrata: il tool usato, i parametri, l'utente o il processo per cui agisce, l'esito. Questi log servono a ricostruire un incidente e ad accorgersene mentre succede. In produzione il monitoraggio degli agenti AI si regge su segnali semplici, come picchi di chiamate, tool usati fuori orario, richieste verso domini non previsti ed errori di autorizzazione ripetuti. Il rate limiting fa da freno quando qualcosa va storto.
Checklist in 10 punti prima di collegare un agente a ERP e CRM
- Esiste un inventario dei server MCP in uso, con origine, versione e responsabile.
- I server di terze parti vengono verificati (codice, editore, versione bloccata) prima dell'installazione e a ogni aggiornamento.
- Ogni tool esegue una sola operazione con credenziali dedicate e permessi minimi.
- Tutti i tool richiedono autenticazione, anche quelli interni.
- I parametri generati dal modello sono validati lato server con filtri bloccanti.
- Le richieste in uscita passano da allowlist di domini, protocolli e formati, con TLS verificato.
- Email, note e documenti esterni sono trattati come dati non affidabili e non attivano da soli azioni sensibili.
- Le azioni irreversibili richiedono la conferma di una persona.
- Sviluppo, test e produzione hanno ambienti e credenziali separati.
- Ogni chiamata è registrata, con rate limiting e alert attivi sulle anomalie.
Come gestiamo la sicurezza dal prototipo alla produzione
Nei nostri progetti di automazione con agenti la sicurezza entra nel piano insieme alla scelta del processo. Se stai ancora decidendo da dove partire, la checklist su quale processo automatizzare prima con l'AI aiuta a valutare anche il rischio: un flusso che legge e propone è più semplice da proteggere di uno che scrive e invia.
Il prototipo, pronto in 2-4 settimane, lavora sui dati reali del cliente ma in un ambiente separato, con credenziali in sola lettura dove possibile. In quella fase fissiamo l'elenco dei tool, i permessi di ciascuno e le azioni da confermare. Il passaggio in produzione aggiunge autenticazione sui server, log centralizzati e alert. Durante il presidio rivediamo i log, aggiorniamo i server MCP in modo controllato e riesaminiamo i permessi ogni volta che all'agente si affidano compiti nuovi.
Per la sicurezza del codice scritto con l'AI, un tema diverso dagli agenti in produzione, trovi un approfondimento su come integrare l'AI nei flussi di sviluppo senza compromettere qualità e sicurezza. Se invece hai già in mente un agente da collegare al gestionale o al CRM, con l'analisi AI gratuita capiamo insieme che dati tocca, di che tool ha bisogno e dove mettere i controlli prima di scrivere codice.
.jpeg)
