Che cosa sono le Non-Human Identity e come gestirle nell’era degli agenti AI

In questo articolo

Le Non-Human Identity esistevano molto prima dell’intelligenza artificiale. Ogni volta che un software gestionale si collega a un database, un sistema esegue un backup automatico, un sito richiama un servizio di pagamento o un sensore invia dati al cloud, utilizza un’identità digitale per farsi riconoscere e ottenere le autorizzazioni necessarie.

La NHI è il “badge aziendale” di applicazioni, dispositivi e processi automatici. L’AI non introduce quindi una categoria completamente nuova: ne accelera la crescita e ne modifica il comportamento. Le NHI tradizionali eseguono in genere attività predefinite e relativamente prevedibili. Un agente AI può invece scegliere quali strumenti utilizzare, interrogare più servizi, concatenare azioni e operare a velocità macchina in base al contesto. L’effetto riguarda sia la quantità sia la complessità: aumentano identità, token e permessi da governare, mentre il loro utilizzo diventa più dinamico.
Per questo l’AI trasforma un problema IAM già esistente in una priorità di sicurezza e governance.

Una Non-Human Identity è l’identità digitale con cui un’entità software si autentica e ottiene accesso a sistemi, dati o servizi. Rientrano in questa categoria, ad esempio, service account, service principal, workload identity, managed identity, API, dispositivi IoT e agenti AI. Queste identità possono utilizzare credenziali come API key, token OAuth, certificati digitali, password applicative e secret crittografici.

È importante distinguere i tre elementi della catena:

• la NHI identifica il soggetto che agisce
• la credenziale ne dimostra l’identità
• i permessi stabiliscono quali risorse e operazioni può utilizzare.

Microsoft include tra le workload identity applicazioni, service principal e managed identity, mentre OWASP evidenzia come le identità applicative possano autenticarsi verso servizi interni o piattaforme SaaS di terze parti. Gli agenti AI ampliano ulteriormente il perimetro perché possono scegliere gli strumenti, richiamare le API ed eseguire azioni in modo dinamico.

La differenza principale? Riguarda il grado di autonomia. Un’identità umana agisce attraverso una persona, una NHI tradizionale esegue una logica predefinita, mentre un agente AI può scegliere gli strumenti e concatenare azioni in funzione del contesto.

*Per pipeline si intendono processi automatizzati che verificano, preparano e distribuiscono gli aggiornamenti software
**Per sponsor umano si intende la persona aziendale che autorizza lo scopo dell’agente AI, ne approva l’accesso a dati e strumenti e verifica periodicamente che la sua attività sia ancora necessaria e coerente con le policy aziendali.

Perché l’intelligenza artificiale amplifica problemi già presenti nella gestione delle identità come scarsa visibilità, credenziali persistenti, privilegi eccessivi e responsabilità poco definite.

Un agente AI può utilizzare le API, interrogare i database, accedere a piattaforme SaaS e concatenare più strumenti nello stesso workflow, con una velocità superiore rispetto ai processi manuali. Il rischio aumenta quando l’agente opera attraverso un account condiviso, eredita tutti i permessi dell’utente o utilizza token privi di scadenza e owner.

Un’indagine CSA condotta su 383 professionisti IT e security ha rilevato che il 78% delle organizzazioni non dispone di policy formalizzate per creare e rimuovere le identità AI, mentre il 92% esprime scarsa fiducia nella capacità degli strumenti IAM legacy di gestirle.
Solo il 14% automatizza completamente provisioning e offboarding. Un prompt injection può inoltre spingere un agente con privilegi eccessivi a utilizzare impropriamente strumenti e credenziali.

La discovery delle Non-Human Identity deve coinvolgere più fonti, perché molte identità macchina non compaiono nelle directory utilizzate per gli account umani. L’IT Manager dovrebbe correlare i dati provenienti da piattaforme IAM e PAM, cloud provider, secrets vault, repository, sistemi SaaS e registri delle applicazioni OAuth.

Per ogni NHI occorre registrare:

• Identificativo
• tipologia
• applicazione associata
• owner tecnico
• sponsor umano
• scopo
• credenziali utilizzate
• risorse accessibili
• privilegi
• ambiente
• data di creazione
• ultimo utilizzo
• scadenza prevista

La mappatura permette di distinguere identità attive, obsolete, duplicate, condivise o prive di responsabile. La discovery deve diventare un processo continuativo: nuovi agenti, integrazioni e workflow possono infatti generare identità e token più rapidamente rispetto ai tradizionali cicli di revisione.
Prima di accedere ad ambienti di produzione, ogni agente AI dovrebbe quindi essere registrato, classificato e associato a responsabilità verificabili.

Approfondimento: qual è il legame tra Shadow AI e NHI?

La Shadow AI nasce quando dipendenti e team introducono strumenti, agenti o integrazioni AI al di fuori dei processi di governance aziendale. Ogni nuovo collegamento può generare API key, token OAuth, service account o identità assegnate agli agenti. Il risultato non è soltanto un’applicazione fuori catalogo, ma un insieme di NHI potenzialmente prive di owner, scadenza e controllo sui privilegi. La discovery dovrebbe quindi comprendere applicazioni SaaS, consensi OAuth, traffico API, log cloud e agenti creati attraverso piattaforme low-code o no-code.

Per approfondire cause e modalità di gestione, leggi il nostro articolo dedicato alla Shadow AI.

Un agente AI dovrebbe avere un’identità dedicata quando accede a dati, applicazioni o strumenti aziendali. In questo modo è possibile assegnare permessi coerenti con il suo scopo, sospenderlo senza coinvolgere altri servizi e ricostruire con precisione le azioni eseguite.

Se l’agente utilizza l’identità personale dell’utente o un account di servizio condiviso, eredita spesso autorizzazioni più ampie del necessario e rende meno chiara l’attribuzione delle responsabilità.

Quando l’agente agisce per conto di una persona, il sistema deve conservare entrambi i contesti, ovvero chi ha richiesto l’attività e quale agente l’ha eseguita. Per le operazioni ad alto impatto serve inoltre un’approvazione esplicita, associata alla specifica azione. Le identità dovrebbero essere separate tra sviluppo, test e produzione, utilizzare credenziali di breve durata e terminare insieme al deployment o al workflow per cui sono state create.

La gestione del ciclo di vita delle NHI inizia prima che l’identità acceda ai sistemi. Al momento del provisioning, ogni identità deve avere uno scopo dichiarato, un owner tecnico, uno sponsor umano, un ambiente di utilizzo, una durata prevista e permessi coerenti con il compito. Dove possibile, è preferibile utilizzare managed identity, workload identity federation e token temporanei al posto di secret statici.

Le credenziali ancora necessarie devono essere conservate in un vault e sottoposte a rotazione automatica. Durante la fase operativa occorre registrare ultimo utilizzo, risorse raggiunte e modifiche ai privilegi, affiancando revisioni periodiche degli accessi. La conclusione di un workflow, la dismissione di un’applicazione, il cambio di fornitore o owner e un periodo di inattività devono attivare la revoca. L’offboarding deve invalidare token, certificati e API key, rimuovere ruoli e policy ed eliminare i riferimenti presenti in pipeline e integrazioni.

Un controllo conclusivo verifica che non restino accessi orfani, riducendo i rischi OWASP legati a offboarding incompleto, secret esposti e credenziali troppo longeve.

Il principio del minimo privilegio richiede che ogni agente AI possa utilizzare esclusivamente le risorse necessarie per il compito assegnato. I permessi vanno definiti per singolo strumento, API o server MCP, distinguendo lettura, scrittura, modifica e cancellazione, oltre a dati, ambiente e durata dell’accesso.

Le autorizzazioni temporanee e just-in-time riducono l’esposizione rispetto ai privilegi permanenti e possono scadere al termine del workflow. Quando l’agente opera per conto di una persona, l’accesso effettivo dovrebbe corrispondere all’intersezione tra i permessi dell’utente, quelli dell’agente e quelli richiesti dal task. Operazioni ad alto impatto, come esportare dati, modificare configurazioni, cancellare record o avviare transazioni, richiedono un controllo aggiuntivo e un’approvazione esplicita. È inoltre opportuno separare decisione ed esecuzione: il modello propone l’azione, mentre un livello di policy deterministico verifica identità, contesto, ambito e rischio prima di autorizzarla.

Log e revisioni periodiche permettono infine di eliminare i privilegi inutilizzati e adeguare gli accessi all’evoluzione dell’agente.

Una prompt injection può indurre un agente AI a interpretare istruzioni malevole contenute in e-mail, documenti, pagine web o dati recuperati come parte del workflow. La prima contromisura consiste quindi nel trattare i contenuti esterni come dati non attendibili, separandoli dalle istruzioni operative.

I secret non devono comparire nel prompt, nella memoria dell’agente o negli output degli strumenti e i token e le credenziali vanno gestiti da componenti dedicati e forniti solo al momento dell’esecuzione. Ogni chiamata a strumenti e API dovrebbe rispettare una allowlist, uno schema di input definito e limiti su domini, risorse e operazioni consentite. Prima delle azioni ad alto impatto, un livello di autorizzazione indipendente dal modello deve verificare identità, permessi, contesto e finalità, richiedendo l’intervento umano quando necessario. È utile anche isolare sessioni e memoria, validare gli output e rilevare sequenze anomale di chiamate.

In questo modo, anche se il modello interpreta un’istruzione manipolata, l’architettura impostata a monte limita ciò che l’agente può eseguire.

Monitorare un agente AI vuol dire ricostruire l’intera catena che porta dalla richiesta iniziale all’azione eseguita. Ogni evento dovrebbe registrare l’identità dell’agente, la sua versione, l’utente o lo sponsor per conto del quale opera, il workflow, l’orario e l’ambiente coinvolto. Il log deve inoltre indicare lo strumento o l’API utilizzata, la risorsa raggiunta, l’operazione richiesta, la policy applicata, l’eventuale approvazione umana e l’esito. Per tutelare le informazioni sensibili, è opportuno conservare l’identificativo della credenziale o del token, evitando di registrarne il valore.

I dati devono confluire in un sistema centralizzato, protetto da alterazioni e integrato con SIEM e strumenti di incident response. L’impostazione di alert specifici è utile per segnalare accessi fuori orario, escalation di privilegi, volumi anomali, strumenti mai utilizzati prima o sequenze incompatibili con lo scopo dichiarato. Una tracciatura completa consente all’IT Manager di attribuire le responsabilità, individuare rapidamente l’origine di un incidente e revocare l’identità, il token o il singolo permesso coinvolto.

Il punto di partenza è trasformare le Non-Human Identity da componente tecnica “dispersa” a patrimonio governato.

Un assessment iniziale deve produrre una baseline verificabile e una roadmap basata sul rischio.

Le priorità sono:

• censire service account, API key, service principal, workload e agenti AI;
• classificare le identità per privilegi, dati raggiungibili, ambiente e criticità;
• assegnare a ogni NHI uno scopo, un owner tecnico e uno sponsor umano;
• sostituire progressivamente i secret statici con credenziali temporanee;
• applicare autorizzazioni granulari e approvazioni alle operazioni ad alto impatto;
• centralizzare log e alert per rilevare accessi e sequenze anomale;
• automatizzare provisioning, revisione periodica, revoca e offboarding

Un progetto pilota su un workflow AI rilevante permette di misurare identità prive di owner, secret persistenti e tempi di revoca prima di estendere il modello. L’obiettivo è rendere l’adozione dell’AI scalabile e riconducibile a responsabilità precise.

BeeCyber offre un modello evoluto di cyber security “as-a-service”, pensato per le aziende che vogliono rafforzare la propria sicurezza senza appesantire il reparto IT interno. Attraverso un approccio integrato che combina tecnologie avanzate, competenze specialistiche e monitoraggio continuo, supportiamo le imprese nella difesa dei dati, nella conformità normativa e nella continuità operativa.

Le percentuali riportate nell’articolo derivano dall’indagine CSA condotta online tra agosto e settembre 2025 su 383 professionisti IT e security. La ricerca, commissionata da Oasis Security, è stata pubblicata nel gennaio 2026.

• Cloud Security Alliance, The State of Non-Human Identity and AI Security, 26 gennaio 2026.
• Cloud Security Alliance, 79% of IT Pros Feel Ill-Equipped to Prevent Attacks Via Non-Human Identities, 27 gennaio 2026. Fonte delle percentuali e della metodologia dell’indagine.
• OWASP, Non-Human Identities Top 10 – 2025. Classificazione dei principali rischi legati alle NHI.
• OWASP, AI Agent Security Cheat Sheet. Controlli relativi a minimo privilegio, prompt injection, tool security, memoria, supervisione umana e monitoraggio.
• Microsoft Learn, What are workload identities?. Definizioni di workload identity, service principal e managed identity.
• Microsoft Learn, Che cosa sono le identità degli agenti?, 2026. Approfondimento sulle identità dedicate agli agenti AI e sul ruolo dello sponsor.
• Cloud Security Alliance, Who’s Behind That Action? The AI Agent Identity Crisis, 20 aprile 2026.
• Cloud Security Alliance, Agent Identity Governance Framework, bozza del 27 marzo 2026.
• NIST, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, concept paper in versione Initial Public Draft, 5 febbraio 2026.
• Cybersecurity360, Non-Human Identity e sicurezza dell’IA: quanto si rischia, 29 luglio 2026.