Come definire le regole di accesso per agenti IA nel back-office telco

Un agente prepara note di credito per i clienti colpiti da un disservizio in una valle. Il suo prompt dice: non accreditare mai più di un canone mensile, e solo ai clienti collegati al nodo di accesso interessato. Quasi sempre funziona. Poi un cliente inoltra all'assistenza un lungo scambio di email, e da qualche parte c'è una frase che il modello tratta come un'istruzione. Oppure l'elenco dei clienti colpiti proviene da un ticket che qualcuno ha modificato a mano. In entrambi i casi il prompt era l'unico limite a ciò che l'agente ha inviato alla fatturazione.

Le regole di accesso per gli agenti devono essere fatte rispettare dai sistemi che conservano i dati ed eseguono le azioni. Questo articolo illustra sei regole per farlo nel back-office di un operatore telco, ciascuna con un esempio dall'operatività quotidiana, e spiega dove aiuta la specifica di autorizzazione di MCP.

Perché un'istruzione al modello non è un controllo

Un modello linguistico segue le istruzioni con alta probabilità, e il testo che legge mentre lavora fa parte del suo input. L'email di un cliente, un commento in un ticket o una nota in una scheda del CRM possono cambiare ciò che fa subito dopo. Per questo un prompt è un buon posto per descrivere un compito e un posto debole per imporre un limite.

Un controllo è qualcosa che regge anche quando il modello sbaglia. Il sistema di fatturazione rifiuta una nota di credito oltre il limite. Il sistema degli ordini respinge una disdetta proveniente da un'identità che non ha il diritto di disdire. Il log registra il tentativo in ogni caso.

La specifica MCP attribuisce questo compito al lato server: i server che espongono tools devono validare gli input, implementare controlli di accesso e limitare la frequenza delle chiamate (specifica MCP, Tools). Il Work Trend Index 2026 di Microsoft fa un'osservazione simile per le organizzazioni nel loro insieme e chiede all'IT di gestire gli agenti con «identities, permissions, policy enforcement, and lifecycle management» (Microsoft, 2026).

Verificare identità, ruolo e permessi a ogni accesso

Ogni richiesta di un agente porta con sé un'identità propria, separata da quella della persona che lo ha avviato, e il sistema verifica ruolo e permessi a ogni richiesta. Il controllo avviene a ogni richiesta perché un agente può restare in esecuzione per ore, e nel frattempo i suoi diritti possono cambiare.

Ogni agente ha inoltre una persona designata che ne è responsabile, ne verifica i risultati e ne corregge gli errori.

Esempio: una portabilità in uscita. Arriva una richiesta di trasferire il numero di un cliente a un altro operatore. Un agente può leggere il cliente, i servizi attivi e le fatture aperte per verificare che la richiesta corrisponda al contratto. Quando chiede di creare la fattura finale, il sistema di fatturazione verifica di nuovo l'identità e il ruolo dell'agente per quell'azione specifica, e rifiuta se il ruolo copre solo la lettura.

Separare i dati dei clienti

Gli agenti vedono i clienti per cui lavorano, e nient'altro. Per un operatore che vende tramite rivenditori o gestisce più marchi, questa separazione deve esistere nel modello dati e in ogni query, così che un filtro nelle istruzioni dell'agente non sia mai l'unica barriera.

Esempio: l'agente di un rivenditore. Un rivenditore vende la vostra fibra con il proprio marchio e vuole un proprio agente per controllare lo stato degli ordini dei suoi clienti. L'identità dell'agente appartiene a quel rivenditore, e ogni query restituisce solo i clienti di quel rivenditore. Se l'agente chiede un numero d'ordine che appartiene a un altro rivenditore, la risposta è la stessa che riceverebbe per un numero inesistente.

Dare a ogni agente solo i diritti di cui ha bisogno

I diritti seguono il compito. Un agente che prepara un elenco di traslochi legge gli ordini e i riscontri tecnici. Un agente che redige lettere di sollecito legge fatture e pagamenti. Nessuno dei due può modificare una tariffa.

La specifica di autorizzazione di MCP chiede ai client di richiedere solo gli scope di cui hanno bisogno, e consente al server di rispondere a una richiesta con diritti insufficienti con 403 Forbidden e un errore insufficient_scope che indica gli scope necessari (specifica MCP, Authorization). La guida di sicurezza di MCP elenca tra gli errori comuni gli scope jolly e il fare affidamento sugli scope di un token senza una logica di autorizzazione sul server (MCP Security Best Practices).

Esempio: una migrazione tariffaria in blocco. Dismettete una vecchia tariffa DSL e spostate i suoi clienti su una tariffa in fibra o su una tariffa sostitutiva. L'agente di migrazione può leggere i contratti di quella tariffa e creare ordini di modifica esattamente per quel segmento. Non può disdire contratti, emettere accrediti o toccare clienti con altre tariffe, anche se il caso di un cliente sembra richiedere una di queste azioni.

Approvare esplicitamente disdette e accrediti

Alcune azioni pongono fine a un servizio o muovono denaro. Per queste, l'agente prepara il caso e il sistema lo trattiene finché una persona designata non lo approva. L'approvazione è un passaggio separato con un permesso proprio, registrato con il nome della persona che l'ha data.

Esempio: una nota di credito. Dopo il disservizio, l'agente redige le note di credito per i clienti colpiti e allega le prove: nodo di accesso, finestra del disservizio, canone mensile. Le note restano nella fatturazione con lo stato «in attesa di approvazione». Qualcuno della fatturazione esamina il lotto, lo approva oppure rimanda indietro singole note. Il ruolo dell'agente non ha il permesso di approvare, quindi nessuna formulazione in un prompt può indurlo ad approvare.

Lo stesso vale per disdette e portabilità in uscita. L'agente può verificare i dati, preparare la fattura finale ed elencare ciò che non è chiaro. Il passaggio che pone fine al servizio lo compie una persona.

Tenere un registro di audit di quale agente ha fatto che cosa e quando

Il registro risponde alle domande che vi verranno poste mesi dopo. Per ogni azione registra l'agente, la persona che ne è responsabile, per conto di chi ha agito, l'operazione, i record che ha toccato, i valori prima e dopo, l'ora e, se era necessaria un'approvazione, chi l'ha data. Anche le richieste rifiutate vanno nel registro, perché vi mostrano dove un agente continua a tentare qualcosa che non dovrebbe fare.

Esempio: un cambio di tariffa contestato. Tre mesi dopo la migrazione, un cliente afferma di non aver mai accettato la nuova tariffa. Il registro mostra la data in cui l'agente di migrazione ha creato l'ordine di modifica, il lotto a cui apparteneva, la persona del product management che ha approvato quel lotto e la notifica inviata al cliente. Senza di esso, dovreste ricostruire tutto dalle email.

Testare la revoca e l'interruzione dei job in esecuzione

Revocare i diritti di un agente conta solo se la richiesta successiva fallisce. Testatelo prima di farci affidamento, e testatelo mentre un job è in esecuzione.

Esempio: fermare una migrazione a metà. La migrazione tariffaria sta elaborando qualche migliaio di contratti quando qualcuno si accorge che il nuovo prezzo è sbagliato. Tre cose devono succedere contemporaneamente: i diritti dell'agente vengono revocati, i suoi ordini di modifica in coda si fermano e sapete esattamente quali contratti sono già stati modificati. Provatelo in un ambiente di test: avviate un lotto, revocate l'agente a metà strada e verificate che la chiamata successiva venga rifiutata, che non venga elaborato nient'altro e che il log vi dica dove si è fermato.

I token di breve durata aiutano. La guida di MCP sull'autorizzazione li raccomanda, perché un token di lunga durata rubato continua a funzionare più a lungo (Understanding Authorization in MCP).

Dove aiuta l'autorizzazione di MCP, e dove si ferma

Se i vostri agenti raggiungono i sistemi aziendali tramite un server MCP remoto, la specifica di autorizzazione copre la connessione. Segue OAuth 2.1. Il server MCP agisce come resource server, deve verificare che un token di accesso sia stato emesso per lui e non deve accettare né inoltrare token destinati ad altri servizi. Nel protocollo l'autorizzazione è facoltativa, e le implementazioni su HTTP dovrebbero seguire la specifica (specifica MCP, Authorization).

Questo dice al server quale client sta chiamando, per quale utente e con quali scope. La decisione se questo agente possa preparare una nota di credito per questo cliente, e se una persona l'abbia approvata, spetta comunque al sistema aziendale che sta dietro al server. Quando valutate un fornitore, chiedete di vedere entrambi i livelli e la voce di log che ciascuno scrive.

Come METAVSHN gestisce gli accessi per persone e agenti

METAVSHN ha un unico livello di accesso per persone e agenti: identità, ruoli, diritti, approvazioni e registro di audit. Si trova davanti a fatturazione, CRM, ordini, catalogo prodotti e magazzino, quindi la stessa regola vale sia quando un collaboratore apre l'anagrafica di un cliente, sia quando un agente la richiede tramite la CLI o il server MCP di METAVSHN. I dati dei clienti sono separati per tenant, disdette e accrediti passano per un'approvazione e le indicazioni sui permessi nella CLI non concedono nulla di per sé. La piattaforma è ospitata nei nostri datacenter a Zurigo.

Gestiamo noi stessi un ISP (Ticinocom funziona su METAVSHN), quindi queste regole nascono dai casi che trattiamo ogni settimana: portabilità in uscita, accrediti per disservizi e migrazioni tariffarie.

Se volete vedere come si presentano un'approvazione e la relativa voce di audit per una nota di credito preparata da un agente, prenotate con noi una presentazione di 30 minuti dedicata alla sicurezza: contattate METAVSHN.

Fonti

Tutte le fonti consultate il 31 ottobre 2026.

1. Model Context Protocol, «Tools», versione della specifica 2026-07-28, luglio 2026. modelcontextprotocol.io
2. Model Context Protocol, «Authorization», versione della specifica 2026-07-28, luglio 2026. modelcontextprotocol.io
3. Model Context Protocol, «Understanding Authorization in MCP», luglio 2026. modelcontextprotocol.io
4. Model Context Protocol, «Security Best Practices», versione del protocollo 2026-07-28, luglio 2026. modelcontextprotocol.io
5. Microsoft WorkLab, «2026 Work Trend Index Annual Report: Agents, human agency, and the opportunity for every organization», 5 maggio 2026. microsoft.com