Quando un agente AI cancella un archivio, approva una transazione o interroga un database aziendale, qualcuno deve poter rispondere alla domanda: con quale autorizzazione lo ha fatto, e per conto di chi? Le identità non umane permettono di attribuire a un agente un’identità verificabile e permessi definiti e, insieme a sistemi di logging adeguati, di ricostruire le sue azioni. Non è un dettaglio tecnico da lasciare ai team infrastrutturali: stabilisce chi può autorizzare un’azione e quali elementi restano disponibili per accertare eventuali responsabilità. Identificare tecnicamente un agente, però, non equivale a determinare automaticamente chi risponde delle conseguenze delle sue azioni.
Identità non umane: cosa cambia tra accesso delegato e accesso autonomo
Un’identità non umana permette agli amministratori di autenticare un carico di lavoro, assegnargli permessi e monitorarne l’attività, distinguendo due modelli operativi molto diversi tra loro [1]. Nell’accesso delegato l’agente agisce per conto di un utente umano, con permessi circoscritti a un’attività specifica e, quando previsto, limitati nel tempo; nell’accesso autonomo l’agente opera con una propria identità e permessi assegnati direttamente, senza richiedere una sessione umana attiva [1].
È importante distinguere l’identità dalle credenziali e dalle autorizzazioni. L’identità permette di riconoscere l’agente, le credenziali, come token o certificati, servono ad autenticarlo, mentre i permessi stabiliscono quali risorse può utilizzare e quali operazioni può eseguire. Possedere un’identità verificabile non significa avere automaticamente accessi limitati o una tracciabilità completa: entrambi dipendono dai controlli effettivamente implementati [9].
Microsoft Entra Agent ID applica questa distinzione nella pratica: gli agenti autonomi si autenticano direttamente con la piattaforma usando l’identità dell’agente e un flusso di credenziali client, mentre con l’accesso delegato l’agente usa i diritti assegnati all’utente, nei limiti delle autorizzazioni concesse [2]. Un esempio concreto è il flusso On-Behalf-Of (OBO) di Microsoft Entra, basato su OAuth 2.0: consente a un’applicazione di ottenere un token per accedere a un’altra API utilizzando autorizzazioni delegate da un utente. Si tratta di un meccanismo specifico della piattaforma Microsoft per scenari che coinvolgono un’identità utente, non di un protocollo universale per la delega tra agenti autonomi [18]. Se l’agente deve a sua volta delegare il compito a un sub-agente, è opportuno prevedere autorizzazioni circoscritte e una tracciabilità verificabile della catena di delega: questi controlli devono essere implementati nell’architettura di gestione delle identità e non sono garantiti automaticamente dal solo protocollo OAuth [3] [4].
Nel riepilogo dei commenti pubblici al concept paper del NIST NCCoE sull’adozione di identità e autorizzazione per agenti software e AI, un partecipante alla consultazione descrive la delega come l’elemento che rende un agente utile in azienda senza dover esporre credenziali di lunga durata o concedere privilegi ambientali troppo ampi: la delega standardizzata, scrive, permette all’agente di agire per conto di un soggetto umano attraverso i confini applicativi, con un intento esplicito dell’utente dietro ogni azione [4]. Il concept paper, pubblicato nel febbraio 2026, non costituisce uno standard vincolante, ma raccoglie questioni da approfondire per un possibile progetto dimostrativo. Tra queste figurano identificazione, autenticazione, autorizzazione e delega, auditing e non ripudio, prevenzione e mitigazione delle prompt injection [5]. L’autorizzazione può appoggiarsi su standard già esistenti come OAuth 2.0 e su meccanismi di controllo degli accessi basati su policy, per decidere cosa un agente può fare in base alla sua identità, al contesto e alle autorizzazioni applicabili [6].
I rischi che le organizzazioni di sicurezza attribuiscono agli agenti autonomi
L’OWASP Top 10 for Agentic Applications 2026 cataloga dieci categorie di rischio che un team dovrebbe modellare prima di portare un agente in produzione: dirottamento dell’obiettivo dell’agente, uso improprio degli strumenti, abuso di identità e privilegi, vulnerabilità della catena di fornitura agentica, esecuzione di codice non prevista, avvelenamento della memoria e del contesto, comunicazione insicura tra agenti, fallimenti a cascata, sfruttamento della fiducia tra umano e agente, e agenti canaglia [7].
Il rischio dell’abuso di identità e privilegi merita attenzione specifica: quando un agente opera, può esercitare le autorizzazioni associate alle chiavi, ai token e agli account di servizio che gli sono stati assegnati, nei limiti imposti dai sistemi a cui accede. Se questi permessi sono troppo ampi, più privilegi possono concentrarsi in un unico punto di esecuzione [8]. È quello che l’OWASP NHI Top 10 descrive come identità con privilegi eccessivi, insieme a offboarding improprio con credenziali dimenticate e a perdita di segreti e credenziali di lunga durata [9].
Un caso utile per illustrare il rischio delle credenziali non governate è la violazione dell’Internet Archive del 2024. Un token GitLab, rimasto esposto per un lungo periodo, avrebbe consentito l’accesso al codice sorgente e ad altre credenziali, contribuendo alla compromissione di sistemi aziendali, tra cui il servizio di assistenza Zendesk. Gli attaccanti hanno dichiarato di aver esfiltrato 7 terabyte di dati, una quantità non confermata in modo indipendente. Non si tratta di un incidente causato da un agente AI, ma di un esempio dei rischi che possono derivare dall’esposizione e dalla mancata rotazione delle credenziali non umane [20].
Un’indagine della Cloud Security Alliance, commissionata da Aembit e pubblicata nel marzo 2026, evidenzia quanto sia difficile governare le identità degli agenti: il 68% delle organizzazioni intervistate non riesce a distinguere chiaramente le azioni compiute dagli agenti AI da quelle degli utenti umani, mentre il 74% riferisce che gli agenti ricevono spesso più privilegi del necessario [10]. Nel distinto Data and Identity Security Report 2026 di Netwrix, il 76% delle organizzazioni dichiara di non governare o monitorare completamente le identità non umane. Il rapporto si basa sulle risposte di 2.317 professionisti IT e della sicurezza, rappresentativi di 1.889 organizzazioni: il dato misura la maturità della governance e non va interpretato come la percentuale di aziende che utilizzano agenti autonomi [11].
Il divario tra adozione e governance è esattamente il punto su cui si concentra l’analisi giuridica italiana: un agente dotato di credenziali eccedenti la funzione per cui è stato predisposto può concatenare accessi e risorse fino a produrre, di fatto, una condizione operativa assimilabile a quella di un utente privilegiato, pur non essendo stato progettato per quel ruolo [12]. L’assenza di un principio di minimo privilegio applicato alle identità macchina può integrare una lacuna del modello organizzativo rilevante ai fini della responsabilità dell’organizzazione, secondo le norme e le circostanze applicabili [12].
Un punto spesso sottovalutato riguarda l’affidabilità dei vincoli scritti nelle istruzioni dell’agente: un’istruzione di configurazione, come il divieto di cancellare archivi determinati, non equivale a un controllo tecnico vincolante, perché il modello può disattenderla per prompt injection, comportamenti non previsti in fase di progettazione o per la natura probabilistica del proprio funzionamento [12]. Il divieto deve essere applicato anche dai sistemi che autorizzano ed eseguono le operazioni, indipendentemente dalle istruzioni ricevute dal modello. Chi pensa di aver risolto il problema scrivendolo in un prompt sta confondendo un’intenzione con un controllo.
Cosa chiedono NIS2 e AI Act su accessi e tracciamento
La direttiva NIS2 richiede ai soggetti che rientrano nel suo ambito di applicazione di adottare misure adeguate e proporzionate di gestione del rischio, incluse strategie di controllo degli accessi e gestione degli asset. Per le organizzazioni che impiegano agenti AI, queste misure sono rilevanti anche per governare le identità non umane. Tra le soluzioni operative per applicare il principio del minimo privilegio rientrano l’Identity and Access Management e il controllo degli accessi basato sui ruoli (RBAC), insieme a revisioni periodiche degli accessi e procedure per concederli e revocarli. Per gli agenti che operano in contesti dinamici possono essere necessari anche controlli più granulari, basati su attributi, contesto e singole azioni, oltre a Privileged Access Management per limitare i privilegi amministrativi permanenti. Si tratta di possibili misure di implementazione, non di tecnologie universalmente imposte dalla direttiva [13].
La protezione delle identità comprende misure come autenticazione multifattore, quando appropriata e applicabile, controllo degli accessi privilegiati, gestione delle identità digitali e tracciabilità degli accessi ai sistemi critici, da adottare in funzione dei rischi e dei requisiti pertinenti [14]. Per le identità macchina, l’autenticazione forte può richiedere meccanismi diversi da quelli utilizzati dagli esseri umani, come credenziali di breve durata e certificati gestiti in modo sicuro. L’articolo 21, paragrafo 2, lettera i, della NIS2 richiama specificamente le strategie di controllo degli accessi e la gestione degli asset. L’articolo 20 assegna inoltre agli organi di gestione dei soggetti essenziali e importanti compiti di approvazione e supervisione delle misure di cybersicurezza, prevedendo la possibilità di responsabilità per le violazioni nei termini della normativa applicabile [13].
In Italia questi obblighi trovano una declinazione operativa nella Determinazione ACN 379907/2025, applicabile dal 15 gennaio 2026, che include tra le misure di sicurezza di base della NIS2 la gestione dell’autenticazione, delle identità digitali e del controllo degli accessi. Gli allegati prevedono complessivamente 37 misure per i soggetti importanti e 43 per i soggetti essenziali, delle quali rispettivamente dodici e sedici appartengono alla funzione di protezione [16]. La data del 15 gennaio 2026 riguarda l’applicabilità della determinazione, non la scadenza generale per completare tutte le misure: per i soggetti inseriti nell’elenco NIS nel 2025 il termine è di diciotto mesi dalla comunicazione di inserimento, generalmente nell’ottobre 2026 per le comunicazioni ricevute ad aprile 2025. Per i soggetti inseriti per la prima volta nel 2026, la Determinazione ACN 127434/2026 ha fissato il termine al 31 luglio 2027 [15].
L’AI Act introduce un secondo livello di obblighi, specifico per i sistemi ad alto rischio. L’articolo 26 stabilisce i requisiti per i deployer, ossia i soggetti che utilizzano un sistema AI sotto la propria autorità. L’applicazione delle disposizioni sui sistemi ad alto rischio è prevista dal 2 dicembre 2027 per quelli classificati ai sensi dell’allegato III e dal 2 agosto 2028 per quelli integrati nei prodotti regolamentati dell’allegato I, secondo le condizioni e le disposizioni transitorie applicabili [19]. Per approfondire classificazione e calendario è disponibile anche l’analisi sui sistemi ad alto rischio nell’AI Act. Tra gli obblighi previsti per i deployer dall’articolo 26 rientrano [17]:
- un utilizzo conforme alle istruzioni d’uso fornite dal produttore
- sorveglianza umana affidata a persone dotate delle competenze, della formazione e dell’autorità necessarie
- controllo sui dati di input quanto a pertinenza e rappresentatività rispetto alla finalità prevista, nella misura in cui siano sotto il controllo del deployer
- monitoraggio del funzionamento, con segnalazioni al fornitore o all’autorità competente nei casi previsti
- conservazione dei registri generati automaticamente dal sistema, nella misura in cui siano sotto il controllo del deployer, per un periodo appropriato alla finalità del sistema e comunque di almeno sei mesi, salvo diverse disposizioni applicabili
Sono gli obblighi previsti dall’articolo 26 per i deployer di sistemi ad alto rischio, nei limiti e secondo le condizioni stabilite dal regolamento [17]. Letti insieme ai requisiti di accesso della NIS2, questi obblighi indicano una direzione comune per i soggetti e i sistemi cui le norme si applicano: controllare chi può accedere ai sistemi, ricostruire le operazioni e, per i sistemi AI ad alto rischio, garantire la sorveglianza umana prevista dal regolamento. Le due normative hanno tuttavia ambiti di applicazione distinti e non impongono automaticamente gli stessi adempimenti a ogni agente AI aziendale [13] [17].
Perché questo non è un dettaglio di configurazione
Le identità non umane mettono insieme tre questioni strettamente collegate: chi autorizza un’azione, chi ne risponde, e cosa viene registrato per ricostruirla dopo. Microsoft Entra Agent ID distingue l’accesso delegato da quello autonomo, mostrando come i permessi possano essere attribuiti all’identità dell’agente oppure derivare dai diritti delegati da un utente umano [2]. I framework di OWASP e le analisi su incidenti reali mostrano cosa succede quando questa gestione non viene applicata con rigore: un agente con credenziali eccedenti la propria funzione può operare, di fatto, con privilegi molto più ampi di quelli necessari al suo compito [7] [9].
Si consideri un agente incaricato di leggere gli ordini di un e-commerce per preparare un report. Se riceve per errore anche il permesso di modificare o cancellare gli ordini, il problema non nasce necessariamente da una decisione autonoma del modello, ma dalla configurazione delle autorizzazioni. I registri possono mostrare quali operazioni ha eseguito e con quali credenziali; per capire perché disponesse di quei privilegi occorre invece risalire a chi li ha concessi, alle procedure di approvazione e ai controlli previsti. È proprio questa distinzione che rende la gestione delle identità non umane una questione di governance, oltre che di sicurezza tecnica.
Per stabilire chi risponde delle azioni di un agente AI bisogna distinguere tre livelli. L’identità tecnica permette di attribuire un’operazione all’agente che l’ha eseguita. La responsabilità organizzativa riguarda i soggetti che hanno autorizzato l’impiego dell’agente, assegnato i permessi e definito i controlli e la supervisione. La responsabilità giuridica dipende invece dagli obblighi applicabili, dai ruoli effettivi e dalle circostanze del caso: non discende automaticamente dall’identità utilizzata per accedere al sistema. Anche il NIST NCCoE evidenzia l’esigenza di registrare non soltanto le azioni, ma il contesto, le autorizzazioni e le catene di delega che le hanno rese possibili [4].
Per i soggetti e i sistemi che rientrano nei rispettivi ambiti di applicazione, NIS2 prevede misure di controllo degli accessi e AI Act specifici obblighi di tracciamento per i sistemi ad alto rischio, secondo le relative scadenze [13] [19]. Decidere come trattare un’identità non umana oggi non significa stabilire automaticamente chi sarà giuridicamente responsabile domani, ma creare le condizioni tecniche e organizzative per ricostruire le decisioni, verificare le autorizzazioni e accertare le responsabilità quando necessario.
Fonti
- Sicurezza dell’agente AI: Controlla l’accesso alle app aziendali — TSplus tsplus.net
- Che cosa sono le identità degli Agenti? – Microsoft Entra Agent ID — Microsoft Learn learn.microsoft.com
- Agente IAM Spiegazione: Identità e accesso sicuri per gli agenti di intelligenza artificiale — miniorange miniorange.com
- Summary of Comments on the Concept Paper — NCCoE Agentic AI Identity and Authorization Project — NIST NCCoE pages.nist.gov
- Accelerating the Adoption of Software and AI Agent Identity and Authorization — Concept Paper — NIST NCCoE | Febbraio 2026
- NIST NCCoE Four Focus Areas → AuthZ Controls — Permit.io | 21/10/2026
- OWASP Top 10 for Agentic Applications — The Benchmark for Agentic Security — OWASP Gen AI Security Project | 09/12/2025
- OWASP Agentic Top 10 Released: AI Risks — Astrix Security | 10/12/2025
- OWASP Non-Human Identities Top 10 — OWASP Foundation owasp.org
- More Than Two-Thirds of Organizations Cannot Clearly Distinguish AI Agent from Human Actions — Cloud Security Alliance | 24/03/2026
- 2026 Data and Identity Security Report — Netwrix Research Lab | 2026
- Identità non umane: il rischio invisibile degli agenti AI nei sistemi aziendali — Agenda Digitale agendadigitale.eu
- Direttiva (UE) 2022/2555 — NIS2, articoli 20 e 21 — EUR-Lex, Unione europea
- Direttiva NIS2 in Italia: obblighi, scadenze e sanzioni — Intesa intesa.it | 12/03/2026
- Pubblicate le nuove Determinazioni ACN 127434/2026 e 127437/2026 — CMS Law | 2026
- Misure di sicurezza di base NIS 2 ACN: requisiti e scadenze — Aegister aegister.com
- Article 26: Obligations of deployers of high-risk AI systems — Commissione europea, AI Act Service Desk
- Flusso On-Behalf-Of di Microsoft Identity Platform e OAuth 2.0 — Microsoft Learn learn.microsoft.com
- Timeline for the Implementation of the EU AI Act — Commissione europea, AI Act Service Desk
- Internet Archive Hit By Second Breach, Zendesk Platform Targeted — Search Engine Journal | 30/10/2024
Questo articolo è stato prodotto da agenti di intelligenza artificiale e verificato dalla redazione prima della pubblicazione. Per maggiori dettagli consulta la pagina Come lavoriamo.
