Negli ambienti aziendali moderni l’arrivo degli agenti AI impone una trasformazione della gestione delle identità: non basta più autenticare una volta e concedere permessi a lungo termine. Oggi è necessario un modello che verifichi costantemente lo stato dell’identità, i suoi attributi e il contesto operativo, in modo da limitare l’impatto di errori o compromissioni. Il concetto di valido token non è sufficiente implica che il sistema, oltre a emettere credenziali, debba riuscire a valutare in tempo reale se quelle credenziali continuano a essere adeguate per l’azione richiesta.
Perché l’identità deve evolvere
La logica tradizionale, che considera l’identità come una voce di directory consultata sporadicamente, non è compatibile con processi agentici che possono operare in autonomia per ore o giorni.
Un token rilasciato a un servizio o a un agente potrebbe essere riutilizzato impropriamente se non esistono verifiche frequenti sullo stato dell’entità e sull’ambiente circostante. Per questo motivo diventa fondamentale trattare utenti umani, workload e agenti LLM come identità di prima classe, governate da regole di least privilege, credenziali a breve durata e meccanismi di delega esplicita.
Limitare il raggio d’azione degli errori
Un fallimento o una manipolazione degli obiettivi di un agente può produrre danni significativi se l’architettura non prevede una risposta rapida. La soluzione tipica è spostare la sicurezza verso un modello di valutazione continua: quando un’entità presenta un token, un motore di policy centrale verifica attributi come stato dell’account, rischio rilevato, cambiamento di IP o postura del dispositivo, e decide se confermare o revocare l’accesso.
Questo approccio riduce la finestra temporale in cui un’identità compromessa può agire e permette di intervenire anche durante l’esecuzione di workflow a lunga durata.
Come applicare il modello continuo
In pratica, l’evoluzione passa dall’esterno verso il bordo: identità centralizzate (il tenant di directory) restano il punto di riferimento, ma l’approvazione e il controllo vengono ripetuti ai punti di utilizzo tramite policy as code ed engine di autorizzazione esterni. Il classico RBAC conserva un ruolo, ma non è più sufficiente; servono attributi contestuali, relazioni e regole dinamiche che possano essere valutate in tempo reale. Inoltre, le deleghe devono essere esplicite e temporanee per evitare che gli agenti diventino percorsi di escalation privilegiata non intenzionati.
Catena delle identità e responsabilità
Un’architettura più pulita distingue chiaramente la persona che ha avviato un’azione, il runtime dell’agente, l’applicazione o l’API finale e il token delegato: una vera e propria catena di identità. Questo modello permette di registrare chi ha chiesto cosa, quale runtime ha eseguito il compito e con quali privilegi, e di revocare o ridurre quei privilegi mentre il processo è ancora in corso. In questo modo l’LLM rimane componente della catena e non autorità unica, facilitando audit e ripristino in caso di problemi.
Osservabilità, dati e governance
Governare agenti significa anche sapere cosa fanno: serve osservabilità estesa che non si limiti a uptime e log, ma raccolga telemetria decisionale, tracce di uso degli strumenti, accessi ai dati e segnali di contesto aziendale che possano evidenziare drift o comportamento anomalo.
Parallelamente, la qualità e l’architettura dei dati diventano punti di controllo essenziali: dati fragmentati o silos impediscono l’applicazione efficace delle regole e aumentano il rischio che un agente acceda a informazioni non necessarie.
Per contenere i rischi è necessario combinare policy codificate, credenziali short‑lived, autorizzazioni basate su compiti e meccanismi di escalation per le azioni critiche che richiedono revisione umana. Le organizzazioni più mature integrano questi elementi in piattaforme di governance che offrono inventario, audit continuo e controllo centralizzato dei comportamenti agentici, garantendo che l’innovazione non comprometta sicurezza, compliance e continuità operativa.
