9 settembre 2026
Concedere a un agente di intelligenza artificiale l’uso illimitato dell’account di un dipendente potrebbe sembrare la scelta più pragmatica. L’account è già autenticato, dispone già delle autorizzazioni necessarie e il progetto può procedere senza un’altra lunga revisione di sicurezza. Il problema emerge nel momento in cui l’agente inizia ad agire e il confine tra la persona e il software svanisce. Il registro di audit riporta che un dipendente ha aperto un file, modificato un record o approvato una transazione, quando in realtà è stato un agente a svolgere il lavoro. La responsabilità diventa una questione di supposizioni e l’agente detiene silenziosamente un accesso ben più ampio di quanto richiesto dal suo compito.
Assegnare a ciascun agente una propria identità è la correzione giusta, ed è la prima di due. Un’identità distinta stabilisce quale agente abbia agito. Non stabilisce però che un essere umano responsabile abbia approvato ciò che l’agente ha fatto. Questo secondo problema persiste anche in presenza di un programma di identificazione ben gestito, ed è proprio quello che comporta conseguenze legali e finanziarie.
Il Gartner® Hype Cycle™ 2026 per l’identità digitale definisce la categoria in questo modo: “L’identità degli agenti IA è la rappresentazione digitale univoca degli agenti IA all’interno di un’organizzazione. La definizione e la gestione dell’identità degli agenti di IA, inclusi assistenti e chatbot, consente ai sistemi di gestione delle identità e degli accessi (IAM) di assegnare identificatori univoci, rilasciare credenziali mirate per l’accesso alle risorse (ad esempio API, dati e servizi) e stabilire chiare responsabilità umane e percorsi di audit in tutti i sistemi aziendali.”
Gli identificatori univoci, le credenziali con ambito di validità e una traccia di controllo che attribuisce le azioni al soggetto corretto sono tutte proprietà di attribuzione. Esse stabiliscono quale agente abbia agito e sotto quale autorità, il che è una questione diversa dal fatto che una persona specifica abbia approvato l’azione da esso compiuta.
Le credenziali prese in prestito e la sicurezza degli account di servizio creano un punto cieco
I primi progetti di intelligenza artificiale tendono a funzionare con qualsiasi risorsa sia già a disposizione:
- Un assistente interno potrebbe acquisire autorizzazioni eccessive, a meno che il suo accesso delegato non sia esplicitamente limitato.
- Un flusso di lavoro passa attraverso un account di servizio condiviso.
- Uno sviluppatore collega un agente a un'API utilizzando una chiave a lunga durata.
Queste configurazioni comportano diversi rischi: accesso eccessivo, attribuzione ambigua o credenziali persistenti. L’agente potrebbe ricevere più autorizzazioni di quelle necessarie per svolgere il proprio compito. L’attività umana e quella dell’agente potrebbero confondersi nei casi in cui le credenziali siano condivise. I team di sicurezza potrebbero non disporre di un modo affidabile per sapere quando un agente è in esecuzione o quali transazioni abbia completato.
Ecco perché la sicurezza degli account di servizio è diventata una questione urgente, piuttosto che un semplice problema di gestione interna. Un account di servizio condiviso non è mai stato concepito per rappresentare un attore autonomo in grado di prendere decisioni autonome alla velocità di una macchina, e una chiave API statica non contiene alcuna informazione su chi abbia autorizzato l’operazione o sul motivo per cui sia stata autorizzata.
Le credenziali prese in prestito compromettono inoltre il non ripudio – una caratteristica di sicurezza che dimostra che una persona specifica ha inviato un messaggio o effettuato una transazione e non può in seguito negare di averlo fatto. Quando una persona e un agente condividono la stessa identità, l’organizzazione non è in grado di dimostrare chi dei due abbia compiuto una determinata azione. Secondo il rapporto: «La pratica rischiosa di impiegare agenti di intelligenza artificiale come proxy che operano con credenziali di accesso umane viola i requisiti di audit, tracciabilità e non ripudio, aumentando significativamente il rischio di concessione eccessiva di autorizzazioni, nonché l’impatto della compromissione delle credenziali e dell’appropriazione indebita degli account».
Si tratta di errori di attribuzione, e un’identità ben definita è il rimedio giusto per risolverli.
Cosa cambia con un’identità separata?
Un’identità dedicata assegna all’agente un proprio record nell’ambiente IAM, con un proprietario identificato, uno scopo definito e un insieme deliberatamente ristretto di autorizzazioni approvate per suo conto da tale proprietario. Può essere disattivata senza interferire con il dipendente o il team che la gestisce. L’autenticazione dell’agente IA diventa un evento distinto che è possibile osservare e analizzare, piuttosto che qualcosa di nascosto all’interno di una sessione umana. All’agente possono essere rilasciate credenziali a breve durata anziché una password permanente o una chiave API. Il suo accesso può essere limitato a una specifica applicazione, attività o transazione. La sua attività può essere esaminata in base ai propri criteri, separatamente da quella di qualsiasi utente umano.
Il re-binding merita particolare attenzione. L'assegnazione di un agente a un proprietario o mandante diverso costituisce un cambiamento di identità piuttosto che un semplice aggiornamento di un campo; pertanto, dovrebbe richiedere una nuova verifica della persona che ora si assume la responsabilità. Un registro di proprietà che possa essere modificato senza ristabilire chi ha accettato di assumersi il rischio espone il rapporto a possibili controversie.
Questo si avvicina maggiormente al modo in cui dovrebbe funzionare il modello Zero Trust, in cui un’autenticazione precedente non viene considerata una prova definitiva di nulla. Il caso “agentic” estende questa logica ancora di un passo. Un’autenticazione precedente non costituisce nemmeno la prova che una persona abbia approvato ciò che accadrà in seguito
Gli agenti di intelligenza artificiale hanno bisogno di un accesso permanente?
Spesso sì. L’accesso da parte degli utenti dipende solitamente dal ruolo lavorativo, poiché le responsabilità permangono. Alcuni agenti funzionano allo stesso modo. Un agente di riconciliazione che viene eseguito ogni notte, o un agente di servizio che gestisce una coda continua, ha bisogno di un’autorizzazione permanente per essere effettivamente utile. Altri ne hanno bisogno in misura molto minore: prelevare una fattura, abbinarla a un ordine di acquisto, restituire il risultato. Concedere a entrambi i tipi l’insieme completo delle autorizzazioni di un dipendente sarebbe indifendibile. Le credenziali a breve durata sono utili in entrambi i casi, sebbene riducano il margine di abuso piuttosto che eliminarlo del tutto, e la scadenza non annulla di per sé l’autorizzazione sottostante.
Il rapporto descrive un profilo di innovazione correlato come segue: “La gestione dell’accesso ai carichi di lavoro, che fa parte di un programma globale di IAM per le macchine, protegge l’universo in rapida espansione dei carichi di lavoro – che comprende agenti di intelligenza artificiale, applicazioni, container e microservizi – applicando il principio del privilegio minimo in fase di esecuzione e sostituendo le credenziali statiche con controlli dinamici e sensibili al contesto. La gestione degli accessi ai carichi di lavoro elimina le autorizzazioni permanenti, riduce le superfici di attacco da macchina a macchina e colma il punto cieco critico che compromette la maggior parte delle strategie zero-trust.”
Manteniamo le autorizzazioni permanenti e poniamo una domanda diversa al riguardo. Non ci chiediamo per quanto tempo un agente detenga l’autorità, ma chi gliel’abbia concessa. Ogni insieme di autorizzazioni dovrebbe essere approvato da una persona identificabile, sulla base di prove che l’agente non avrebbe potuto produrre. Un agente in grado di produrre, riprodurre o soddisfare tali prove può, di fatto, approvare se stesso.
L’identità da sola non spiega l’intenzione
Un’identità distinta indica quale agente sta agendo. Non dice nulla su ciò che quell’agente sta cercando di ottenere. La distinzione diventa importante non appena un agente riceve un’istruzione generica come “organizza il mio viaggio di lavoro” o “risolvi il problema relativo al conto di questo cliente”. L’agente potrebbe interpretare la richiesta in modi che l’utente non avrebbe mai previsto, e potrebbe essere indotto a deviare dal proprio obiettivo tramite l’inserimento di prompt o dati compromessi.
In questo contesto, l’autenticazione e l’autorizzazione si distinguono nettamente. L’autorizzazione dell’agente IA deve rispondere a una domanda a cui un semplice accesso non può rispondere: questa azione specifica rientra nei limiti di ciò che la persona ha effettivamente richiesto?
Il rapporto descrive un ulteriore profilo di innovazione che affronta proprio questo aspetto: “Il controllo degli accessi basato sull’intento è un quadro autorizzativo emergente che sostituisce le autorizzazioni generali e permanenti ed è attualmente rivolto all’IA agentica, ma offre un’ampia applicabilità. Il controllo degli accessi basato sull’intento concede l’accesso alle risorse di back-end in base all’intento rilevato o dedotto degli utenti che interagiscono con un agente e valuta le azioni previste dall’agente alla luce di tale intento”.
L’intento dedotto è un input utile per una decisione di accesso. Non è un’approvazione. L’intento ricavato da una conversazione rimane una descrizione assemblata all’interno del contesto proprio dell’agente, quindi un agente disallineato o influenzato dal prompt può plasmarlo. La valutazione dell’intento può restringere ciò che un agente fa all’interno di un’autorità concessa da qualcuno. Stabilire che l’autorità sia stata concessa è un passo a sé stante. A questo punto, tre controlli stanno svolgendo un lavoro concreto, e ciascuno ha lo stesso limite:
- La verifica dell'identità della persona serve a stabilire chi sia. Non serve a stabilire ciò che ha accettato.
- Dedurre l’intenzione permette di stabilire quale fosse l’apparente significato della richiesta. Non dimostra però che la persona abbia visto l’azione che ne è derivata.
- La definizione dell’ambito di accesso stabilisce in modo restrittivo ciò a cui l’agente può accedere. Non stabilisce che quella specifica azione fosse desiderata.
Ciò di cui hanno bisogno le azioni con le conseguenze più gravi è un collegamento tra tre elementi: una persona verificata, l’agente che agisce per suo conto e l’azione specifica o l’autorizzazione che quella persona ha approvato. Pertanto, l’azione dovrebbe essere sospesa prima che abbia effetto. È il livello di controllo, piuttosto che l’agente, a dover illustrare cosa comporta l’azione e entro quali limiti, e la decisione dovrebbe essere restituita fuori banda, direttamente a quel livello di controllo, attraverso un canale che non sia mediato dall’agente proponente. Chiamiamo la prova rilasciata a sostegno di tale decisione “resistente all’agente”: l’agente non può generarla, riprodurla né ottenerla reclutando un secondo agente su un altro dispositivo. iProov Dynamic Liveness la fornisce, attestando la presenza di un essere umano autentico nel momento dell’approvazione e legato all’azione specifica. Abbiamo illustrato come tale delega dovrebbe funzionare in un articolo separato sull’autorizzazione umana verificata nell’IA agente.
Inizia distinguendo le persone dagli agenti, poi dimostra l'approvazione
Gli agenti non dovrebbero essere estensioni invisibili dell’account di un dipendente. È necessario attribuire a ciascuno di essi una propria identità, assegnare un responsabile, mantenere rigorosi i permessi, monitorarne le attività e revocarne l’accesso al termine del lavoro. Se gestita correttamente, questa non è una configurazione una tantum, ma la gestione del ciclo di vita degli agenti di IA: gli agenti vengono creati, valutati, riassegnati e dismessi, e la governance degli agenti di IA è ciò che garantisce l’integrità di tale ciclo man mano che il numero di agenti cresce.
A questo punto occorre decidere quali azioni non possano essere eseguite solo sulla base dell’autorità delegata, poiché è proprio in questi casi che una prova più solida dimostra il proprio valore. Le organizzazioni limitano comunemente gli agenti a compiti di scarsa rilevanza, non perché l’agente non sia in grado di fare di più, ma perché non possono dimostrare l’approvazione umana per operazioni di livello superiore. Una prova di approvazione che nessun agente è in grado di fornire elimina tale limite. L’avvio dei pagamenti, le modifiche dei beneficiari, l’elevazione a ruoli privilegiati e le modifiche alle autorizzazioni dell’agente stesso possono essere automatizzate fino al punto di approvazione e mantenute in attesa di un’autenticazione di livello superiore; vengono poi rilasciate a fronte di una ricevuta che indica l’approvatore, l’azione, i parametri che gli sono stati mostrati e un periodo di validità monouso. L’attrito si concentra su una manciata di momenti cruciali, mentre il lavoro di routine tra uno e l’altro procede senza interruzioni.
Non è possibile ricostruire a posteriori le prove dell’approvazione, pertanto il collegamento tra una decisione umana e l’azione che essa autorizza deve essere definito prima che gli agenti vengano messi in funzione. Queste fasi richiedono un impegno iniziale all’avvio di un progetto, ma consentono di evitare un problema ben più grave in seguito: migliaia di agenti autonomi che operano utilizzando credenziali condivise o gestite in modo inadeguato, prendendo decisioni con conseguenze significative di cui non è possibile attribuire la responsabilità a nessuna persona identificabile.
Gartner, Hype Cycle for Digital Identity, 2026, Zachary Smith, Nayara Sangiorgio, 6 luglio 2026.
Gartner e Hype Cycle sono marchi registrati di Gartner, Inc. e/o delle sue affiliate.
Gartner non promuove alcuna azienda, fornitore, prodotto o servizio citato nelle proprie pubblicazioni e non consiglia agli utenti di tecnologia di scegliere esclusivamente i fornitori con le valutazioni più elevate o altre designazioni. Le pubblicazioni di Gartner riflettono le opinioni dell’organizzazione di analisi aziendale e tecnologica di Gartner e non devono essere interpretate come affermazioni di fatto. Gartner declina ogni garanzia, espressa o implicita, in relazione alla presente pubblicazione, incluse eventuali garanzie di commerciabilità o idoneità per uno scopo particolare.
Prossimo articolo della serie: perché la visibilità dell’identità è così importante quando esseri umani, macchine e agenti di intelligenza artificiale operano tutti nello stesso ambiente.
