Il tuo MCP non è un accessorio: è un’interfaccia come le altre

Stesse operazioni, tre porte

Il principio è semplice da enunciare: tutto ciò che si fa dall’interfaccia deve potersi fare anche dall’MCP, e viceversa, con gli stessi permessi e lo stesso storico. Non come disciplina da ricordare, ma come conseguenza della struttura.

Per ottenerlo ogni operazione è definita una sola volta: un identificatore, se legge o scrive, il permesso richiesto, lo schema di ciò che accetta e di ciò che restituisce, l’evento da registrare. Un unico esecutore la fa girare, che arrivi da una pagina, da un’API o da un assistente: valida, controlla permesso e ambito, apre la transazione, scrive lo storico. I tool MCP si generano da queste definizioni e nessuno è scritto a mano: quando un’operazione cambia, cambia il tool con lei.

Cosa deve saper fare un tool, oltre a funzionare

• Separare lettura e scrittura. Strumenti distinti, con titolo e annotazioni (sola lettura, distruttivo, idempotente), così il client può trattarli in modo diverso.
• Prendere il perimetro dal collegamento, non dagli argomenti. L’organizzazione è scritta nel token al momento del consenso. Il permesso effettivo è l’intersezione tra ciò che l’applicazione ha chiesto e ciò che l’utente può fare.
• Far confermare le azioni distruttive al server. La prima chiamata non cancella: risponde con un riassunto di ciò che sta per accadere e un codice da ripassare dopo il sì della persona. Non basta che il client chieda: verifica il server.
• Restituire dati, non istruzioni. Ciò che un tool restituisce (note, nomi, descrizioni scritte da altri) viene marcato come dato. Le descrizioni dei tool sono testi fissi nel codice, mai letti dal database, per chiudere alla fonte il rischio di descrizioni manipolate.
• Spiegare gli errori. Un rifiuto arriva come risultato del tool, con la stessa frase che l’utente leggerebbe nell’interfaccia: l’agente spiega perché non può, invece di riprovare alla cieca.
• Lasciare traccia di ogni chiamata. Anche delle letture e dei rifiuti, con l’interfaccia (MCP) e il client usato.

Il caso che nessun filtro copre: leggere, poi scrivere

Un agente legge un record scritto da qualcun altro, ragiona e poi scrive. Se in quel testo c’era un’istruzione nascosta, una prompt injection, la scrittura è il momento in cui il danno diventa reale. Non esiste un filtro affidabile che riconosca le istruzioni dentro un testo. Ciò che un server può fare è meno ambizioso e più onesto: dopo aver restituito righe scritte da altri, chiede conferma per le scritture successive per un tempo limitato (nel nostro caso dieci minuti).

Va detto dove finisce questa difesa: chiede conferma anche per scritture del tutto legittime, non sa se la scrittura è davvero causata da ciò che è stato letto, non copre il testo iniettato nei dati dell’utente stesso. Il costo è una conferma in più. Meglio dichiararlo che far credere che il problema sia risolto.

Un dettaglio che ci ha insegnato qualcosa

Durante le prove con un client reale, un assistente collegato in sola lettura ha suggerito all’utente di scrivere “dal pannello di amministrazione o direttamente sul codice del progetto”. Aveva ragione sul piano tecnico e torto su quello del progetto: l’MCP è una porta come le altre, e ciò che i suoi strumenti non permettono non si fa altrove. Oggi le istruzioni del server lo dicono esplicitamente, e spiegano come ricollegare l’applicazione con i diritti giusti.

Perché conviene farlo dall’inizio

Aggiungere l’MCP dopo la prima versione significa rivedere permessi, storico e definizione delle operazioni già scritti. E aprirlo anche agli utenti esterni alza il livello richiesto a tutto il resto: è il rischio dell’incidente raccontato in questo altro pezzo. Una dichiarazione di parte: è il modo in cui costruiamo i nostri sistemi, e il tema è quello degli agenti AI e del middleware.