C’è un punto che molte aziende stanno ancora sottovalutando nell’ondata degli AI agent: non basta farli funzionare, bisogna anche sapere chi sono, cosa possono fare e per conto di chi agiscono. È qui che Okta vuole giocare una partita decisiva.
In una conversazione pubblicata da The Verge, il CEO di Okta Todd McKinnon ha spiegato che la prossima grande sfida dell’enterprise security non sarà solo autenticare persone e applicazioni, ma gestire l’identità degli agenti AI. Il punto è semplice da formulare e molto meno semplice da implementare: quando un software autonomo legge dati, avvia workflow, interroga sistemi interni o compie azioni dentro strumenti aziendali, serve un modello chiaro di autenticazione, autorizzazione e tracciabilità.
La tesi di Okta arriva in un momento in cui il mercato si sta riempiendo di agenti “operativi”: assistenti che aprono ticket, strumenti che generano report a partire da database interni, bot che prenotano meeting, aggiornano CRM o orchestrano processi fra più applicazioni. In teoria accelerano il lavoro. In pratica, se non c’è un layer di identity robusto, possono trasformarsi in un nuovo punto cieco della governance IT.
La scommessa di Okta: trattare gli agenti come nuovi soggetti digitali
Dal podcast di The Verge emergono alcuni elementi molto netti. McKinnon sostiene che gli agenti AI non vadano considerati come semplici feature dentro un’applicazione, ma come entità software con capacità operative proprie, da governare con regole simili — ma non identiche — a quelle usate per utenti umani e workload machine-to-machine.
Il CEO di Okta insiste in particolare su un problema: se un agente agisce a nome di un dipendente, bisogna distinguere con precisione l’identità dell’utente, l’identità dell’agente e l’ambito della delega. È una differenza sostanziale. Un conto è autorizzare una persona ad accedere a Salesforce; un altro è consentire a un agente di leggere opportunità commerciali, aggiornare alcuni campi del CRM e inviare un riepilogo su Slack, ma solo entro un perimetro definito e registrando ogni passaggio.
McKinnon, sempre nell’intervista, lega questo tema a un’idea precisa: l’AI renderà l’identity infrastructure ancora più centrale, non meno. In altre parole, più autonomia avranno gli agenti, più le aziende dovranno investire in controlli su who did what, anche quando quel “who” non è una persona in carne e ossa.
È un cambio di prospettiva che pesa. Per anni la sicurezza enterprise ha separato abbastanza nettamente tre categorie: utenti, applicazioni e automazioni. Gli agenti AI stanno erodendo questi confini. Possono ricevere istruzioni da un umano, prendere decisioni intermedie, chiamare API, manipolare documenti, attivare flussi. E ogni passaggio apre una domanda scomoda: chi è responsabile di quell’azione?
Permessi granulari: il nodo vero non è l’accesso, ma il perimetro
Qui il discorso si fa molto concreto. Parlare genericamente di “sicurezza degli agenti” serve a poco se non si traduce in policy operative.
Prendiamo un caso realistico: un agente collegato a Microsoft 365 e a un gestionale interno deve aiutare il team finance a recuperare fatture, verificare anomalie e preparare una bozza di report mensile. In un modello fragile, l’agente riceve un accesso troppo ampio ai documenti condivisi o alle API del sistema contabile. In un modello maturo, invece, gli vengono assegnati scope limitati: può leggere solo le cartelle del reparto finance, interrogare soltanto l’endpoint API relativo alle fatture degli ultimi 30 giorni e non può approvare pagamenti né modificare IBAN fornitori.
Questa granularità è il cuore del problema. Non basta dire che l’agente è “autenticato”. Bisogna definire quali azioni può compiere, su quali risorse, in quali condizioni e per quanto tempo.
Lo stesso vale per la delega. Se un dipendente autorizza un agente a lavorare sul proprio calendario e sulla posta, la delega non dovrebbe trasformarsi in accesso illimitato all’intera casella email. Un esempio tecnico più corretto sarebbe consentire all’agente di leggere solo i messaggi con una determinata etichetta, estrarre gli allegati da una cartella specifica e inviare email soltanto verso domini approvati dall’azienda, magari con un limite di volume e una finestra temporale definita. È un modello molto più vicino al least privilege che all’automazione “magica” promessa da tanti vendor.
Audit e responsabilità: il problema emerge quando qualcosa va storto
Finché l’agente risparmia tempo, tutto sembra filare liscio. Il tema vero arriva dopo.
Se un AI agent aggiorna in modo errato i dati di un cliente, scarica un documento riservato nel workspace sbagliato o invia un’informazione sensibile a un tool esterno non autorizzato, l’azienda deve poter ricostruire la catena degli eventi con precisione. Non un generico log applicativo, ma un audit trail che dica: quale agente ha agito, quale identità stava usando, chi aveva delegato il compito, quali token o credenziali sono stati impiegati, quali API sono state chiamate e con quale risultato.
Questo punto è centrale anche per la compliance. In settori regolati, dal finance alla sanità, non basta sapere che “il sistema” ha compiuto un’azione. Serve attribuzione. Serve contesto. Serve prova documentabile.
Non a caso, un secondo riscontro autorevole arriva da Microsoft. Nella documentazione ufficiale su Microsoft Entra e nelle linee guida sulla governance delle identità di workload e applicazioni, l’azienda insiste sulla necessità di gestire credenziali, permessi e monitoraggio continuo per identità non umane, incluse le automazioni che accedono a risorse cloud e dati aziendali. Con l’estensione di Copilot e degli agenti nei workflow enterprise, quel principio diventa ancora più critico: le identità machine e software non possono restare fuori dai meccanismi di access governance.
Anche Gartner, nelle sue analisi recenti sulla gestione delle machine identities, descrive l’esplosione delle identità non umane come una delle aree più delicate della sicurezza moderna. Il punto non riguarda solo il numero crescente di credenziali, certificati e token, ma il fatto che questi soggetti software interagiscono sempre più spesso con dati sensibili e sistemi business-critical.
Perché il tema arriva adesso
La spinta è tecnologica, ma anche di mercato. Negli ultimi mesi il settore ha visto una crescita rapida di startup, prodotti e piattaforme che promettono agenti capaci di eseguire task multi-step in ambienti enterprise. Non parliamo più solo di chatbot che rispondono a domande, ma di sistemi che agiscono: cercano informazioni, compilano campi, inviano richieste, fanno triage di ticket, orchestrano software diversi.
Ed è qui che Okta intravede un’opportunità strategica. Se l’adozione degli agenti continua, l’identità diventa un layer infrastrutturale obbligato. Un po’ come è successo con il cloud: all’inizio sembrava bastare collegare servizi e utenti; poi autenticazione centralizzata, SSO, MFA, provisioning e governance sono diventati elementi strutturali.
Con gli agenti AI potrebbe ripetersi uno schema simile, ma con una complessità aggiuntiva. Un agente non è un utente passivo e non è neppure una tradizionale integrazione server-to-server. Ha margini di iniziativa. Può interpretare obiettivi, scegliere azioni intermedie e concatenare strumenti diversi. Questo rende più sfumato il confine fra autorizzazione tecnica e responsabilità operativa.
Il rischio per le aziende: agenti efficienti, ma opachi
Il messaggio che arriva da Okta, letto in controluce, è più ampio di una semplice mossa di posizionamento prodotto. È un avvertimento al mercato enterprise.
Le aziende che introdurranno agenti senza un modello chiaro di identity rischiano di ritrovarsi con una nuova classe di soggetti digitali molto efficienti ma poco governabili. Un agente connesso a CRM, repository documentali e sistemi HR può fare risparmiare ore di lavoro. Può anche diventare un moltiplicatore di errori se riceve permessi eccessivi, se la delega non è contestualizzata o se l’audit non consente di capire dove si sia rotto il processo.
In concreto, il rischio operativo non è astratto. Basta immaginare un agente che, per “aiutare” il reparto acquisti, interroghi un database fornitori, recuperi contratti da un archivio cloud e invii automaticamente richieste di aggiornamento via email. Se il perimetro dei permessi è troppo largo, potrebbe esporre documenti a destinatari sbagliati. Se manca la separazione tra identità dell’utente e identità dell’agente, diventa difficile stabilire se l’azione sia stata approvata, suggerita o eseguita autonomamente. Se l’audit trail è incompleto, il team security si ritrova senza elementi affidabili per ricostruire l’incidente.
È per questo che la scommessa di Okta va letta con attenzione. Non solo come narrativa sull’AI, ma come indicazione di dove si sposterà una parte importante della sicurezza enterprise nei prossimi mesi: governare l’autonomia prima che l’autonomia diventi opacità.
E probabilmente il mercato scoprirà presto che l’identità degli agenti non è un dettaglio architetturale. È la condizione minima per fidarsi davvero di loro.
