L'agente AI è una nuova utenza privilegiata. Nessuno l'ha censita.

Quando un'azienda adotta un agente AI — un assistente che legge la posta, aggiorna il CRM, prepara documenti, esegue workflow — la conversazione interna ruota quasi sempre attorno a cosa l'agente sa fare. Quasi mai attorno a una domanda molto più vecchia e molto più importante: chi è, questo agente, per i tuoi sistemi?

Con quale identità si presenta al gestionale? Con quali credenziali legge la casella di posta? E quando alle 3 di notte parte una richiesta verso il database, nei log compare lui — o compari tu?

Il default sbagliato: l'agente sei tu

Nella maggior parte dei deployment reali, oggi, l'agente opera con l'identità del suo utente umano. Il meccanismo è quasi sempre lo stesso: un consenso OAuth ("consenti all'app di accedere al tuo account"), un token API personale incollato in una configurazione, oppure — peggio — le credenziali di un amministratore, perché "così funziona tutto senza sbatterci la testa".

È il percorso di minor resistenza, e ha una conseguenza precisa: l'agente può fare tutto ciò che puoi fare tu. Non ciò che gli serve per il compito: tutto. Se tu puoi cancellare, lui può cancellare. Se tu sei admin, lui è admin.

Con il software tradizionale questo problema lo conosciamo da decenni, e infatti abbiamo inventato i service account, i ruoli, il principio del privilegio minimo. Ma un agente AI non è un software tradizionale, ed è qui che il default diventa pericoloso.

Perché un agente non è un service account

Un service account classico esegue sempre la stessa operazione: lo script di backup fa il backup, l'integrazione contabile scrive le fatture. Il suo comportamento è enumerabile in anticipo, e i suoi permessi si possono ritagliare una volta per tutte.

Un agente AI decide a runtime cosa fare: quale strumento chiamare, quale dato leggere, se e come concatenare più azioni per raggiungere l'obiettivo che gli è stato dato. Può incontrare contenuti che non controlli (una email in arrivo, una pagina web) e — come la ricerca sulla prompt injection ha dimostrato ampiamente — può essere indotto da quei contenuti a fare cose che nessuno gli ha chiesto. Su questo torneremo nel prossimo articolo della serie; quello che conta qui è la conseguenza sul piano delle identità: il perimetro di ciò che un agente può fare non è definito dal suo codice, ma dai permessi che gli hai dato. Sono l'unico confine che regge.

E la scala del fenomeno non è marginale. Le identità non umane — service account, chiavi API, workload, e ora agenti — superano già quelle umane di decine di volte nelle stime di settore (da 25:1 a oltre 80:1 secondo le fonti), e una quota consistente degli incidenti di sicurezza coinvolge proprio identità macchina non governate. Gli agenti AI aggiungono a questa massa una proprietà nuova: sono identità non umane con capacità decisionale, create alla velocità con cui si scrive un prompt, mentre i processi di censimento e approvazione delle utenze viaggiano alla velocità degli umani.

Cosa dicono le norme (spoiler: valgono anche per lui)

La parte interessante è che, sul piano normativo, non serve inventare nulla: i requisiti esistono già. Il problema è che quasi nessuno li applica alle identità non umane.

ISO/IEC 27001 — il controllo 5.16 (identity management) copre esplicitamente l'intero ciclo di vita delle identità, umane e non; il 5.18 richiede che i diritti di accesso siano assegnati, riesaminati e revocati secondo la policy; l'8.2 impone la gestione ristretta dei privilegi elevati. Un audit fatto bene dovrebbe chiedere: l'agente AI è nel registro delle identità? Chi ne è l'owner? Quando è stata l'ultima review dei suoi permessi? Nella pratica, la maggior parte degli audit si ferma alle utenze umane, e le identità macchina restano in una zona grigia.

ISO/IEC 42001— il sistema di gestione dell'AI richiede accountability dimostrabile: ogni sistema AI deve avere ruoli e responsabilità definiti, e l'accesso a dati, modelli e pipeline deve essere governato e auditabile. Tradotto per gli agenti: ogni agente ha un responsabile umano identificato, e "chi può fare cosa" è documentato — non implicito nelle credenziali che qualcuno gli ha prestato.

NIS2— per i soggetti in perimetro, l'articolo 21 richiede politiche di controllo degli accessi e gestione delle identità come misura minima. Un agente che opera con credenziali umane condivise è, tecnicamente, una violazione di quella politica prima ancora che un rischio: un'utenza non censita con privilegi non tracciabili.

La domanda "l'agente è un'utenza?" ha quindi una risposta normativa chiara: sì, e da prima che gli agenti esistessero. Ciò che manca non è la regola: è l'abitudine di applicarla a soggetti che non hanno un badge.

Come si governa un'identità agentica

L'esperienza diretta — nostra, costruendo una piattaforma multi-agente, e del settore che sta convergendo sulle stesse pratiche — indica una lista corta e concreta:

1. Censimento — ogni agente entra nell'inventario delle identità come qualunque utenza: nome, scopo, sistemi a cui accede, data di attivazione. Se non è censito, non va in produzione.
2. Un'identità propria per ogni agente — mai le credenziali del suo utente, mai credenziali condivise tra agenti. Se due agenti fanno cose diverse, hanno identità diverse: nei log si deve vedere chi ha fatto cosa.
3. Privilegio minimo, per strumento — l'agente vede solo i tool e i dati che servono al suo compito. "Accesso a tutto il CRM" non è uno scope: "lettura anagrafica clienti" lo è.
4. Credenziali fuori dal modello — chiavi e token stanno in un vault e vengono usati dall'infrastruttura; non passano mai nel contesto del modello, dove qualunque contenuto letto potrebbe indurre l'agente a rivelarli.
5. Accessi a tempo — dove possibile, grant just-in-time legati alla finestra del task invece di permessi permanenti. Un agente che fa una cosa al giorno non ha bisogno di poterla fare 24 ore su 24.
6. Un owner umano — ogni agente ha un responsabile che risponde del suo operato, ne rivede i permessi periodicamente e lo spegne quando non serve più. L'accountability, per ISO 42001, non si delega all'agente.

Niente di tutto questo richiede tecnologia esotica: sono gli stessi principi dell'identity management di sempre, applicati con disciplina a un soggetto nuovo. La differenza rispetto a "facciamolo con il mio account" è la stessa che passa tra dare a un nuovo collaboratore un badge nominativo e prestargli il tuo.

La domanda da fare lunedì mattina

Se in azienda c'è già un agente AI operativo — anche solo in prova, anche solo "quello che smista la posta" — la domanda da fare non è se lavora bene. È: con quali credenziali sta lavorando, e chi lo sa?

Se la risposta è "con quelle di qualcuno", avete appena trovato la vostra utenza privilegiata non censita. Ed è molto più operosa di quelle che eravate abituati a cercare.

Questo è il primo articolo di una serie sulla sicurezza agentica. Il prossimo: la "lethal trifecta" — il triangolo del fuoco degli agenti AI, e come usarlo per valutare qualunque deployment.

Fonti

• Cloud Security Alliance — The Non-Human Identity Governance Vacuum
• The Hacker News — The Non-Human Identity Crisis: Why Your Machine Identities Are Your Biggest Governance Gap
• Obsidian Security — What Are Non-Human Identities? The Complete Guide to NHI Security
• ISO/IEC 42001:2023 — AI management systems
• Roval — ISO 42001 compliance for AI agents: controls, certification and the gap most teams miss
• Direttiva (UE) 2022/2555 — NIS2, art. 21 (EUR-Lex)
• Simon Willison — The lethal trifecta for AI agents