Una domanda a cui la maggior parte dei vertici aziendali non sa rispondere
Chiedete a un direttore tecnico o a un responsabile della sicurezza quanti dipendenti conti la propria organizzazione, e la risposta arriva immediata. Ponete la stessa domanda riguardo alle identità non umane presenti in questo momento nel loro ambiente, e nella maggior parte delle organizzazioni segue il silenzio. Account di servizio. Chiavi API. Token OAuth. Script di automazione. Credenziali delle pipeline CI/CD. E, sempre più spesso, agenti IA autonomi che accedono, agiscono e generano altri agenti di propria iniziativa.
Le ricerche di settore del 2026 convergono verso un quadro scomodo. A seconda dello studio, le identità non umane superano oggi quelle umane in un rapporto che va da 80 a 1 in un'azienda tipica fino a oltre 140 a 1 negli ambienti cloud-native, un rapporto che è approssimativamente raddoppiato in meno di due anni. Alcune analisi collocano il parco cloud medio di un'azienda oltre il quarto di milione di identità non umane, la grande maggioranza delle quali possiede più privilegi di quanto l'attività richieda realmente. Gli agenti IA rappresentano la fetta in crescita più rapida di questa popolazione, con una crescita prevista che supera ampiamente sia le identità macchina in generale sia l'organico umano.
Non si tratta di un dettaglio infrastrutturale marginale. È lo strato di identità che sta alla base di ogni trasformazione digitale, di ogni programma di adozione dell'IA e di ogni migrazione al cloud attualmente in corso, e per la maggior parte delle organizzazioni nessuno ne è responsabile end-to-end.
La verità scomoda: la categoria di "utente" in più rapida crescita nella vostra organizzazione in questo momento non è una persona. Non partecipa ad alcun processo di onboarding, non viene disattivata alla fine di un progetto e non compare in alcun organigramma. Semplicemente si accumula.
Come ci siamo arrivati: tre ondate di automazione
Le identità non umane non sono una novità. Ciò che è cambiato è il ritmo, l'autonomia e il livello di privilegio coinvolto.
Ondata 1: account di servizio e script
La prima ondata era semplice: un'operazione pianificata necessita di una credenziale di database, uno strumento di monitoraggio richiede accesso in lettura ai log, uno script di backup necessita di accesso in scrittura allo storage. Questi account venivano creati deliberatamente, di solito uno alla volta, e sebbene fossero spesso sovra-privilegiati e raramente rinnovati, almeno un essere umano aveva preso la decisione consapevole di crearne ciascuno.
Ondata 2: la proliferazione cloud-native e CI/CD
La seconda ondata è arrivata con i microservizi, i container e la distribuzione continua. Ogni servizio deve ora autenticarsi verso tutti gli altri. Ogni fase della pipeline necessita di credenziali proprie. I modelli di infrastructure-as-code generano nuovi ruoli e principal di servizio come semplice effetto collaterale di un deployment, spesso senza che nessuno esamini le autorizzazioni associate. È questa l'ondata che ha portato il numero di identità non umane da "superiore all'organico" a "superiore di diversi ordini di grandezza rispetto all'organico".
Ondata 3: l'IA agentica
La terza ondata sta avvenendo proprio ora, ed è qualitativamente diversa dalle prime due. Un agente IA non è una credenziale statica che riposa tranquillamente in un file di configurazione. È un attore autonomo che richiede autorizzazioni dinamicamente in fase di esecuzione, invoca API esterne di propria iniziativa, scrive ed esegue codice e, in architetture sempre più diffuse, genera sotto-agenti per completare parti del proprio compito. Un singolo assistente di programmazione IA, agente di deployment o bot per il servizio clienti approvato può generare una cascata di identità a valle che nessuno ha esplicitamente predisposto e che nessuno sta esplicitamente monitorando.
È a questo livello che la governance è rimasta più indietro rispetto alla realtà. Indagini di settore recenti rilevano che una quota significativa di organizzazioni non traccia affatto la creazione di identità legate all'IA, e una larga maggioranza dei responsabili della sicurezza ammette di non avere fiducia nella propria capacità di prevenire un attacco che ne sfrutti una.
Perché è un problema aziendale, non solo una nota a margine della sicurezza
È tentante archiviare la proliferazione delle identità non umane sotto la voce "compito del team di sicurezza". Questa impostazione sottovaluta l'entità dell'esposizione. Il tema si colloca esattamente all'intersezione tra architettura tecnologica, resilienza operativa e controllo dei costi, ed è esattamente per questo che merita di figurare nello stesso ordine del giorno della vostra strategia cloud e della vostra roadmap sull'IA, non in un raccoglitore di conformità separato.
Un problema di architettura
Il modo in cui progettate i vostri agenti IA, i vostri microservizi e la vostra infrastruttura cloud determina quante identità non umane create e quanto privilegio porta ciascuna di esse. I team che adottano l'IA agentica senza un'architettura di identità già predisposta stanno di fatto prendendo centinaia di decisioni ad hoc sul controllo degli accessi ogni settimana, senza alcun processo di revisione. Si tratta tanto di un fallimento nella progettazione tecnologica quanto di un fallimento della sicurezza, e lo riscontriamo ripetutamente quando esaminiamo gli ambienti cloud e le pipeline CI/CD dei nostri clienti.
Un problema di resilienza operativa
Il 2026 ha già offerto un promemoria: l'infrastruttura cloud da cui tutti dipendono non è infallibile. Un difetto nelle autorizzazioni della console di fatturazione di un grande hyperscaler ha esposto dati di costo e utilizzo cross-account a clienti che non avrebbero mai dovuto vederli. I regolatori europei hanno reagito designando formalmente i principali fornitori cloud come terze parti critiche soggette a vigilanza diretta sulla resilienza operativa, proprio perché una parte così ampia dell'economia, incluse vaste porzioni del settore finanziario, dipende ormai da una manciata di fornitori. Ogni identità non umana che la vostra organizzazione crea in questa infrastruttura condivisa è un filo che collega la vostra resilienza operativa alla loro. Più questi fili esistono senza un responsabile, più diventa difficile rispondere a una semplice domanda regolamentare: cosa accade alle nostre operazioni se questa credenziale, questo fornitore o questo prestatore di servizi venisse meno?
Un problema di costi
Ogni identità non umana non gestita, ogni account di servizio orfano, ogni agente IA che richiama silenziosamente un'API a pagamento in un ciclo di ritentativo, rappresenta anche un punto cieco nel controllo dei costi. I reparti finanziari segnalano sempre più spesso una spesa cloud legata all'IA cresciuta più rapidamente di quanto qualsiasi modello avesse previsto, in buona parte perché nessuno dispone di un inventario chiaro di cosa stia effettivamente chiamando cosa.
Un problema della catena di fornitura software
Lo stesso periodo ha visto emergere una catena di vulnerabilità critiche, ampiamente sfruttata, che colpisce centinaia di milioni di siti web costruiti su piattaforme comuni, oltre a un ciclo mensile di patch dei fornitori che ha affrontato ben oltre 500 vulnerabilità distinte. Ognuno di questi sistemi si autentica verso qualcos'altro tramite un'identità non umana. La gestione delle patch, le pratiche di sviluppo sicuro e la governance delle identità non sono tre discipline separate; sono tre angolazioni sulla medesima esposizione di fondo.
Come si presenta davvero un fallimento
I fallimenti legati alle identità non umane raramente somigliano a un attacco da film hollywoodiano. Appaiono banali, fino al momento in cui smettono di esserlo.
Scenario 1: l'assistente di programmazione sovra-privilegiato
Un team di sviluppo adotta un assistente di programmazione IA con accesso ai repository sorgente dell'organizzazione per accelerare le consegne, una decisione di per sé del tutto sensata. All'assistente viene concesso un token di accesso ampio "per evitare attriti", anziché uno limitato e specifico per il compito. Mesi dopo, un'integrazione mal configurata o un portatile di uno sviluppatore compromesso espone quel token. Poiché non è mai stato ridotto nell'ambito, il raggio d'azione non è un singolo repository, ma ogni repository a cui l'assistente poteva accedere, oltre a ogni segreto codificato al suo interno. Solo le scansioni dei repository pubblici nel 2025 hanno rilevato decine di milioni di segreti esposti, e gli strumenti di programmazione assistiti dall'IA hanno accelerato in modo misurabile questa fuga, proprio perché gli agenti sono rapidi nel trovare e riutilizzare credenziali davanti alle quali uno sviluppatore umano si sarebbe forse fermato.
Scenario 2: il sotto-agente silenzioso
Un'organizzazione distribuisce un agente autonomo per smistare e instradare i ticket dell'assistenza clienti. Per gestire un sottoinsieme di richieste, l'agente è progettato per generare un sotto-agente specializzato con accesso ai sistemi di fatturazione. Nessuno registra il sotto-agente come identità distinta, quindi esso eredita le ampie autorizzazioni del genitore anziché un insieme proprio e ristretto. Diciotto mesi dopo, un audit interno scopre che il sotto-agente è stato attivo per tutto quel tempo, che le sue autorizzazioni non sono mai state riesaminate e che nessuno nell'organizzazione può dire con certezza chi sia responsabile di ciò a cui ha avuto accesso.
Scenario 3: l'integrazione di terze parti dimenticata
Un reparto finanziario collega uno strumento di automazione dei fogli di calcolo a una piattaforma contabile cloud tramite una chiave API, generata una sola volta, durante una prova di concetto due anni prima. Il responsabile del progetto ha da allora lasciato l'azienda. La chiave funziona ancora. Non è mai stata rinnovata, mai limitata al solo accesso in lettura e mai collegata a un responsabile che ne avrebbe notato un uso improprio. È esattamente questo tipo di credenziale orfana che incidenti recenti presso grandi società di servizi professionali e piattaforme di assistenza hanno dimostrato essere attivamente ricercata dagli aggressori: non la porta principale, ma la porta di servizio che nessuno ricordava fosse rimasta sbloccata.
Perché la gestione tradizionale delle identità non risolve il problema
La maggior parte dei programmi di gestione delle identità e degli accessi è stata concepita attorno alle persone: qualcuno entra in azienda, un responsabile approva l'accesso, le risorse umane attivano l'offboarding e revisioni periodiche degli accessi individuano le derive. Applicate questo modello alle identità non umane, e crolla su quasi tutte le sue ipotesi.
- Non esiste un innesco delle risorse umane. Un account di servizio o un agente IA non viene "assunto" né "licenziato" tramite un processo che qualcuno monitora. Viene creato da uno script di deployment e spesso sopravvive al progetto, al team o persino al rapporto con il fornitore che lo giustificava.
- L'autenticazione a più fattori non si applica. A una macchina non si può chiedere un secondo fattore alle due del mattino. Le identità non umane si basano tipicamente su segreti statici, ed è esattamente per questo che la gestione dei segreti, non la politica delle password, è qui il controllo che conta.
- La responsabilità viene raramente assegnata al momento della creazione. Un account umano ha un proprietario nominato fin dal primo giorno. Un principal di servizio creato come effetto collaterale di un modello infrastrutturale spesso non ce l'ha, e quando qualcuno chiede "di chi è", la risposta onesta è spesso "nessuno lo sa".
- I privilegi vengono richiesti dinamicamente, non predisposti una volta per tutte. Un agente autonomo può acquisire nuove autorizzazioni in fase di esecuzione mentre concatena i compiti, il che significa che una revisione degli accessi effettuata oggi può risultare significativamente obsoleta nel giro di pochi giorni.
Un framework pratico di governance delle identità non umane
Collaboriamo con i clienti attraverso le funzioni tecnologiche e di sicurezza per colmare questo divario utilizzando un framework costruito attorno a cinque dimensioni pratiche, deliberatamente progettato affinché un team tecnologico e un team di sicurezza possano attuarlo congiuntamente anziché in flussi di lavoro separati.
Dimensione 1: scoperta e inventario
Non si può governare ciò che non si vede. Il punto di partenza è sempre un inventario completo: ogni account di servizio, chiave API, autorizzazione OAuth, principal di servizio e agente IA, su tutti gli account cloud, le piattaforme SaaS e i sistemi CI/CD in uso. La maggior parte delle organizzazioni che svolge questo esercizio per la prima volta rimane sorpresa, e raramente piacevolmente, dal numero risultante.
Dimensione 2: responsabilità e ciclo di vita
Ogni identità non umana dovrebbe avere un proprietario umano o un team nominato, uno scopo documentato e un ciclo di vita definito: una data di creazione, una data di revisione prevista e un innesco di deprovisioning legato al progetto o al sistema che supporta. Un'identità senza proprietario è un'identità di cui nessuno noterà l'uso improprio.
Dimensione 3: privilegio minimo e accesso just-in-time
Adottate per impostazione predefinita l'ambito più ristretto richiesto da un compito, e preferite credenziali di breve durata, predisposte just-in-time, rispetto a quelle statiche di lunga durata, ovunque l'architettura lo consenta. Per gli agenti IA in particolare, ciò significa limiti espliciti di autorizzazione per ciascun agente e sotto-agente, con le azioni ad alto impatto subordinate all'approvazione umana anziché concesse per impostazione predefinita.
Dimensione 4: gestione e rotazione dei segreti
Le credenziali codificate nel codice sorgente, nei file di configurazione o nelle pipeline CI/CD dovrebbero essere trattate come un incidente in attesa di accadere, perché i dati mostrano costantemente che è esattamente ciò che sono. Un caveau di segreti gestito, con rotazione automatizzata, colma la singola falla più ampia che osserviamo negli ambienti dei clienti.
Dimensione 5: monitoraggio e linee di base comportamentali
Il monitoraggio delle identità umane cerca accessi anomali. Il monitoraggio delle identità non umane deve cercare comportamenti anomali: un account di servizio che accede improvvisamente a dati al di fuori del suo schema abituale, un agente IA che invoca API mai utilizzate prima, una credenziale che si autentica da una posizione inattesa o con un volume inconsueto. È qui che il monitoraggio cyber e la governance dell'IA convergono davvero in un'unica capacità.
Da dove iniziare, in pratica
- Effettuate un rilevamento delle identità non umane sull'intero parco cloud e SaaS. Trattate il primo risultato come una linea di base, non come un obiettivo; l'importante è conoscere il numero reale prima di cercare di ridurlo.
- Individuate e correggete per prime le credenziali orfane. Gli account senza un proprietario chiaro rappresentano la correzione a rischio più elevato e sforzo più basso: disattivare, rinnovare o eliminare.
- Rendete obbligatoria d'ora in poi l'assegnazione della responsabilità. Nessun nuovo account di servizio, integrazione o agente IA dovrebbe essere predisposto senza un proprietario nominato e uno scopo documentato, imposto dal vostro processo di deployment, non da un documento di policy che nessuno legge.
- Integrate il deployment degli agenti IA nello stesso processo di governance di qualsiasi altro sistema di produzione. Se un nuovo microservizio richiederebbe una revisione architetturale, dovrebbe richiederla anche un nuovo agente IA con accesso ai sistemi.
- Distribuite un gestore di segreti se non lo avete già fatto. È uno dei passi con il rendimento più alto e la minore interruzione disponibile, e non dovrebbe attendere la progettazione di un programma più ampio.
- Estendete il monitoraggio al comportamento non umano, non solo agli accessi umani. Se il vostro attuale sistema di monitoraggio non è in grado di rispondere a "cosa ha fatto di diverso questo account di servizio questa settimana", è una lacuna che conviene colmare prima che venga messa alla prova da un incidente.
Il contesto lussemburghese ed europeo
Per le organizzazioni attive nei settori dei servizi finanziari, dell'amministrazione di fondi e dei servizi professionali in Lussemburgo, la governance delle identità non umane non è una buona pratica astratta: si interseca sempre più direttamente con le aspettative delle autorità di vigilanza. I requisiti di gestione del rischio ICT di DORA si applicano ai sistemi e alle credenziali da cui dipendono i vostri agenti IA e le vostre pipeline automatizzate, non solo alle applicazioni a cui i vostri dipendenti accedono manualmente. Mentre i regolatori europei formalizzano la vigilanza sui grandi fornitori cloud che ospitano gran parte di questa infrastruttura, e mentre la più ampia spinta dell'UE verso la sovranità tecnologica ridisegna dove i carichi di lavoro sensibili possono essere eseguiti, le organizzazioni che dispongono già di un inventario pulito e responsabilizzato delle proprie identità non umane sono semplicemente meglio posizionate per rispondere alle domande che un regolatore, un revisore o un assicuratore prima o poi porranno.
Lo stesso vale per il numero crescente di aziende lussemburghesi che accelerano l'adozione dell'IA, anche tramite il programma di sovvenzione SME Package AI. Un'implementazione IA ben governata e un parco di identità non umane ben governato sono, in pratica, lo stesso progetto visto da due angolazioni.
Tecnologia e sicurezza, non tecnologia o sicurezza
La governance delle identità non umane si colloca esattamente dove si colloca la nostra stessa attività: all'intersezione tra la costruzione della tecnologia (architettura cloud, pipeline DevSecOps, distribuzione di agenti IA) e la sua messa in sicurezza (governance delle identità, valutazione dei rischi, monitoraggio). Trattare questi aspetti come progetti separati condotti da team separati è esattamente il modo in cui le organizzazioni finiscono per ritrovarsi con 250.000 identità non gestite e nessuna risposta chiara alla domanda "di chi è la responsabilità".
Se la vostra organizzazione sta adottando agenti IA, sta ampliando la propria infrastruttura cloud, o semplicemente oggi non è in grado di dire quante identità non umane esistano nel proprio ambiente, è una conversazione che vale la pena avere prima che un audit, un incidente o un regolatore la impongano. Saremo lieti di aiutarvi a mappare l'esposizione e a costruire un programma di governance adatto al modo in cui i vostri team tecnologici lavorano realmente.
