Gli agenti di IA sono già dentro i tuoi sistemi e la tua strategia di identità non lo sa ancora
Entro la fine del 2026, il 40% delle applicazioni aziendali includerà agenti di IA con compiti specifici. Dodici mesi fa, quella cifra non raggiungeva il 5%. Il salto non è solo statistico: è strutturale. Milioni di identità non umane stanno operando in questo momento nelle reti aziendali con accesso a dati, sistemi e decisioni, e la maggior parte dei team di sicurezza sta ancora guardando il problema con gli strumenti sbagliati.
La gestione delle identità e degli accessi — ciò che il settore chiama IAM, dall'inglese Identity and Access Management — fu costruita per un mondo in cui gli attori del sistema erano persone. Qualcuno entra, gli viene assegnato un ruolo, il suo accesso viene verificato periodicamente e alla fine viene disconnesso. Il ciclo ha una logica umana perché fu progettato per gli esseri umani. Gli agenti di IA non entrano attraverso le risorse umane, non hanno un responsabile che approvi i loro permessi e non hanno nemmeno una data di disattivazione programmata. Ma hanno accesso. E quell'accesso, nella maggior parte delle organizzazioni, non è governato con lo stesso rigore di quello di qualsiasi nuovo dipendente.
Questo non è un problema tecnico secondario. È una crepa strutturale nel modo in cui le aziende comprendono chi — o cosa — opera all'interno dei loro sistemi.
L'inventario che nessuno possiede
Prima di parlare di controlli, c'è una domanda più fondamentale a cui poche organizzazioni riescono a rispondere con precisione: quanti agenti di IA stanno girando nei loro ambienti in questo momento, chi li ha distribuiti e cosa sono in grado di fare.
La risposta scomoda è che la maggior parte non lo sa. Secondo dati pubblicati da Gravitee, solo uno su sette agenti di IA che operano in ambienti produttivi ha ricevuto una revisione formale da parte del team di sicurezza prima di essere distribuito. Gli altri furono lanciati da team aziendali o di sviluppo con urgenza operativa, senza passare attraverso gli stessi filtri applicati a qualsiasi nuovo sistema. Il risultato è un ecosistema di identità non umane che accumulano permessi senza audit, operano sotto credenziali condivise e rimangono attive molto dopo che il flusso di lavoro che le aveva generate è cambiato o è scomparso.
Il problema non è nuovo in termini concettuali. Le identità non umane — account di servizio, chiavi API, script di automazione — già superavano in numero gli utenti umani nella maggior parte delle grandi aziende prima che gli agenti di IA entrassero nel panorama. Ciò che è cambiato è la velocità e l'autonomia. Un cluster Kubernetes può fornire migliaia di account di servizio in pochi minuti. Un agente di IA può interagire con più sistemi contemporaneamente, prendere decisioni in tempo reale e modificare il proprio comportamento in base al contesto. Non si tratta di un account di servizio passivo in attesa di un'istruzione. È un attore con capacità di giudizio propria all'interno dei tuoi sistemi.
Senza un inventario chiaro di quali agenti esistono, quale accesso hanno e chi ne risponde, qualsiasi conversazione sui controlli arriva in ritardo rispetto al problema. Non puoi governare ciò che non hai catalogato.
Come appare una violazione quando l'attore è una macchina
Il caso di Salesloft e Drift, avvenuto l'anno scorso, illustra con precisione il tipo di rischio che emerge quando i controlli di identità non coprono le integrazioni di IA. Degli aggressori compromisero token OAuth collegati al chatbot di Drift — un'integrazione di IA utilizzata da Salesloft — e accedettero agli ambienti Salesforce di oltre 700 organizzazioni. La violazione passò inosservata per giorni.
Il dettaglio che conta non è tecnico ma operativo: il team di sicurezza poteva vedere che il chatbot aveva accesso. Quello che non riusciva a vedere era cosa stesse facendo con quell'accesso in tempo reale. Dall'esterno, le query malevole erano indistinguibili dal comportamento legittimo del bot. Era un'identità non umana di fiducia che faceva esattamente quello che sembrava dover fare.
Quel pattern — accesso visibile, comportamento invisibile — è il nucleo del problema. I framework IAM tradizionali furono costruiti per rispondere alla domanda su chi ha accesso a cosa. Di fronte agli agenti di IA, la domanda che conta è cosa sta facendo quell'accesso in ogni momento, in quale contesto e con quale scopo. Sono domande diverse e richiedono strumenti diversi.
Il modello di controllo statico basato sui ruoli — assegni un ruolo, il ruolo definisce i permessi, i permessi vengono rivisti ogni trimestre — non fu progettato per attori che operano alla velocità di una macchina e modificano il loro comportamento in base al contesto. Hai bisogno di una valutazione continua del rischio, non di audit periodici. Hai bisogno che l'accesso scada automaticamente quando il compito termina, non che persista indefinitamente perché nessuno lo ha revocato.
I principi esistono da tempo. Il minimo privilegio, l'accesso just-in-time, i token effimeri che scadono da soli, l'integrazione con piattaforme di gestione degli accessi privilegiati. Nessuno di questi meccanismi è nuovo. Ciò che è nuovo è l'urgenza di estenderli a una classe di identità per cui non erano stati originariamente pensati, e farlo prima che il prossimo incidente compaia nel report trimestrale.
Ciò che le organizzazioni stanno rimandando e perché quel rinvio ha un costo
C'è una ragione per cui i team di sicurezza non hanno esteso i loro framework IAM agli agenti di IA con la stessa velocità con cui quegli agenti vengono distribuiti: il dispiegamento è guidato dai team aziendali e i team di sicurezza rispondono in un secondo momento.
L'asimmetria è strutturale. Un team di prodotto o di operations che trova in un agente di IA un modo per automatizzare un flusso di lavoro non ha incentivi a fermarsi e richiedere una revisione della sicurezza che può richiedere settimane. Il suo incentivo è il risultato operativo immediato. Il costo di non farlo — una violazione, un accesso non autorizzato, un agente compromesso — lo paga un altro team, più tardi, con un altro budget.
Quella distribuzione degli incentivi produce esattamente l'inventario caotico descritto in precedenza: decine o centinaia di agenti in esecuzione in produzione, molti senza un proprietario formale, con permessi che non sono mai stati rivisti e credenziali di cui nessuno sa quando scadono.
La soluzione non è rallentare il dispiegamento degli agenti. I guadagni in termini di produttività sono reali e le organizzazioni che restano indietro pagheranno quel costo in altro modo. La soluzione è integrare la governance delle identità nel processo di dispiegamento, non come un passo successivo ma come una condizione preliminare. Che nessun agente entri in produzione senza che qualcuno abbia risposto a tre domande fondamentali: a cosa ha accesso, chi risponde di quell'accesso e in quali condizioni quell'accesso scade.
Gartner ha identificato la mancanza di governance sulle identità degli agenti di IA come una delle tendenze di cybersecurity più critiche per il 2026. Non perché sia un problema nuovo nella sua logica, ma perché la velocità di adozione sta superando la velocità dei controlli. Il divario tra le due è dove vivono gli incidenti.
Il governatore mancante nella corsa verso l'IA operativa
La narrativa dominante sull'IA nelle aziende è centrata sulla capacità: cosa può fare un agente, quanto tempo risparmia, quanti processi automatizza. È una narrativa legittima. I numeri sulla produttività sono reali.
Ciò che quella narrativa lascia fuori è la domanda su chi risponde quando qualcosa va storto. E quando l'attore che fallisce non è un dipendente ma un agente con accesso a più sistemi, la domanda diventa più difficile a cui rispondere.
La riduzione dei costi derivante dalle violazioni che i framework di IA nell'IAM promettono — fino all'80% secondo alcuni studi del settore — non arriva da sola. Arriva quando qualcuno ha deciso che gli agenti di IA sono decisioni di identità prima di essere decisioni di ingegneria. Quando il team di sicurezza ha visibilità in tempo reale sul comportamento di ogni agente, non solo sui suoi permessi statici. Quando gli accessi scadono automaticamente e i flussi di attestazione sono continui, non annuali.
Le organizzazioni che stanno distribuendo agenti di IA senza quel livello di governance non stanno agendo in modo avventato per ignoranza. Stanno agendo in modo avventato perché la pressione a muoversi velocemente è reale e i controlli corretti richiedono investimenti, coordinamento e attrito deliberato nei processi di dispiegamento.
Quell'attrito, ben progettato, non frena l'adozione. La rende sostenibile. La differenza tra un programma di IA che scala in modo ordinato e uno che produce un incidente grave nel giro di diciotto mesi non sta nella qualità dei modelli né nell'ambizione dei casi d'uso. Sta nel fatto che qualcuno abbia avuto la conversazione sulle identità prima che il primo agente arrivasse in produzione.
