Identity Management alla prova delle identità non umane: cosa ci aspetta

Per decenni l’Identity & Access Management è stato costruito attorno all’idea che dietro ogni identità digitale rilevante ci fosse una persona. Un dipendente, un consulente, un amministratore, un fornitore, un cliente.

Su questa logica sono stati costruiti i pilastri dell’IAM moderno: il ciclo che segue il dipendente dall’assunzione al cambio di ruolo alla cessazione (Joiner-Mover-Leaver), l’autenticazione unica per tutti i sistemi aziendali (Single Sign-On), l’autenticazione a più fattori con password e codice temporaneo (Multi-Factor Authentication), l’assegnazione dei permessi per ruolo organizzativo (Role-Based Access Control), il controllo degli accessi ad alto privilegio (Privileged Access Management), le revisioni periodiche degli accessi, l’allineamento tra HR, IT e sicurezza.

Era un modello coerente con un mondo in cui l’utente era quasi sempre una persona. Ma quel mondo non esiste più.

I casi

Nel dicembre del 2024 BeyondTrust, uno dei più grandi fornitori di piattaforme che controllano gli accessi privilegiati nelle grandi organizzazioni — rileva attività anomala. Tre giorni dopo emerge che ciò è avvenuto perché una chiave API, cioè la credenziale che permette a un’applicazione di autenticarsi presso un’altra senza intervento umano, è stata compromessa. L’attaccante l’ha usata per accedere a 17 ambienti cloud di clienti, resettando password di account applicativi. Il breach si è propagato lungo la catena.

Tra le vittime, il Dipartimento del Tesoro degli Stati Uniti, che dichiara un “major incident”: il Committee on Foreign Investment e l’Office of Foreign Assets Control vengono toccati, workstation di dipendenti compromesse, documenti non classificati esfiltrati. L’attribuzione arriva al gruppo cinese Silk Typhoon.

Il caso non è isolato. Nel novembre 2024 Schneider Electric subisce l’esfiltrazione di 40 GB di dati dalla propria piattaforma interna di gestione progetti attraverso credenziali esposte. Nell’ottobre 2024 Cisco vede compromessi token e chiavi di accesso dal suo ambiente pubblico di sviluppo software. Il denominatore comune è preciso: nessuno di questi attacchi ha compromesso un’identità umana. Tutti hanno sfruttato identità non umane — chiavi API, account di servizio (usati da software e macchine per operare autonomamente sui sistemi), credenziali automatizzate — con accessi privilegiati e governance frammentata.

Identità non umane: perché il modello IAM non regge più

Il 2025 Identity Security Landscape di CyberArk, basato su 2.600 decision maker cybersecurity in venti paesi, quantifica lo spostamento: le identità delle macchine superano quelle umane con un rapporto di 82 a 1. Il 94% delle organizzazioni segnala un aumento delle identità non umane negli ultimi tre anni. Il 42% di queste identità ha accesso privilegiato o sensibile. Ma il dato più rivelatore è un altro: l’88% delle organizzazioni continua a definire “utente privilegiato” solo un’identità umana.

Il 68% dichiara di non avere controlli identity adeguati per l’AI. Il 47% non riesce a mettere in sicurezza l’uso della cosiddetta Shadow AI, cioè l’AI usata dai dipendenti fuori dai canali autorizzati dall’azienda. La metà dei security leader ha registrato breach legati a identità non umane compromesse nell’ultimo anno.

L’ordine di grandezza è chiaro. Il perimetro dell’identità non coincide più con la persona ma con l’azione digitale. E la maggior parte delle azioni digitali oggi non le compie un dipendente.

Agenti AI e Identity Management: la discontinuità operativa

Finché le identità non umane erano account di servizio, chiavi API e componenti software residenti nel cloud, il problema era già serio ma delimitato: identità statiche, con permessi noti, che eseguono compiti prevedibili. Con gli agenti AI il salto è qualitativo. Un agente non si limita ad autenticarsi e accedere. Interpreta un obiettivo, pianifica sotto-attività, sceglie strumenti, combina fonti informative, genera output, attiva processi. Un agente nel procurement può leggere contratti, interrogare il gestionale, confrontare fornitori, generare una richiesta d’acquisto e avviare un processo autorizzativo.

Un agente nel finance può riconciliare fatture, classificare anomalie, preparare pagamenti. Un agente nel customer service può leggere ticket, aggiornare il CRM, proporre rimborsi, inviare comunicazioni.

La domanda IAM non può più essere soltanto “questo agente può accedere al sistema?”. Deve diventare: con quale identità agisce, entro quale mandato, per conto di chi, con quali limiti, con quale livello di autonomia, sotto la responsabilità di quale referente? Molti incidenti dell’era degli agenti non nasceranno da identità non autorizzate ma da identità perfettamente autorizzate che compiono azioni inappropriate.

Se un agente sbaglia un rimborso o invia una risposta con informazioni sensibili, il problema non è che abbia violato una regola di accesso: è che aveva permessi sufficienti a produrre un danno e governance insufficiente a impedirlo. Se viene manipolato tramite prompt injection — istruzioni ostili inserite nell’input per alterare il comportamento dell’agente — può usare credenziali valide per compiere azioni formalmente autorizzate ma sostanzialmente fraudolente. L’attaccante non deve forzare la porta principale se può convincere un agente autorizzato ad aprirla dall’interno.

Dall’accesso al mandato: l’Action Governance degli agenti AI

Il passaggio operativo richiesto è dal concetto statico di accesso al concetto dinamico di mandato. Un agente non dovrebbe avere semplicemente “permesso di accedere” a un sistema. Dovrebbe avere un perimetro operativo: cosa può fare, quando può farlo, su quali dati, per conto di chi, con quali soglie di autonomia, con quale escalation verso una persona.

Cinque sono i pilastri di questo modello.

Visibilità su identità non umane e agenti AI

Il primo è la visibilità. Non si governa ciò che non si vede. Tutte le identità non umane in azienda — account di servizio, chiavi API, token, bot, componenti software automatizzate, integrazioni con piattaforme esterne e agenti AI — devono essere censite e collegate a sistemi, processi, responsabili e livelli di rischio. Il caso BeyondTrust dimostra cosa succede quando una singola chiave API rimane fuori dal perimetro di monitoraggio adeguato: diventa il vettore d’attacco per compromettere il Dipartimento del Tesoro.

Ownership e responsabilità umana

Il secondo è l’ownership, la titolarità organizzativa. Ogni identità non umana deve avere un responsabile umano o organizzativo. Nessun agente dovrebbe esistere senza qualcuno che ne approvi l’uso, ne comprenda i permessi, ne monitori il comportamento e risponda delle conseguenze. Senza un responsabile identificato, la responsabilità evapora. E quando la responsabilità evapora, il rischio resta.

Privilegio minimo dinamico per gli agenti

Il terzo è il privilegio minimo dinamico. Gli agenti non dovrebbero ricevere permessi ampi “per comodità”, né ruoli generici che restano validi per mesi. I permessi devono essere minimi, temporanei, contestuali e proporzionati al compito. Un agente può avere bisogno di leggere dati in una fase e di scrivere in un’altra, ma non dovrebbe conservare privilegi elevati quando non servono.

Separare lettura, scrittura e decisione

Il quarto è la separazione tra lettura, scrittura e decisione. Un agente che legge dati non dovrebbe poterli modificare automaticamente. Un agente che suggerisce una decisione non dovrebbe necessariamente poterla eseguire. Un agente che prepara un pagamento non dovrebbe poterlo autorizzare. L’autonomia non è binaria: azioni a basso impatto possono essere automatizzate, azioni critiche devono restare presidiate da una persona.

Tracciabilità operativa e audit trail

Il quinto è la tracciabilità operativa (audit trail). Non basta sapere che un agente ha prodotto un risultato o invocato uno strumento. Bisogna poter ricostruire quale input ha ricevuto, quali dati ha usato, quale modello ha interrogato, quale strumento ha invocato, quale credenziale ha utilizzato, quale policy era applicabile. Senza tracciabilità, la governance dell’AI resta una promessa non verificabile.

Identità degli agenti AI tra NIS2, DORA e AI Act

Per le organizzazioni italiane la questione ha un ancoraggio regolatorio preciso. La direttiva NIS2, recepita con il decreto legislativo 138/2024, impone obblighi di gestione strutturata del rischio cyber e responsabilità diretta degli organi di governo. Il regolamento DORA, applicabile dal gennaio 2025 per il settore finanziario, estende requisiti stringenti di resilienza operativa digitale ai fornitori ICT. L’AI Act introduce obblighi di governance, tracciabilità e supervisione umana per i sistemi AI ad alto rischio. Nessuno di questi regimi consente di trattare le identità non umane come dettagli infrastrutturali.

Un account di servizio con accessi privilegiati non censito, una chiave API con permessi sovradimensionati, un agente AI senza responsabile organizzativo sono, in questo quadro, esposizioni di compliance oltre che di sicurezza.

Governare gli agenti AI oltre la cybersecurity

Governare le identità degli agenti AI non è un tema esclusivo del CISO. Coinvolge CIO, CTO, Chief AI Officer, Chief Data Officer, DPO, Legal, Internal Audit, HR, Procurement e i responsabili di funzione. Gli agenti AI non sono oggetti tecnologici: sono nuovi attori organizzativi. Lavorano nei processi, trattano dati, producono raccomandazioni, attivano flussi di lavoro, influenzano decisioni. Ogni attore organizzativo — umano o digitale — deve avere identità, mandato, responsabilità e limiti.

Le aziende più mature stanno introducendo nuove responsabilità organizzative: referenti degli agenti, comitati di governance degli accessi AI, revisori del rischio agentico. Non è burocrazia aggiuntiva: è ciò che rende scalabile un fenomeno altrimenti destinato a rimanere artigianale e incontrollabile. Il percorso operativo parte da un assessment delle identità umane e non umane, passa attraverso una classificazione per rischio e costruisce un modello di governance con responsabili, policy, approvazioni, segregazione dei compiti, registrazione delle attività e procedure di disattivazione. Le tecnologie di supporto — piattaforme di governance dell’identità, gestione degli accessi privilegiati, gestione delle credenziali automatizzate, identità dei carichi di lavoro nel cloud, gateway AI — abilitano il modello, non lo sostituiscono.

Nel futuro dell’impresa la domanda IAM non sarà più soltanto “chi sei?”. Sarà: che cosa puoi fare, per conto di chi, con quale autonomia e sotto quale responsabilità? È lì che si giocherà la vera governance dell’AI. E le organizzazioni che continueranno a trattare le identità delle macchine come eccezioni tecniche scopriranno, come BeyondTrust e Schneider Electric hanno scoperto nel 2024, che l’eccezione tecnica è diventata il vettore principale del rischio