Il nuovo utente del Service Desk non è sempre umano
Nel Service Desk l’identità è sempre stata un presupposto operativo. Un dipendente apre una richiesta, un tecnico la prende in carico, un amministratore approva un accesso. Ogni passaggio lascia un nome, un ruolo e una responsabilità. Con gli agenti AI questo modello si complica: un agente può leggere una knowledge base, interrogare un inventario, creare un ticket, richiamare un altro agente e avviare una correzione senza coincidere né con l’utente che lo ha istruito né con il sistema che lo ospita.
Il 29 settembre 2026 il National Cybersecurity Center of Excellence del NIST ha pubblicato la sintesi di oltre 600 contributi ricevuti sul tema dell’identità e dell’autorizzazione degli agenti software e AI. Il messaggio più utile per chi gestisce servizi è semplice: un agente deve essere riconoscibile come entità non umana, deve poter dimostrare chi lo ha autorizzato e deve possedere soltanto i diritti necessari per il compito corrente.
Non è una discussione lontana dall’operatività. Se un agente apre cento ticket, modifica una priorità o invoca uno strumento di remediation, il Service Desk deve sapere quale agente ha agito, per conto di chi, con quale mandato e per quanto tempo. Senza queste risposte, l’automazione aumenta la velocità ma riduce l’attribuibilità.
Usare le credenziali della persona è una scorciatoia pericolosa
Molti prototipi partono nel modo più rapido: l’agente utilizza una chiave API condivisa oppure eredita la sessione dell’utente. Funziona, ma confonde due soggetti diversi. Nei log l’azione sembra compiuta dalla persona anche quando il percorso è stato deciso dall’agente; oppure tutte le esecuzioni appaiono originate dallo stesso account tecnico, rendendo difficile distinguere errori, abusi e comportamenti inattesi.
Il NIST richiama un principio IAM tutt’altro che nuovo: credenziali e responsabilità non vanno condivise. Per gli agenti significa assegnare un’identità propria, collegata all’organizzazione e al servizio che li governa, mantenendo separata l’identità dell’utente che conferisce il mandato. La catena corretta non è «Marco ha eseguito la modifica», ma «l’agente X ha eseguito la modifica su mandato di Marco, entro il perimetro Y».
Questa distinzione protegge anche il dipendente. Se l’automazione prende una decisione non prevista, l’audit deve ricostruire l’intero percorso senza attribuire automaticamente alla persona ogni conseguenza tecnica. Identità dell’agente, identità del mandante e contesto della richiesta devono quindi viaggiare insieme, ma non fondersi.
Identità stabile, permesso breve
La sintesi del NCCoE distingue utilmente fra una radice di fiducia stabile e credenziali operative effimere. L’organizzazione deve poter riconoscere nel tempo il servizio agente, il proprietario, la versione e l’ambiente autorizzato. Ma il token con cui una singola istanza consulta l’asset management o avvia un reset dovrebbe durare soltanto quanto il compito, essere revocabile e restringersi quando il lavoro viene delegato a un sotto-agente.
Per il Service Desk questo si traduce in una regola pratica: nessun agente dovrebbe conservare privilegi amministrativi permanenti perché, occasionalmente, potrebbe averne bisogno. Un agente che classifica richieste non deve poter cambiare configurazioni; quello che propone una remediation non deve automaticamente eseguirla; quello autorizzato a intervenire su una workstation non deve ricevere lo stesso accesso sull’intero parco dispositivi.
La separazione riduce il raggio d’impatto di un prompt malevolo, di una configurazione errata o di un comportamento emergente. Riduce anche la tentazione di compensare una governance incompleta con un generico account di servizio, comodo nei test e quasi impossibile da difendere quando l’automazione scala.
Il controllo deve avvenire mentre l’agente usa gli strumenti
L’inventario degli agenti è necessario, ma non basta. Un’autorizzazione valida in fase di progetto può diventare inadeguata quando cambia lo strumento chiamato, il dato trattato o il rischio operativo. La governance deve quindi raggiungere il punto in cui l’agente invoca effettivamente un tool, non fermarsi alla registrazione iniziale.
La release di settembre 2026 di AI Gateway di ServiceNow mostra questa direzione applicata alle connessioni MCP. Il gateway separa la configurazione delle policy dalla loro applicazione runtime, mantiene un catalogo dei server e degli strumenti esposti, blocca quelli non approvati, verifica l’identità dell’agente e rilascia token OAuth 2.1 limitati e di breve durata. Le credenziali del server non vengono consegnate direttamente all’agente.
Il principio è più importante del prodotto: tra agente e strumento serve un punto di controllo capace di autenticare, autorizzare, registrare e interrompere. La possibilità di sospendere un singolo server o una singola connessione senza fermare tutte le automazioni trasforma inoltre la revoca da incidente generale a risposta selettiva.
Dal ticket all’audit: quattro identità da conservare
Una registrazione utile dovrebbe separare almeno quattro elementi: l’utente o il sistema che ha espresso l’intento; l’agente principale che ha pianificato il lavoro; gli eventuali sotto-agenti che hanno eseguito attività specialistiche; lo strumento o servizio che ha applicato la modifica. A questi si aggiungono versione del modello, policy valutata, permessi concessi, esito e motivazione dell’eventuale approvazione umana.
Nel ticket non serve riversare ogni dettaglio tecnico. Serve però un riferimento immutabile alla traccia completa, leggibile da supporto, sicurezza e audit. Il tecnico deve capire subito se la richiesta proviene da una persona, da un agente interno o da un agente esterno; il service owner deve poter misurare volumi, errori e rollback per identità agente; la sicurezza deve poter revocare un’autorizzazione senza bloccare l’utente o l’intero servizio.
Anche gli SLA vanno adattati. Il tempo di risoluzione di un’attività automatica non dice nulla se non include autenticazioni negate, tentativi ripetuti, interventi annullati e passaggi all’operatore. L’identità diventa così una dimensione operativa della qualità, non soltanto un controllo di sicurezza.
Un controllo minimo prima di lasciare agire l’agente
Per partire, chiederei a ogni nuovo caso d’uso sei risposte verificabili: quale identità rappresenta l’agente; chi può istanziarlo; quale mandato riceve; quali strumenti può chiamare; quanto durano i privilegi; chi può interromperlo. Se una risposta dipende da una chiave condivisa o da una credenziale personale, il caso d’uso non è pronto per la produzione.
Il pilota dovrebbe iniziare con azioni reversibili e a basso impatto: arricchire il ticket, consultare inventari, proporre una classificazione o preparare una remediation senza eseguirla. Solo dopo aver dimostrato attribuibilità, revoca e qualità dei log si può aumentare l’autonomia. Ogni estensione dei permessi deve essere trattata come una modifica al servizio, con owner, test e criterio di rollback.
Il punto non è rallentare gli agenti AI. È evitare che diventino utenti invisibili con privilegi ereditati e responsabilità indefinite. Nel Service Desk del prossimo ciclo operativo, la domanda decisiva non sarà soltanto che cosa sa fare l’agente. Sarà: possiamo dimostrare chi è, chi lo ha autorizzato e perché quella singola azione gli era consentita?
Fonti e approfondimenti
- NIST — Comments on Software and Agentic AI Identity Concept Paper, 29 settembre 2026 ↗
- NCCoE — Summary of Comments on Agentic AI Identity and Authorization ↗
- NIST — Why Agentic AI Needs a Strong Identity Foundation ↗
- ServiceNow — What’s new in AI Gateway v3.4, settembre 2026 ↗
Analisi e interpretazioni sono personali e non rappresentano le posizioni delle organizzazioni citate o del mio datore di lavoro.