L’adozione di agenti di Intelligenza Artificiale (AI) all’interno delle aziende sta procedendo a un ritmo superiore alla maturazione dei relativi sistemi di sicurezza. Gli impieghi di questi agenti sono ormai estremamente diversificati, spaziando dalla gestione automatizzata del servizio clienti allo sviluppo software, fino alla sicurezza informatica e all’esecuzione autonoma di attività quotidiane.

Come evidenziato in un nuovo documento pubblicato dal National Institute of Standards and Technology (NIST), intitolato Back to the Future: Why Agentic AI Needs a Strong Identity Foundation, molte implementazioni attuali stanno reintroducendo vulnerabilità che il mondo dell’Identity and Access Management (IAM) combatte da decenni. Uno degli errori più frequenti riscontrati consiste nel fornire a un agente le credenziali personali di un utente.

Questa pratica, sebbene comprensibile durante la fase iniziale di realizzazione di un proof-of-concept, dal punto di vista della sicurezza elimina la distinzione fondamentale tra l’identità digitale del proprietario e il software che opera per suo conto. Un agente AI dovrebbe invece disporre di una propria identità univoca, con credenziali specifiche e autorizzazioni strettamente associate all’utente o al sistema che delega le attività. Questo approccio consente di mantenere una traccia completa delle operazioni eseguite dall’agente e, soprattutto, di stabilire con maggiore precisione quali azioni l’agente sia effettivamente autorizzato a compiere.

In ambito enterprise esistono già diverse tecnologie che possono essere utilizzate come base per implementare un sistema di identità robusto per gli agenti AI. OAuth 2.0 e SPIFFE (Secure Production Identity Framework For Everyone) permettono di costruire meccanismi di identificazione e delega sicuri, mentre standard emergenti come WIMSE (Web Identity Management System for Enterprises) e strumenti basati su JSON Web Token (JWT) mirano ad adattare questi principi ai sistemi distribuiti nei quali operano gli agenti AI.

Ancora più rischioso è affidare a un agente API key o bearer token con una durata molto lunga. Queste credenziali rappresentano spesso il modo più rapido per collegare un agente a un servizio esterno, ma presentano un limite strutturale significativo: chiunque entri in possesso del token può utilizzarlo per impersonare l’agente e accedere ai servizi associati. La situazione peggiora ulteriormente quando le chiavi vengono conservate all’interno di file di configurazione non protetti, documentazione pubblica, repository di codice o log di sistema.

Un agente AI può infatti attraversare numerosi sistemi e servizi durante l’esecuzione di un’attività complessa, aumentando esponenzialmente i punti nei quali una credenziale sensibile potrebbe essere accidentalmente esposta. La soluzione a questo problema risiede nell’utilizzo di credenziali temporanee, con una durata limitata allo specifico servizio e all’azione necessaria per completare il compito assegnato. Le tecnologie già citate – OAuth 2.0, SPIFFE e i token JWT – forniscono gli strumenti necessari per implementare questo approccio, mentre meccanismi come DPoP (Draft Proof of Possession) aggiungono una prova crittografica del possesso della credenziale, rendendo più difficile sfruttare un token semplicemente copiato.

Tuttavia, l’utilizzo di sistemi IAM moderni non risolve automaticamente il problema. Un agente AI con autorizzazioni eccessivamente ampie può infatti produrre danni molto superiori rispetto a quelli causati da un singolo utente malintenzionato, semplicemente perché opera a una velocità maggiore e può eseguire una quantità enorme di azioni senza interruzioni o controlli umani. Un comando apparentemente innocuo potrebbe portare un agente ad utilizzare strumenti differenti da quelli previsti, accedere a dati non necessari o seguire percorsi inattesi per raggiungere l’obiettivo assegnato.

In presenza di privilegi elevati, il risultato potrebbe essere la cancellazione accidentale di interi dataset critici, la modifica non autorizzata del codice sorgente o l’accesso a informazioni riservate e sensibili. Per questo motivo, l’autorizzazione deve essere strettamente legata allo scopo specifico dell’attività che l’agente è chiamato a svolgere. Tecnologie come Rich Authorization Requests consentono di definire permessi più granulari rispetto ai tradizionali scope, mentre i Transaction Token possono contribuire a trasferire il contesto dell’autorizzazione lungo una catena di chiamate, riducendo progressivamente i privilegi delegati.

Un’altra pratica problematica consiste nell’eseguire l’agente AI localmente utilizzando direttamente l’account utente. Questa soluzione può essere comoda, soprattutto per gli sviluppatori che utilizzano agenti per scrivere codice, creare documenti o eseguire comandi di sistema, ma al tempo stesso attribuisce al software gli stessi privilegi della persona fisica. Di conseguenza, diventa estremamente difficile distinguere ciò che è stato fatto direttamente dall’utente da ciò che è stato eseguito autonomamente dall’agente AI.

Un’alternativa più sicura consiste nell’utilizzare ambienti isolati e controllati, come container o sandbox, nei quali il sistema AI possa operare con una superficie d’attacco ridotta e un insieme di permessi limitato. Infine, anche se il coinvolgimento umano viene spesso considerato l’ultimo livello di sicurezza, in realtà un utilizzo eccessivo della richiesta di conferma da parte dell’utente può generare la cosiddetta consent fatigue.

Se un agente AI chiede continuamente conferma per accedere a dati o strumenti, l’utente potrebbe finire per approvare automaticamente ogni richiesta pur di non interrompere il flusso di lavoro e in quel momento il controllo umano perde gran parte della sua efficacia. L’approccio più solido consiste quindi nel combinare una identità distinta dell’agente AI, autorizzazioni granulari, credenziali temporanee e ambienti isolati, ricorrendo all’intervento umano soprattutto per le decisioni realmente critiche che richiedono un giudizio soggettivo.

* Contenuto realizzato con l’ausilio di sistemi di intelligenza artificiale.