L’adozione degli agenti AI nelle aziende sta procedendo a velocità superiore rispetto alla maturazione dei relativi sistemi di sicurezza. Gli impieghi sono ormai estremamente diversificati, dalla gestione automatizzata del customer service allo sviluppo software, fino alla sicurezza informatica e all’esecuzione autonoma di attività quotidiane. Il problema, come riportato da un nuovo paper del NIST intitolato Back to the Future: Why Agentic AI Needs a Strong Identity Foundation, è che molte implementazioni stanno riproponendo vulnerabilità che il mondo dell’Identity and Access Management combatte da decenni.

Uno degli errori più frequenti consiste nel fornire a un agente le credenziali personali dell’utente. È una scorciatoia comprensibile durante la realizzazione di un proof-of-concept, ma dal punto di vista della sicurezza elimina la distinzione fondamentale tra chi possiede un’identità digitale e il software che opera per suo conto.

Un agente dovrebbe invece disporre di una propria identità, di credenziali specifiche e di autorizzazioni associate all’utente o al sistema che ne delega le attività. Questo consente di mantenere traccia delle operazioni e, soprattutto, di stabilire con maggiore precisione quali azioni l’agente sia effettivamente autorizzato a compiere.

In ambito enterprise esistono già tecnologie utilizzabili come base. OAuth 2.0 e SPIFFE permettono di costruire meccanismi di identificazione e delega, mentre standard emergenti come WIMSE e strumenti basati su JSON Web Token mirano ad adattare questi principi ai sistemi distribuiti nei quali operano gli agenti AI.

Il problema dei token che non scadono

Ancora più rischioso è affidare a un agente API key o bearer token con durata molto lunga. Queste credenziali rappresentano spesso il modo più rapido per collegare un agente a un servizio esterno, ma hanno un limite strutturale visto che chiunque entri in possesso del token può utilizzarlo.

La situazione peggiora quando le chiavi vengono conservate all’interno di file di configurazione, documentazione, repository o log. Un agente può infatti attraversare numerosi sistemi e servizi durante l’esecuzione di un’attività, aumentando i punti nei quali una credenziale può accidentalmente essere esposta.

La soluzione passa da credenziali temporanee, limitate allo specifico servizio e all’azione necessaria. Tecnologie già citate come OAuth 2.0, SPIFFE e i token JWT forniscono già parte degli strumenti necessari, mentre meccanismi come DPoP aggiungono una prova crittografica del possesso della credenziale, rendendo più difficile sfruttare un token semplicemente copiato.

nist agenti AI

Crediti: Shutterstock

Anche utilizzare sistemi IAM moderni non risolve automaticamente il problema. Un agente con autorizzazioni eccessivamente ampie può infatti produrre danni molto superiori rispetto a quelli causati da un singolo utente, semplicemente perché opera più velocemente e può eseguire una quantità enorme di azioni senza interruzioni.

Un comando apparentemente innocuo può portare un agente a 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 può essere la cancellazione di interi dataset, la modifica di codice o l’accesso a informazioni riservate.

Per questo l’autorizzazione deve essere strettamente legata allo scopo dell’attività. Tecnologie come Rich Authorization Requests consentono di descrivere 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.

Attenzione agli agenti che girano sul PC dell’utente

Un’altra pratica problematica consiste nell’eseguire localmente l’agente utilizzando direttamente l’account dell’utente. È una soluzione comoda, soprattutto per sviluppatori che utilizzano agenti per scrivere codice, creare documenti o eseguire comandi, ma al tempèo stesso attribuisce al software gli stessi privilegi della persona.

Diventa quindi difficile distinguere ciò che è stato fatto dall’utente da ciò che è stato eseguito autonomamente dall’agente. Un’alternativa consiste nell’utilizzare ambienti isolati, come container o sandbox, nei quali il sistema AI possa operare con una superficie d’attacco e un insieme di permessi limitati.

Infine, anche se il coinvolgimento umano viene spesso considerato l’ultimo livello di sicurezza, in realtà un utilizzo eccessivo della conferma da parte dell’utente può però generare la cosiddetta consent fatigue. Se un agente chiede continuamente conferma per accedere a dati o strumenti, l’utente può 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 identità distinta dell’agente, autorizzazioni granulari, credenziali temporanee e ambienti isolati, ricorrendo all’intervento umano soprattutto per le decisioni realmente critiche.

(Immagine in apertura: Shutterstock)