Quando l’IA agisce in autonomia: controllo degli accessi e Identity Access Management

Una buona identità agente risponde non solo alla domanda «Chi è?», ma anche a tre domande a cui per le identità umane viene spesso data una risposta implicita:

1. Chi è il responsabile (owner)?
2. Per quanto tempo vale l’identità (scadenza)?
3. Su incarico di chi agisce l’agente (delega)?

Proprio come un collaboratore ha un account utente con attributi definiti, all’agente IA viene conferito un profilo completo personale. L’esempio seguente illustra un’identità agente nel servizio di directory:

Il noto principio di base del Least Privilege vale anche per gli agenti IA, ma deve essere ripensato per adattarsi alla moderna realtà pratica ibrida tra uomo e macchina.

Il Least Privilege segue il principio secondo il quale ogni entità non riceve più solo le autorizzazioni di cui ha assolutamente bisogno per un task concreto. Nel caso degli utenti umani o dei classici account di sistema, si tratta di una pratica ampiamente consolidata. Per gli agenti IA, questo modello fallisce nella sua forma classica perché tre presupposti di base cessano di essere validi:

• I task non sono prevedibili. Un agente riceve spesso istruzioni vaghe e decide autonomamente quali tool utilizzare.
• Le autorizzazioni non costituiscono una decisione binaria. Un agente autorizzato a leggere le e-mail può anche inviarle, inoltrarle o eliminarle, a seconda della granularità dell’API.
• Il contesto modifica la necessità in modo dinamico. Ciò di cui un agente ha bisogno in un task A è irrilevante nel task B, ma l’autorizzazione rimane invariata.

A) Autorizzazioni basate sui task anziché sui ruoli
L’IAM classico assegna ruoli (ad es. «HR Manager»). Per gli agenti IA, un approccio basato sui task è più efficace: l’agente riceve solo le autorizzazioni necessarie per il task specifico attuale, che scadono automaticamente al suo termine.

Anziché: l’agente ha un accesso permanente in lettura a tutti i dati finanziari
Meglio: per il task X l’agente ottiene l’accesso in lettura alle fatture del T2 2026; valido per 15 minuti.

B) Scoped token anziché API key permanenti
Le API key con scope ampio sono l’equivalente di una chiave generica. Per gli agenti IA dovrebbero invece essere utilizzati token di breve durata e strettamente limitati, analogamente agli ambiti OAuth, ma definiti in modo più granulare a livello di risorse.

C) Tool-level permission
Ogni strumento disponibile per un agente deve essere autorizzato singolarmente ed esplicitamente, non come pacchetto. Regola empirica: se un tool non è obbligatorio per il caso d’uso definito, non è disponibile.

D) Autorizzazioni agente gerarchiche in architetture multi-agente
Se un agente Orchestrator coordina più agenti subordinati, nessun agente subordinato può ottenere più autorizzazioni di quelle dell’Orchestrator stesso (vedere la Parte 1 di questa serie). Le autorizzazioni possono essere delegate, ma mai affidate al livello superiore. Questo principio è noto in letteratura come Privilege Containment.

La risposta breve è: no, non automaticamente. Solo se l’architettura lo impone esplicitamente.Questo è un punto importante che il CISO non dovrebbe minimizzare: la tracciabilità completa non è una caratteristica intrinseca degli agenti di intelligenza artificiale. È una decisione sull’architettura che deve essere integrata attivamente. Senza queste precauzioni si creano tipicamente tre lacune:

1. Le catene di delega si perdono. L’Agente A incarica l’Agente B, che a sua volta incarica l’Agente C. Se non tutte le trasmissioni vengono registrate esplicitamente, alla fine rimane visibile solo il fatto che è successo qualcosa, non perché e per conto di chi. Un agente non agisce semplicemente per conto di un reparto definito, ma riceve un’autorizzazione delegata per ogni azione.

2. Il reasoning non è deterministico. Due richieste identiche possono comportare azioni diverse. Il «Perché l’agente ha deciso così» può essere riprodotto spesso solo tramite le fasi intermedie registrate (reasoning trace), ma non in modo affidabile né preciso.

3. Gli strumenti di terze parti sono scatole nere. Non appena un agente attiva un’API esterna o un tool SaaS, la propria visibilità termina al limite del sistema.

La tracciabilità è quindi possibile, ma solo con punti di controllo espliciti lungo l’intera catena (delegation chain). Il fatto è che senza un’architettura ben definita, l’impiego di agenti IA si trasforma rapidamente in una caccia al tesoro forense che può rivelarsi costosa.

Proprio perché l’Agentic AI prende decisioni autonomamente, utilizza i tool e interagisce con i sistemi periferici, ha bisogno di prontezza decisionale e d’azione: ogni azione rilevante deve essere tracciabile dal punto di vista tecnico, organizzativo e specialistico. Questo è in linea con il concetto di zero trust, in cui ogni accesso viene verificato, nonché con gli approcci di AI Governance e TRiSM, che richiedono monitoraggio, tracciabilità, controllo dei dati e dei rischi.

Mentre i fattori descritti nelle sezioni da 2 a 4 contribuiscono alla prevenzione, il fattore dell’accountability fornisce quella visibilità senza la quale Least Privilege, Context e Continuous Verification rimangono ciechi. L’accountability ha un effetto preventivo non appena è abbinata alla valutazione in tempo reale. In questo modo, la semplice documentazione si trasforma in un fattore scatenante per contromisure automatiche.

Qui entra in gioco SIEM/XDR, l’anello di congiunzione che trasforma l’accountability investigativa in un controllo reattivo e in parte preventivo e porta le azioni degli agenti nel campo visivo SOC. Non come esotici log di intelligenza artificiale in una stanza secondaria, ma con un’integrazione in SIEM, SOAR, XDR, IAM, DLP, ERP Audit Log, API Gateway Log, CASB/SASE Context. SIEM (Log Correlation) e XDR (Detection and Response per l’intero sistema) sono i livelli che intrecciano un quadro coerente dalle singole tracce di audit e ne derivano delle azioni.

Concretamente si tratta di quattro parametri d’azione:

A) Correlazione oltre i confini del sistema
L’accesso di un singolo agente al sistema A sembra innocuo. Solo quando SIEM riconosce che lo stesso agente accede entro 90 secondi al sistema A, poi B e poi C, cioè a sistemi che tecnicamente non hanno nulla a che fare l’uno con l’altro, si crea uno schema di «movimento laterale». Questa correlazione è esattamente ciò che rende valutabili la catena di deleghe e i singoli agent log. 

B) Baselining comportamentale per gli agenti
XDR apprende il comportamento normale di un agente: a quali sistemi si rivolge solitamente un agente specifico? Con quale frequenza? Quando? Se il comportamento è eccezionale (come ad esempio l’accesso a un sistema finanziario al quale non si è mai avuto accesso nel profilo normale), il sistema interviene. Si tratta di un rilevamento di anomalie applicato alle non-human identity.

C) Risposta automatica come leva preventiva
È qui che avviene la trasformazione: si passa dal riconoscere qualcosa al prevenirlo. Ad esempio, dei playbook definiti possono attivarsi immediatamente in caso di rilevamento di un movimento laterale:

• Invalidare immediatamente il token dell’agente
• Isolare la sessione dell’agente / Impostare la quarantena
• Bloccare temporaneamente i sistemi interessati per l’Agent ID in questione
• Innescare un’escalation umana

Il punto decisivo consiste nel fatto che questa risposta automatizzata avviene in pochi secondi, cioè mentre l’evento è in corso, non ore dopo durante la valutazione del log. In questo modo si evita qualsiasi ulteriore movimento laterale, anche se il primo è già avvenuto. Si impedisce così la propagazione e quindi si argina efficacemente il blast radius.gina efficacemente il blast radius.

D) Effetto su Least Privilege, Context e Continuous Verification
Le informazioni SIEM/XDR confluiscono nuovamente nel policy engine. Un agente che risulta anomalo può essere sottoposto automaticamente a regole di Continuous Verification più severe o declassato a livello di autorizzazioni (Least Privilege). In questo modo si chiude il cerchio tra controllo investigativo e controllo preventivo.

Per l’architettura ciò significa concretamente che gli accountability log sono inutili se vengono semplicemente scritti in un archivio che nessuno valuta in tempo reale. Il valore viene generato solo nell’associazione. Le tracce di audit degli agenti devono fluire in modo nativo e strutturato nella pipeline SIEM/XDR, con ID agente, catena di delega e contesto come campi di correlazione. Solo allora si passa da «sapere chi è stato» a «fermarlo mentre succede».

Cosa significa concretamente per voi nel ruolo di CISO
Il principio del Least Privilege rimane valido, ma deve essere reso operativo per gli agenti IA.
Tre misure con effetto immediato:

1. Introdurre l’accesso just-in-time: le autorizzazioni vengono rilasciate on demand per un periodo e uno scope definiti e successivamente revocate automaticamente.
2. 3-agent identity registry: ogni agente IA riceve una propria identità univoca nel servizio directory, con autorizzazioni, owner e ciclo di review definiti.
3. Stabilire gli audit di autorizzazione per gli agenti come processo regolare: non annualmente, ma ad ogni modifica del profilo degli incarichi di un agente.
   

In linea di principio, l’obiettivo non dovrebbe essere quello di limitare le autorizzazioni per gli agenti IA, ma di garantire la minima superficie di attacco possibile con la massima funzionalità. È una questione di filosofia della sicurezza? No. È una questione di architettura del sistema. La domanda chiave non è più: «Di quali autorizzazioni ha bisogno un agente IA?», bensì: «Che grado di fiducia ottiene l’agente, per quale task e a quali condizioni?»

Il risultato è un moderno modello di autorizzazione basato su cinque principi chiave, che possono essere riassunti nella seguente formula come guida strutturale:
Identity × Least Privilege × Context × Continuous Verification × Accountability = capacità di agire controllata degli agenti IA
La logica moltiplicativa tra l’arco composto da «Chi → Cosa → Perché → Ancora valido? → Chi risponde» chiarisce che un unico fattore trascurato azzera la sicurezza totale. Un agente IA può essere identificato perfettamente, dotato di autorizzazioni minime, sensibile al contesto e verificato senza lacune. Se in caso di sinistro non è possibile attribuire alcuna responsabilità (Accountability = 0), l’intero modello è privo di valore dal punto di vista della governance.

I principi fondamentali in sintesi:

1. Identity first: ogni agente ha un’identità univoca.
2. Least Privilege: diritti minimi e legati ai task anziché accessi generici. 
3. Context: le autorizzazioni cambiano a seconda della situazione, del rischio e dello scopo.
4. Continuous Verification: si tratta del pilastro del modello Zero Trust, vale a dire che ogni azione viene costantemente controllata e autorizzata.
5. Full Accountability: ogni decisione e azione di un agente è comprensibile e assegnata a un organo responsabile.

Questo modello segue l’approccio alla sicurezza Zero Trust e si integra bene con concetti attuali come Agent Identity, AI Governance e AI TRiSM (AI Trust, Risk and Security Management), che si stanno affermando sempre più come riferimento per l’uso sicuro dell’IA agentica.

Le seguenti best practice fungono da guida per l’IAM per gli agenti IA:

• Human-in-the-loop (HITL): le azioni critiche (ad es. l’invio di offerte o modifiche contrattuali) dovrebbero essere approvate da collaboratori umani prima dell’esecuzione.
• Impiego di gateway IA: utilizzate interfacce e gateway standardizzati (ad es. gateway IA) per monitorare e registrare gli accessi dell’IA.