Il tuo server MCP è sicuro. Il registro contabile che c’è dietro, invece, no.

In un recente articolo pubblicato qui su Unite.AI, Gil Feig ha illustrato sei buone pratiche per realizzare un server MCP sicuro. Sono valide e chiunque distribuisca un server MCP dovrebbe seguirle. Il suo consiglio di assegnare a ogni integrazione «un ruolo specifico e granulare, limitato rigorosamente alle autorizzazioni necessarie» è del tutto corretto. Presuppone, però, che anche il sistema dall’altra parte disponga di ruoli granulari. E questo rimanda a un presupposto più ampio, raramente esplicitato: che i sistemi dietro al server possano essere protetti allo stesso livello.

Nel software aziendale, spesso non è così. Dirigo il team di ingegneria che sviluppa un livello di integrazione in grado di connettersi a 32 sistemi contabili ed ERP, con un server MCP opzionale. Ci capita spesso di vedere agenti ben autenticati, con autorizzazioni ben circoscritte e registrati correttamente dal nostro lato, che scrivono in sistemi incapaci persino di rilevare il coinvolgimento di un agente.

Questo articolo affronta la seconda metà del problema: cosa offrono davvero i sistemi a monte, cosa si può controllare dal livello di integrazione e dove finisce tale controllo.

Dove la specifica MCP cede il controllo

La specifica di autorizzazione MCP definisce chiaramente i propri confini. Il server MCP è un server di risorse OAuth per i propri client. Quando chiama un’API a monte, agisce come un client OAuth distinto, con un token separato rilasciato dal sistema a monte. È esplicitamente vietato inoltrare il token del client.

È la scelta progettuale corretta. Significa anche che tutto ciò che riguarda la chiamata al sistema a monte, compreso chi può fare cosa e come viene registrato, dipende interamente da quel sistema. La specifica non può correggere ciò che il sistema a monte non offre.

Lo stesso vale per le indicazioni OWASP sull’eccessiva autonomia degli agenti. Raccomandano di limitare al minimo necessario le autorizzazioni che le estensioni di un agente possiedono negli altri sistemi e di eseguire le azioni nel contesto dell’utente per conto del quale agiscono. Sono entrambi buoni consigli. Entrambi presuppongono che l’altro sistema abbia un modo per esprimere le autorizzazioni minime e il contesto dell’utente.

Cosa offrono davvero i sistemi a monte

Ecco come appaiono, dal punto di vista di chi realizza integrazioni, i 32 sistemi contabili ed ERP a cui ci colleghiamo.

Un terzo non dispone affatto di OAuth

21 dei 32 usano OAuth. Gli altri 11 si basano su credenziali statiche: chiavi API, nome utente e password oppure una coppia di token. Alcune di queste chiavi non scadono mai. Un sistema molto diffuso dichiara nella propria documentazione che i suoi token API hanno una durata illimitata, finché l’utente esiste.

Lunga durata, poche possibilità di revoca

OAuth è meno efficace di quanto si potrebbe sperare. Un provider rilascia token di aggiornamento con una durata di circa 20 anni. È una credenziale progettata per durare più dell’agente che la usa, del framework con cui è stato creato e, molto probabilmente, della persona che ha cliccato su «Consenti». In un altro sistema, non scadono nemmeno i token di accesso.

E una volta rilasciata una credenziale, la domanda è: chi può disattivarla? Lo standard in materia, la revoca dei token OAuth (RFC 7009), esiste dal 2013. Eppure, in circa quattro sistemi su dieci, chi realizza l’integrazione non ha alcun mezzo tecnico per revocare le credenziali. Tutti i sistemi basati su chiavi API rientrano in questo gruppo. L’unica possibilità rimasta è chiedere al cliente di revocare manualmente l’accesso.

Ambiti di autorizzazione generici, nessuna identità dell’agente

La maggior parte delle chiavi statiche eredita semplicemente tutti i diritti dell’utente che le ha create; solo pochi sistemi consentono di limitarle a singoli endpoint. Molti sistemi OAuth prevedono ambiti di autorizzazione, ma tendono a essere generici, per esempio «contabilità, lettura e scrittura». E in nessuno dei 32 sistemi siamo riusciti a trovare un modo per registrare tramite API, nella stessa transazione, sia l’agente sia la persona per conto della quale agisce. Gli agenti esterni risultano quindi come l’utente che li ha collegati oppure come utenti di sistema generici. È significativo che, quando un fornitore integra agenti nel proprio prodotto, come ha fatto Microsoft in Business Central, assegni loro account utente dedicati. È lo stesso modello che raccomando più avanti, riservato però agli agenti del fornitore.

Cosa può far rispettare il livello di integrazione

Questo non significa che ci si debba arrendere. Tra l’agente e il sistema contabile, si ha il controllo di quasi tutto:

• credenziali distinte per ogni agente sul proprio livello
• ambiti di autorizzazione propri, per esempio accesso in sola lettura alle fatture
• un registro di controllo di ogni chiamata dell’agente, con l’indicazione della persona per conto della quale ha agito
• chiavi di idempotenza, affinché un agente che riprova non contabilizzi due volte la stessa fattura
• limiti di frequenza per ogni agente
• passaggi di approvazione prima di qualsiasi scrittura

Nessuna di queste misure dipende da ciò che supporta il sistema di destinazione. Oggi è possibile realizzare un livello di controllo degli accessi efficace nel livello di integrazione e, se si impiegano agenti in prossimità di dati finanziari, è opportuno crearne uno.

Dove si ferma

Ciò che non si può fare è estendere questo livello oltre i confini del sistema. A quel punto si verificano tre problemi.

Attribuzione

Nel sistema contabile, l’operazione di scrittura dell’agente risulta attribuita a chi ha autorizzato la connessione oppure a un utente tecnico. Chiunque verifichi il sistema vede una registrazione effettuata da quell’utente. Non può stabilire se a effettuarla sia stata una persona o un agente. Per il libro mastro, un agente che registra 400 fatture alle 3 del mattino è indistinguibile da un responsabile finanziario particolarmente diligente. Per ricostruire l’accaduto servono i log dell’integratore, che appartengono a una catena di fiducia diversa da quella del sistema di registrazione. In caso di indagine forense o di audit, è una posizione debole.

La maggior parte delle organizzazioni non è più avanti su questo fronte. In un sondaggio della Cloud Security Alliance, solo il 28% degli intervistati ha dichiarato di poter tracciare in modo affidabile le azioni degli agenti riconducendole a una persona o a un sistema in tutti gli ambienti, e il 44% usa o prevede di usare chiavi API statiche per i propri agenti.

Principio del privilegio minimo

Si può imporre che un agente legga soltanto le fatture. Ma se il sistema di destinazione non prevede ambiti di autorizzazione, le credenziali usate dal livello intermedio mantengono l’accesso completo. Chiunque riesca a ottenerle può aggirare del tutto il livello intermedio e tutte le regole definite al suo interno.

Revoca

È possibile disattivare immediatamente il proprio agente. Questo non serve a molto se le credenziali del sistema di destinazione stesso sono state compromesse. E, per i quattro sistemi su dieci che non dispongono di un endpoint di revoca, l’interruttore di emergenza è un’email al cliente.

La risposta pragmatica: un utente dedicato per l’agente

La cosa più utile che si possa fare oggi è poco appariscente: creare un utente dedicato all’agente nel sistema di destinazione e collegare l’agente usando esclusivamente quell’utente.

Funziona con tutti i sistemi che consentono di creare utenti e offre tre vantaggi che il livello di integrazione non può garantire:

• Attribuzione nel sistema di registrazione. Le registrazioni risultano effettuate dall’«agente AP», non dal responsabile finanziario che ha cliccato su «connetti» sei mesi fa.
• Una modalità di revoca, anche in assenza di un’API dedicata. Il cliente può disattivare l’utente dall’interfaccia, anche nei sistemi che non offrono un endpoint di revoca.
• Un’applicazione parziale del principio del privilegio minimo. Se il sistema prevede un qualsiasi modello di ruoli, spesso è possibile limitare l’utente dell’agente ai soli moduli di cui ha effettivamente bisogno.

I costi sono reali. Durante la configurazione iniziale, qualcuno deve creare l’utente manualmente, aggiungendo un passaggio proprio nel momento meno opportuno. Circa la metà dei sistemi addebita ogni utente aggiuntivo, da pochi euro al mese per gli strumenti destinati alle piccole imprese a oltre cento euro per un ERP completo. Diversi altri limitano il numero di utenti in base al piano, perciò aggiungerne uno può comportare un piano più costoso per l’intera azienda. Inoltre, un utente di servizio senza un responsabile diventa un rischio a sé stante e contribuisce alla proliferazione delle identità non umane di cui Unite.AI ha già parlato. Come qualsiasi altro account, deve avere un responsabile e una data di revisione.

Questo non risolve neppure il problema degli ambiti di autorizzazione nei sistemi che ne sono sprovvisti. Riporta però attribuzione e revoca nel sistema che gli auditor consultano davvero.

La risposta strutturale: identità delegata

La soluzione corretta esiste già, almeno sulla carta. Lo scambio di token OAuth 2.0 (RFC 8693) distingue l’impersonificazione dalla delega. Con la delega, l’agente conserva la propria identità e il token registra, tramite l’attributo «act», che agisce per conto di una persona.

Applicato alla contabilità, questo significherebbe che:

• il libro mastro registra che questo agente ha effettuato la registrazione per conto di questa persona
• gli ambiti di autorizzazione vengono concessi per singola delega, non per utente
• è possibile revocare una singola delega senza intervenire sull’account della persona

Per quanto sono riuscito a verificare, nessuno dei 32 sistemi supporta qualcosa del genere. Per ora, quindi, resta un obiettivo, non un’opzione disponibile. La richiesta va rivolta ai fornitori di software contabili ed ERP, non agli integratori: gli agenti stanno già scrivendo nei vostri libri mastri e le vostre API dovrebbero poterlo indicare.

Cosa fare prima che un agente acceda a un libro mastro

Se state collegando agenti a sistemi contabili o ERP, ecco una breve lista di controllo:

1. Analizzate il modello delle credenziali di ciascun sistema di destinazione. Usa OAuth o una chiave statica? Quanto dura la credenziale? Prevede ambiti di autorizzazione? È possibile revocarla?
2. Realizzate comunque il vostro livello di controllo degli accessi. Identità per agente, ambiti di autorizzazione, idempotenza e approvazioni devono essere gestiti da voi, indipendentemente da ciò che offre il sistema di destinazione.
3. Usate un utente dedicato per l’agente ogni volta che il sistema lo consente. Considerate l’impegno richiesto per la configurazione iniziale e il costo della licenza come il prezzo da pagare per garantire l’attribuzione.
4. Fate in modo che il vostro registro di audit sia a prova di manomissione. Per molti sistemi sarà l’unica prova del coinvolgimento di un agente.
5. Metti per iscritto il rischio residuo. Se un sistema non prevede ambiti di autorizzazione né revoca, dichiaralo al cliente e annotalo nel tuo registro dei rischi.

Il confine è ciò che conta

Proteggere il tuo server MCP è necessario, ma non sufficiente. La sicurezza di un agente che scrive in un registro si decide al confine tra il tuo livello e il sistema di riferimento, e oggi quel confine è determinato dai sistemi, non da te.

La buona notizia è che la lacuna è ben definita. Gli standard esistono. Ciò che manca è il supporto a questi standard nei sistemi che tengono i registri contabili.