Quando si parla di sicurezza degli AI Agent, il dibattito si concentra quasi sempre sul modello di intelligenza artificiale. Prompt injection, jailbreak e manipolazione delle risposte sono ormai temi noti anche al di fuori della comunità cybersecurity.
Eppure, il cambiamento più importante sta avvenendo altrove. Un AI Agent non è semplicemente un software che genera contenuti o risponde a una richiesta. Per essere davvero operativo deve accedere a documenti, interrogare database, utilizzare applicazioni SaaS, avviare workflow e interagire con altri servizi. Per farlo utilizza credenziali, token e permessi.
In altre parole, possiede un’identità. È proprio questo l’aspetto che rischia di essere sottovalutato. Mentre l’attenzione si concentra sul comportamento del modello, la vera superficie di attacco si sposta sull’identità con cui l’agente opera all’interno del tenant aziendale.
Indice degli argomenti
Sicurezza degli AI Agent e identità non umane
E se per anni l’Identity & Access Management è stato costruito attorno a un presupposto semplice per il quale ogni identità corrisponde a una persona, oggi questo paradigma non basta più.
Negli ambienti cloud convivono già migliaia di identità non umane, dai service account alle API, dai workload alle automazioni. Gli AI Agent rappresentano l’evoluzione di questo scenario, con una differenza sostanziale in quanto non si limitano a eseguire istruzioni, ma interpretano il contesto, prendono decisioni e agiscono in autonomia.
Dal punto di vista della sicurezza, quindi, un agente dovrebbe essere considerato prima di tutto come una nuova identità digitale che opera all’interno del tenant aziendale e che, esattamente come qualsiasi altro account privilegiato, deve essere governata.
Pensare che un’infrastruttura cloud sicura renda automaticamente sicuri anche gli AI Agent è un errore. Se un agente dispone di privilegi eccessivi o di credenziali poco protette, diventa un punto di ingresso come qualsiasi altro account compromesso.
Agenti compromessi: privilegi e nuova superficie di attacco
Quando un attaccante compromette un AI Agent non prende il controllo di una semplice applicazione ma acquisisce la capacità di operare con gli stessi privilegi dell’agente, accedendo agli stessi dati, alle stesse API e agli stessi sistemi. È questo il motivo per cui gli AI Agent stanno rapidamente diventando una nuova superficie di attacco.
La prompt injection rimane una delle tecniche più note, ma è solo una parte del problema.
Il furto di token API, credenziali OAuth o chiavi di accesso può consentire di impersonare l’agente. Allo stesso modo, autorizzazioni troppo estese possono trasformarlo in un efficace vettore di privilege escalation. Esiste poi il rischio della data exfiltration ovvero quando un agente manipolato utilizza accessi perfettamente legittimi per esportare informazioni sensibili.
A tutto questo si aggiunge un fenomeno destinato a crescere: lo shadow AI. La possibilità di creare agenti direttamente all’interno dei tenant Microsoft 365, Google Workspace o AWS rende sempre più facile introdurre nuove identità operative senza un reale controllo da parte dell’IT.
Identity & Access Management per la sicurezza degli AI Agent
La domanda da porsi non è soltanto se un agente possa essere manipolato, ma quale identità utilizzi e quali privilegi gli siano stati assegnati. È qui che l’Identity & Access Management assume un ruolo centrale.
Ogni AI Agent dovrebbe possedere un’identità univoca, chiaramente riconoscibile e gestita lungo tutto il suo ciclo di vita. Dovrebbe accedere esclusivamente alle risorse necessarie per svolgere il proprio compito, secondo il principio del least privilege, evitando autorizzazioni permanenti o eccessivamente estese.
Credenziali machine-to-machine e least privilege
Anche le credenziali machine-to-machine meritano lo stesso livello di attenzione riservato agli account amministrativi. Token, certificati e chiavi API devono essere protetti, ruotati periodicamente e sottoposti a controlli continui.
Anomalie comportamentali e autorizzazioni dinamiche
Non basta però controllare gli accessi. Diventa fondamentale osservare il comportamento dell’identità.
Un agente che normalmente consulta documentazione tecnica e improvvisamente inizia ad accedere a dati finanziari o a esportare grandi quantità di informazioni sta inviando un segnale che non può essere ignorato. La capacità di riconoscere queste anomalie costituisce oggi uno degli aspetti più maturi dell’Identity Security.
Anche il modello autorizzativo è destinato a evolvere. I privilegi statici lasceranno progressivamente spazio ad autorizzazioni dinamiche, contestuali e limitate nel tempo, assegnate in funzione del task che l’agente deve realmente svolgere.
Governance e visibilità per proteggere gli AI Agent
La crescita degli AI Agent introduce anche una sfida organizzativa. Molte organizzazioni conoscono con precisione il numero dei propri utenti, ma non sanno quanti AI Agent operino realmente nei loro ambienti cloud, chi li abbia creati o quali autorizzazioni possiedano.
È proprio da questa visibilità che parte qualsiasi strategia di protezione. Governare, infatti, significa censire tutte le identità non umane, definire chi può creare un agente, stabilire regole chiare per la sua messa in produzione e mantenere un audit trail completo delle azioni che compie.
Perché, quando un’identità software prende decisioni operative, ogni attività deve poter essere ricostruita e attribuita.
Sicurezza degli AI Agent: il futuro dell’IAM è già iniziato
Gli AI Agent non stanno semplicemente introducendo nuovi rischi ma stanno accelerando una trasformazione già in corso. Le identità non umane, AI Agent, workload cloud, API, servizi applicativi e automazioni, stanno crescendo più rapidamente delle identità tradizionali. In molte organizzazioni rappresenteranno presto la componente predominante dell’ecosistema IAM.
Questo significa ripensare il modo in cui vengono progettati Identity & Access Management, Identity Governance, Privileged Access Management e, più in generale, tutti i modelli Zero Trust.
Per questo motivo la protezione degli AI Agent non può essere considerata esclusivamente un tema di sicurezza applicativa. È, prima di tutto, una questione di Identity Security.
Perché la domanda che le organizzazioni dovranno porsi non sarà soltanto chi sta accedendo ai sistemi, ma quale identità, umana o non umana, sta agendo, con quali privilegi e sotto quale livello di controllo.
Partecipa alla community