In un post precedente abbiamo parlato dell'accesso degli agenti. Nello specifico, abbiamo spiegato perché la maggior parte degli agenti di IA ne dispone in misura eccessiva e in che modo l'utilizzo degli strumenti regolato da politiche modifica questa situazione.
Oggi approfondiamo ulteriormente l'argomento: l'identità dell'agente.
Quando un agente di intelligenza artificiale compie un'azione all'interno dei sistemi aziendali, quale identità utilizza? Sembra una domanda semplice. Per la maggior parte delle implementazioni aziendali di intelligenza artificiale, la risposta è sorprendentemente poco chiara.
La trappola dell'account di servizio
Ecco come funziona di solito. Uno sviluppatore configura un agente di intelligenza artificiale e ha bisogno che questo si colleghi a un sistema di backend, a un CRM, a un ERP e a un data warehouse. Crea quindi un account di servizio con le autorizzazioni necessarie. Assegna poi tali credenziali all'agente. Il gioco è fatto.
Si tratta di un approccio pragmatico, veloce e quasi universale. Purtroppo, questa scorciatoia comporta anche un problema fondamentale di identità. Peggio ancora, è proprio questo il tipo di problema che impedisce ai sistemi di IA funzionalmente operativi di ottenere l'approvazione necessaria per essere implementati in produzione. Vediamo perché succede.
Gli account di servizio non sono persone. Non hanno ruoli professionali, rapporti gerarchici o criteri di accesso ai dati legati allo status lavorativo di una persona specifica. Non vengono disattivati quando qualcuno lascia l'azienda. E quando qualcosa va storto, quando un operatore accede a dati a cui non dovrebbe o esegue un'azione non autorizzata, la traccia di audit porta a un account di servizio, non alla persona che ha compiuto quell'azione.
«L'agente ha consultato il record X»non è un'informazione forense utile.«L'agente ha agito per conto di Alice, che aveva accesso in sola lettura a quel record e non ha autorizzato questa azione» è invece un'informazione utile. La differenza è fondamentale quando si cerca di spiegare un incidente a un team addetto alla conformità.
Falsificazione dell'identità vs. delega
Esistono due modelli che descrivono il modo in cui un agente di intelligenza artificiale può agire per conto di un utente.
1. Usurpazione d'identità
Per "impersonificazione" si intende che l'agente assume letteralmente l'identità dell'utente. Le credenziali vengono condivise o delegate in modo tale che il sistema di backend percepisca l'azione come proveniente direttamente dall'utente. Si tratta di una procedura semplice da implementare. Inoltre, rende difficile distinguere tra le azioni umane e quelle dell'agente, in modi che risultano difficili da chiarire a posteriori.
2. Delega
Per "delega" si intende che l'agente agisce in virtù di un'autorizzazione concessa dall'utente, circoscritta e limitata nel tempo. Il sistema di backend sa che è un agente ad agire, sa quale utente lo ha autorizzato e sa esattamente cosa l'agente è autorizzato a fare. Si tratta di un modello più complesso da implementare, ma è l'unico che garantisce una reale tracciabilità delle responsabilità.
SnapLogic supporta la delega tramite lo scambio di token OAuth2 e la propagazione dei token. Quando un utente attiva un agente AI tramite il server MCP, la sua identità e il suo token OAuth2 vengono trasmessi lungo l'intera catena di esecuzione.
Quando la pipeline di SnapLogic raggiunge il sistema di backend, conserva l'identità dell'utente originale, non quella di un account di servizio anonimo.
Perché questo è importante ai fini della conformità
La propagazione dell'identità non è solo un dettaglio tecnico. Per i settori soggetti a regolamentazione, i servizi finanziari, la sanità e la pubblica amministrazione, si tratta di un requisito di conformità imprescindibile quando si tratta di accedere a dati reali. E senza tale accesso, un agente di intelligenza artificiale non è utile.
La maggior parte dei sistemi aziendali applica già controlli di accesso basati sull'identità dell'utente. Ad esempio, il vostro:
- Il CRM non consente a tutti i dipendenti di visualizzare tutte le schede dei clienti
- Il sistema ERP dispone di autorizzazioni basate sui ruoli che vengono gestite con cura da anni
- Il data warehouse dispone di una sicurezza a livello di colonna associata a ruoli utente specifici
Quando si utilizza un account di servizio generico attraverso questi sistemi, tali controlli non vengono applicati. Le politiche esistono, ma vengono aggirate. L'agente ottiene i diritti di accesso dell'account di servizio, che spesso sono molto più ampi di quelli di cui disporrebbe un singolo utente.
E no, la soluzione non è quella di utilizzare un account con un ambito di applicazione limitato, perché senza accesso a dati specifici l'agente risulterà molto meno utile, limitandosi a casi d'uso generici e di scarso impatto.
Quando si propaga l'identità dell'utente, tutte le misure di controllo esistenti vengono applicate automaticamente. L'agente può fare esattamente ciò che può fare l'utente. Non è necessario ricostruire il modello di sicurezza per l'IA. Basta semplicemente applicare l'identità corretta.
Lo standard implementato da SnapLogic: RFC 9728
Il server MCP di SnapLogic implementa lo standard RFC 9728, ovvero la specifica relativa ai metadati delle risorse protette (Protected Resource Metadata) di OAuth 2.0. Si tratta di un approccio alla gestione delle identità basato su standard, non di un meccanismo proprietario che introduce nuovi presupposti di sicurezza o crea vincoli di dipendenza.
Quando un agente IA si connette a un server MCP di SnapLogic, rileva automaticamente la configurazione OAuth2. La procedura di autenticazione è conforme agli standard. Il token di identità viene propagato attraverso il piano dati di SnapLogic tramite la propagazione SecurityContext, dal client IA alla pipeline fino al backend.
La domanda da porsi riguardo ai propri agenti di IA attuali
Se nella tua azienda sono già in funzione agenti basati sull'intelligenza artificiale, chiediti: quale identità utilizzano quando si collegano ai sistemi di backend?
Se la risposta è «un account di servizio», hai un problema di gestione delle identità. I tuoi agenti stanno operando al di fuori del modello di gestione delle identità e degli accessi che hai impiegato anni a costruire.
Nella Parte 3 parleremo di ciò che accade una volta che l'accesso e l'identità sono stati gestiti correttamente: il controllo. Nello specifico, come si fa a dimostrare al proprio team di sicurezza, al team addetto alla conformità e ai revisori che gli agenti di IA stanno facendo esattamente ciò che dovrebbero fare, e nient'altro?
Si tratta di una serie in tre parti dedicata alla nostra prossima discussione virtuale dal titolo “Gestione degli agenti IA: accesso sicuro, identità e controllo su scala aziendale".Unisciti a noi il 10 giugno nella tua regione: registrati per la trasmissione EMEA o alla trasmissione per il Nord America. Ci vediamo lì!
