Per anni abbiamo lavorato sulle identita’ umane: MFA, Conditional Access, passwordless, PAM, access review.
Nel frattempo e’ cresciuta un’altra popolazione. Service account, token, API key, certificati, workload identity e service principal eseguono gia’ una parte consistente del lavoro nei sistemi aziendali.
Gli AI Agent entrano nello stesso problema, con una differenza pratica: possono scegliere quali strumenti usare, concatenare piu’ azioni e operare su sistemi diversi nello stesso flusso.
Per questo la domanda che mi interessa non e’ “quanto e’ intelligente l’agente?”. E’ molto piu’ concreta: con quale identita’ sta lavorando?
Le identita’ non umane sono gia’ tante
Il tema non nasce con gli AI Agent. Nel 2025 CyberArk ha rilevato 82 machine identity per ogni identita’ umana nelle organizzazioni intervistate. Nello stesso studio, il 42% delle machine identity risultava avere accesso privilegiato o sensibile.
Nel 2026 SpyCloud ha intervistato 750 professionisti e responsabili della sicurezza. Il 68% ha dichiarato almeno un evento identity-based nell’anno precedente. Il 42% ha indicato abuso o compromissione di Non-Human Identity come tipologia di evento piu’ frequente, mentre il 50% ha citato NHI esposte, compromesse o con privilegi eccessivi come percorso usato dagli attaccanti.
C’e’ un altro dato che merita attenzione: il 91% delle organizzazioni del campione SpyCloud usa strumenti AI o agenti con accesso interno, ma solo il 56% dichiara una governance formale dei privilegi legati ad AI e NHI.
Sono dati di vendor e vanno letti per quello che sono. Non descrivono tutte le aziende del mercato. Pero’ la direzione del problema e’ chiara: le identita’ software aumentano e una parte di queste identita’ riceve accessi che contano.
Un agente non e’ un normale service account
Un service account classico esegue codice scritto in anticipo. Se il job deve leggere una cartella, elaborare un file e scrivere un risultato, il percorso e’ abbastanza prevedibile.
Un agente puo’ ricevere un obiettivo, decidere quali tool chiamare e adattare i passaggi in base a cio’ che trova. Microsoft descrive esplicitamente agenti capaci di pianificare e concatenare operazioni su piu’ sistemi senza che una persona approvi ogni singolo passaggio.
Questo cambia il modo in cui va valutato un permesso.
Un accesso in sola lettura alla posta, uno a SharePoint, uno al ticketing e uno a un repository possono sembrare limitati se osservati separatamente. Lo stesso agente puo’ pero’ usare insieme quei dati e quelle azioni. Il permesso effettivo diventa la somma di cio’ che l’agente riesce a fare nel flusso completo.
MFA non risolve questo problema
MFA resta fondamentale per gli utenti. Un agente autonomo, pero’, non si autentica come una persona che apre una schermata e approva una richiesta sul telefono.
Nella documentazione di Microsoft Entra Agent ID, gli agenti autonomi possono autenticarsi direttamente con la propria agent identity tramite client credentials flow. Gli agenti che operano per conto di un utente seguono invece un modello delegato.
Il controllo quindi cambia forma. Bisogna sapere quale identita’ sta usando l’agente, quali token puo’ ottenere, quali risorse puo’ raggiungere e per quanto tempo mantiene quei diritti.
Se un agente usa una credenziale condivisa con altri processi, la ricostruzione di un incidente diventa subito piu’ difficile. Se usa permessi troppo ampi, un errore di configurazione o una manipolazione del flusso puo’ avere effetti su sistemi che non erano parte del caso d’uso iniziale.
Microsoft sta trattando gli agenti come identita’ vere
La direzione presa da Microsoft e’ interessante proprio perche’ evita di trattare l’agente come un semplice componente applicativo.
Entra Agent ID introduce identita’ dedicate agli agenti, log di accesso e audit, Conditional Access e gestione del ciclo di vita. La documentazione distingue anche tra owner tecnico e sponsor.
Lo sponsor e’ la persona o il gruppo che risponde dello scopo dell’agente e delle decisioni sul suo ciclo di vita. Microsoft richiede almeno uno sponsor per ogni agent identity e agent identity blueprint.
Questa scelta porta una domanda tecnica dentro la governance aziendale: chi puo’ dire che quell’agente serve ancora? Chi approva i suoi accessi? Chi decide di disabilitarlo durante un incidente?
Un agente senza una risposta a queste domande rischia di diventare il nuovo service account “che nessuno sa a cosa serve”, con in piu’ la capacita’ di agire su piu’ sistemi.
Il problema dei privilegi cresce con i tool
Microsoft, in una guida pubblicata a luglio 2026, consiglia di trattare ogni agente come un principal dedicato, con una propria identita’, ruoli limitati al compito e accesso controllato ai tool.
Il punto sui tool secondo me e’ quello piu’ facile da sottovalutare.
Un agente puo’ avere accesso a una casella di posta, a documenti interni, a un CRM o a un sistema di ticketing. In altri casi puo’ arrivare a repository, API amministrative o automazioni. Se l’agente puo’ scegliere quale strumento chiamare, la sicurezza non puo’ dipendere dal prompt che dice “usa questo tool solo per leggere”.
Il limite deve essere applicato a livello di autorizzazione. Un’azione non consentita deve fallire anche se il modello decide di provarci.
Chi crea l’agente deve pensare anche a come spegnerlo
Cloud Security Alliance ha pubblicato a gennaio 2026 una ricerca commissionata da Oasis Security su 383 professionisti IT e security. Il 78% delle organizzazioni intervistate non aveva policy formalizzate per creare o rimuovere identita’ AI. Il 51% indicava assenza di ownership chiara e accessi eccessivi tra i problemi principali.
Un dato ancora piu’ operativo riguarda la revoca. Il 24% dichiarava di impiegare piu’ di 24 ore per ruotare o revocare una credenziale dopo una possibile esposizione.
Per un agente che puo’ continuare a eseguire task, 24 ore sono tante.
Un progetto serio dovrebbe quindi prevedere fin dall’inizio una procedura di sospensione dell’identita’, revoca dei token e rimozione degli accessi. Non e’ una funzione da aggiungere dopo il primo incidente.
Il modello che userei in azienda
Partirei dall’inventario. Se non sappiamo quanti agenti esistono, chi li ha creati e a quali sistemi accedono, non possiamo governarli.
Ogni agente dovrebbe poi avere una propria identita’. Eviterei account personali riutilizzati, secret condivisi e API key lasciate senza scadenza quando la piattaforma permette alternative migliori.
Il terzo passaggio e’ associare una responsabilita’ umana. Un owner tecnico puo’ gestire configurazione e credenziali. Uno sponsor puo’ decidere se l’agente ha ancora una ragione di esistere e se i suoi accessi sono ancora giustificati.
I permessi andrebbero separati per funzione. Leggere dati, modificare dati, esportare informazioni o cambiare configurazioni non hanno lo stesso rischio. Le azioni con impatto elevato possono richiedere un’approvazione aggiuntiva oppure un diritto temporaneo.
Infine serve un audit che permetta di ricostruire la catena completa: quale utente ha avviato il processo, quale agente ha operato, con quale identita’, quale tool ha chiamato e quale risorsa e’ stata modificata.
Il punto che mi interessa
Gli AI Agent non hanno inventato il problema delle identita’ non umane. Lo stanno rendendo piu’ difficile da ignorare.
Un certificato o una API key possono essere compromessi. Un agente con accesso a piu’ strumenti aggiunge un’altra variabile: puo’ decidere come usare quegli accessi per completare un obiettivo.
Per questo inizierei a trattare gli agenti che accedono a dati e sistemi aziendali con la stessa attenzione riservata agli account privilegiati.
La domanda da fare prima di mettere un nuovo agente in produzione e’ semplice: se domani eseguisse un’azione sbagliata, sapremmo dire con quale identita’ l’ha fatta, perche’ aveva quel permesso e chi poteva fermarlo?