Identità degli AI Agents: cosa succede quando l’AI diventa un utente del sistema?

Da anni, i sistemi digitali sono progettati per riconoscere due categorie principali: utenti e applicazioni. Una persona si autentica nel sistema e ottiene l’accesso in base al proprio ruolo, mentre applicazioni e servizi utilizzano identità tecniche per comunicare tra loro.

Gli AI Agents stanno introducendo una nuova categoria. Possono utilizzare API, consultare documenti, accedere ai dati ed eseguire azioni all’interno dei sistemi, a volte per conto di un utente e altre volte in modo autonomo. Questo introduce una nuova questione architetturale: quale identità dovrebbe utilizzare un AI Agent quando agisce?

Non si tratta più soltanto di una questione teorica. Microsoft Entra Agent ID, ora disponibile in versione generale, introduce identità dedicate agli AI Agents, progettate per supportarne l’autenticazione, l’autorizzazione e la gestione negli ambienti enterprise.

L’utente e l’AI Agent non hanno la stessa identità

Consideriamo un esempio semplice. Un dipendente chiede a un AI Agent di esaminare una serie di documenti, recuperare informazioni da un altro sistema e aggiornare un processo interno.

La richiesta è stata avviata dall’utente, ma le azioni all’interno del sistema vengono eseguite dall’agente. Se il sistema registra soltanto l’identità del dipendente, diventa più difficile distinguere le azioni eseguite direttamente dall’utente da quelle effettuate dall’AI Agent per suo conto.

È qui che l’identità dell’agente assume un ruolo importante. Microsoft definisce una agent identity come l’identità utilizzata da un AI Agent per autenticarsi nei sistemi e accedere alle risorse. In questo modo, il sistema può distinguere l’attività dell’agente da quella degli utenti o di altre applicazioni.

Agire per conto di qualcuno non significa diventare quella persona

Non tutti gli AI Agents operano nello stesso modo.

Un agente interattivo può agire per conto di un utente autenticato. In questo caso, l’utente rimane il soggetto a cui è associato l’accesso, mentre l’agente viene identificato come l’attore che esegue l’azione per suo conto. Un agente autonomo, invece, può operare senza un utente attivo e utilizzare la propria identità e le proprie autorizzazioni.

Questa distinzione cambia il modo in cui possono essere progettati i sistemi. Invece di ricondurre ogni azione alla sola domanda «Quale utente ha fatto questo?», il sistema può conservare un contesto più completo: quale utente ha avviato il processo, quale AI Agent lo ha eseguito e sulla base di quale autorizzazione.

L’identità deve avere confini chiari

Assegnare un’identità a un AI Agent non significa concedergli un accesso illimitato.

Se un agente viene utilizzato per elaborare documenti, ciò non significa automaticamente che debba avere accesso a tutti i documenti dell’organizzazione. Allo stesso modo, se può utilizzare un’API per consultare informazioni, non è detto che debba avere anche l’autorizzazione a modificarle.

Identità e autorizzazione devono quindi essere progettate insieme. Nel modello di Microsoft, le agent identities possono ricevere un accesso delegato quando agiscono per conto di un utente oppure disporre di autorizzazioni proprie quando operano in modo autonomo. Queste identità possono inoltre essere gestite attraverso policy dedicate e specifici processi di lifecycle management.

Il sistema deve sapere anche chi ha eseguito l’azione

Man mano che gli AI Agents iniziano a eseguire processi reali, l’audit diventa importante quanto l’autenticazione.

In un sistema tradizionale, può essere sufficiente registrare che un utente ha modificato un documento. In un processo che coinvolge un AI Agent, il sistema potrebbe invece dover conservare una cronologia più completa: chi ha avviato la richiesta, quale agente ha agito, quali autorizzazioni ha utilizzato e quali modifiche ha effettuato.

Microsoft sta già applicando questa distinzione in alcuni dei propri prodotti. Ad esempio, le azioni eseguite dal Conditional Access Optimization Agent vengono registrate come attività svolte da un AI Agent, rendendo chiaramente distinguibile l’origine dell’attività.

Gli AI Agents stanno diventando attori dell’architettura dei sistemi

Per ALSoft, lo sviluppo delle agent identities riflette un cambiamento più ampio nel modo in cui dovranno essere progettati i sistemi che integrano l’AI.

Se un AI Agent si limita a suggerire una risposta, la sua identità può avere un impatto limitato sul resto del sistema. Ma quando inizia ad accedere ai dati, utilizzare servizi ed eseguire azioni, il sistema deve essere in grado di comprendere chiaramente chi è l’agente, per conto di chi sta agendo e fino a dove si estende la sua autorità.

Come spiega Ermal Beqiri, fondatore di ALSoft:

«Quando l’AI diventa parte attiva di un sistema, non è più sufficiente sapere quale utente ha avviato un processo. Il sistema deve anche distinguere l’agente che sta agendo, l’autorizzazione che ha ricevuto e i limiti entro i quali può operare. È l’identità a rendere chiara questa distinzione.»

Gli AI Agents stanno gradualmente passando dall’essere strumenti che forniscono risposte ad attori in grado di eseguire azioni all’interno dei sistemi digitali. Con il proseguire di questa evoluzione, l’identità digitale non sarà più associata soltanto alle persone e alle applicazioni tradizionali.

L’AI Agent stesso sta diventando un’identità che il sistema deve essere in grado di riconoscere.