La sicurezza degli AI Agents di Okta punta a risolvere la confusione nelle imprese
Okta ha individuato un avversario insolito per la sua iniziativa sulla sicurezza degli AI agent: la confusione dei clienti, non un altro fornitore di sicurezza. Il presidente e COO Eric Kelleher ha sostenuto questa tesi alla Goldman Sachs Communacopia + Technology Conference del 9 settembre 2026.
L’argomentazione riflette un mercato in cui le imprese desiderano software autonomo, ma faticano a definire cosa debba essere protetto. Un agent può riassumere e-mail, aggiornare un record di vendita, approvare un rimborso o gestire un intero flusso di lavoro finanziario. Ogni ruolo comporta autorizzazioni, rischi e requisiti di responsabilità diversi.
Okta vuole che l’identità diventi il livello organizzativo di questo disordine. Il suo framework pone tre domande: dove sono gli agent, a cosa possono connettersi e cosa possono fare? Microsoft persegue obiettivi analoghi attraverso Entra Agent ID e Agent 365, rendendo la distribuzione aziendale importante quanto la progettazione della sicurezza.
Questa concorrenza cambia il significato del messaggio di Okta. La confusione può aprire un mercato per un provider di identità indipendente, ma può anche rallentare gli acquisti e favorire le piattaforme integrate. Okta deve trasformare una narrativa di sicurezza urgente in implementazioni ripetibili, adozione misurabile e standard utilizzabili dai clienti tra fornitori diversi.
La sicurezza degli AI Agents di Okta parte da tre domande
La mossa immediata di Okta consiste nel ridurre un problema di sicurezza vasto alla scoperta degli agent, al controllo delle connessioni e all’autorizzazione.
Durante la conferenza di settembre, Kelleher ha descritto clienti che chiedevano aiuto a Okta dopo essersi imbattuti in rapporti allarmanti sugli agent autonomi. Questi acquirenti comprendono che gli agent introducono rischi, ma spesso non dispongono di un modello condiviso per valutarli.
La risposta di Okta è il suo Blueprint for the Secure Agentic Enterprise. L’azienda ha introdotto il framework a marzo e ha reso Okta for AI Agents generalmente disponibile il 30 aprile 2026. Il prodotto estende controlli di identità familiari al software autonomo e semi-autonomo.
La prima domanda, “Dove sono i miei agent?”, riguarda l’inventario e la titolarità. I dipendenti possono attivare strumenti senza un processo formale di distribuzione, mentre gli sviluppatori possono creare agent su numerose piattaforme cloud. I team di sicurezza non possono governare un agent che non riescono a identificare.
La funzionalità Agent Discovery di Okta è progettata per far emergere queste implementazioni nascoste. Secondo i dettagli sulla scoperta degli agent dell’azienda, rileva l’attività di consenso OAuth e identifica le connessioni che coinvolgono piattaforme agent non autorizzate.
Il consenso OAuth concede a un’applicazione il permesso di accedere a un altro servizio senza ricevere la password dell’utente. Questa comodità diventa rischiosa quando un dipendente autorizza un agent sconosciuto a leggere posta, file, calendari o record dei clienti.
Okta afferma che i segnali del browser possono rivelare l’applicazione client, la risorsa connessa e gli ambiti di autorizzazione richiesti. Gli amministratori possono quindi registrare l’agent, assegnargli un proprietario umano e applicare policy di base.
La seconda domanda, “A cosa possono connettersi gli agent?”, sposta l’attenzione dall’inventario ai percorsi di accesso. Un agent può interagire con applicazioni, API, database, strumenti o server Model Context Protocol. MCP è un’interfaccia standard che consente ai sistemi AI di accedere a strumenti e informazioni esterni.
Il blueprint di Okta include un gateway per mediare queste connessioni, la gestione sicura delle credenziali e la gestione dell’accesso alle API. Questi controlli sono pensati per sostituire credenziali ampie e persistenti con decisioni più circoscritte basate su identità, contesto e rischio.
La terza domanda, “Cosa possono fare gli agent?”, arriva al livello più difficile. Sapere che un agent può entrare in un sistema non rivela se possa leggere, scrivere, trasferire, approvare o eliminare informazioni.
Okta propone di registrare le singole chiamate agli strumenti e le decisioni di autorizzazione. Promuove inoltre Universal Logout come kill switch che revoca i token di accesso di un agent nei sistemi connessi.
Questa impostazione è importante perché un agent non è semplicemente un altro account dipendente. Può eseguire rapidamente molte azioni, combinare informazioni tra sistemi e modificare il proprio comportamento quando cambia il contesto circostante.
Si differenzia inoltre da un tradizionale service account, che di norma esegue un’attività automatizzata prevedibile. Un AI agent può selezionare strumenti, generare piani intermedi e agire tramite autorizzazioni delegate da un utente.
Le tre domande di Okta creano quindi una struttura utile per gli acquisti. Non dimostrano che ogni controllo sottostante funzioni su ogni piattaforma agent. Offrono ai responsabili della sicurezza un vocabolario comune per decidere cosa debba essere testato.
Questo vocabolario è il fondamento della strategia dell’azienda. Okta vuole che le imprese considerino la sicurezza degli agent un’estensione della governance dell’identità, non una categoria isolata di monitoraggio AI.
La confusione genera sia domanda sia ritardi
La stessa incertezza che porta i clienti a rivolgersi a Okta può anche prolungare le valutazioni e impedire che la sicurezza degli agent diventi un’attività prevedibile.
Kelleher ha definito la confusione il principale concorrente attuale dell’azienda nell’identità agentica. Gli acquirenti affrontano affermazioni concorrenti da parte di fornitori di sicurezza, provider cloud, sviluppatori AI e piattaforme di governance. Molti prodotti usano un linguaggio simile proteggendo però livelli diversi.
Un fornitore può analizzare i prompt alla ricerca di istruzioni dannose. Un altro può individuare identità macchina o credenziali esposte. Un terzo può controllare il traffico di rete, mentre un provider di identità stabilisce quale agent possa accedere a una specifica applicazione.
Queste funzioni possono integrarsi tra loro, ma le imprese devono comunque stabilire le responsabilità. Il team di sicurezza può controllare le policy di accesso, mentre gli sviluppatori sono proprietari dell’agent e le unità aziendali definiscono le azioni accettabili.
Gli acquisti diventano più difficili quando un’organizzazione non riesce a rispondere a domande basilari sulla propria implementazione. Un’azienda può sapere che i dipendenti usano assistenti AI senza sapere quali di essi dispongano di autorizzazioni applicative durature.
Anche le definizioni di agent restano incoerenti. Alcuni sistemi sono interfacce chat che raccomandano azioni. Altri eseguono flussi di lavoro dopo l’approvazione umana, mentre gli agent autonomi possono agire senza rivedere ogni passaggio.
Questa ambiguità influenza licenze e misurazione dei prodotti. Kelleher ha detto che Okta attualmente prezza la propria offerta agentica come maggiorazione del prezzo per utente. Ha riconosciuto che il modello è imperfetto per l’architettura agent, ma lo ha descritto come semplice da acquistare per i clienti.
Secondo le sue dichiarazioni alla conferenza, la maggior parte delle prime transazioni è costituita da accordi annuali. Okta prevede che entrambe le parti raccolgano informazioni migliori sull’uso degli agent e sui costi operativi prima dei rinnovi.
Questo approccio riduce l’attrito immediato negli acquisti. Rivela anche quanto il mercato sia ancora agli inizi. Una categoria di sicurezza matura dispone di solito di unità più chiare, come utenti, dispositivi, workload, transazioni o volume di dati protetti.
L’attività degli agent può attraversare tutte queste unità. Un dipendente può usare diversi agent, mentre un singolo agent può generare lavoratori temporanei o effettuare migliaia di chiamate agli strumenti. Un modello per utente può scollegarsi dal workload che viene protetto.
Il vantaggio di Okta è un rapporto già esistente con i team aziendali responsabili dell’identità. Kelleher ha dichiarato che oltre 20.000 aziende affidano già a Okta identità umane e non umane. Questa base installata offre un percorso diretto nelle discussioni sulla sicurezza.
Tuttavia, la fiducia non elimina il lavoro di implementazione. I clienti devono scoprire gli agent, classificarne gli scopi, identificarne i proprietari, ridurre le autorizzazioni eccessive e collegare le applicazioni pertinenti ai punti di enforcement.
I responsabili della sicurezza devono inoltre decidere quali azioni richiedano l’approvazione umana. Un agent di sintesi e un agent quote-to-cash non dovrebbero ricevere controlli identici, anche se entrambi usano la stessa piattaforma di identità.
Il secondo può coinvolgere prezzi, contratti, sistemi di fatturazione e record dei ricavi. Un errore potrebbe trasformarsi in un evento finanziario o di conformità, anziché in una risposta semplicemente scomoda.
Questa distinzione trasforma la confusione in un’opportunità di prodotto soltanto quando Okta è in grado di guidare l’implementazione. Un blueprint aiuta i clienti a porre domande migliori, ma sono i modelli operativi e le integrazioni a dover fornire le risposte.
Questo requisito mette sotto pressione le attività commerciali e i servizi professionali di Okta. Gli acquirenti si aspetteranno che l’azienda traduca un framework astratto di identità in controlli per flussi di lavoro reali.
Gli sviluppatori affrontano una sfida correlata. Hanno bisogno di modelli di accesso sicuro che non richiedano di ricostruire ogni agent per il sistema di identità di ciascun cliente. Ecco perché la strategia di standard di Okta è al centro della sua argomentazione di prodotto.
Cross App Access è la proposta di Okta per un livello di controllo aperto
Okta scommette che uno standard di autorizzazione aperto possa rendere portabile l’accesso degli agent, preservando al contempo i provider di identità come applicatori centrali delle policy.
Cross App Access, o XAA, è il metodo proposto da Okta per connettere gli agent alle applicazioni tramite autorizzazioni standardizzate. Estende concetti di OAuth e opera insieme a MCP, che fornisce agli agent un modo comune per scoprire e richiamare strumenti.
La distinzione è importante. MCP può descrivere uno strumento disponibile e supportare l’interazione, ma le imprese devono comunque decidere se uno specifico agent possa utilizzarlo. XAA è pensato per portare il contesto di identità e autorizzazione in quella connessione.
Kelleher ha dichiarato che Okta ha proposto Cross App Access come standard aperto, anziché come formato proprietario di Okta. Ha inoltre affermato che era stato accettato come estensione di MCP e stava attirando un ampio interesse nel settore.
Okta ha reso Agent SSO generalmente disponibile nell’agosto 2026. Agent SSO consente a un amministratore di registrare un agent come workload principal, ossia un’identità non umana gestita in modo indipendente.
Quando un agent supportato si connette a un’applicazione, Okta può inserirlo in Universal Directory accanto ad altre identità governate. Gli amministratori possono quindi visualizzare proprietà, connessioni e policy applicabili attraverso i processi di identità esistenti.
L’approccio tenta di risolvere una debolezza ricorrente nelle implementazioni agent. Molti agent iniziali prendono in prestito il token di accesso di un utente o si affidano a una credenziale statica memorizzata in un flusso di lavoro.
L’accesso preso in prestito può rendere poco chiara l’attribuzione. Se un agent modifica un record usando l’identità di un dipendente, un audit log potrebbe non distinguere l’azione del software da un’azione umana diretta.
Le credenziali statiche creano un altro problema. Possono rimanere attive più a lungo del necessario e comparire in file di configurazione, log o ambienti di sviluppo. Un segreto esposto può fornire a un attaccante un accesso persistente.
Un’identità dedicata dell’agent separa l’attore dal suo sponsor. Il proprietario aziendale resta responsabile, ma il sistema di sicurezza può applicare policy diverse all’agent e alla persona.
Questa separazione favorisce il principio del privilegio minimo, che limita un’identità all’accesso minimo necessario per il compito assegnato. Può inoltre supportare token di durata più breve e una dismissione più chiara quando un agent viene ritirato.
Okta afferma che Auth0 for AI Agents può aiutare gli sviluppatori a creare agent che funzionano con XAA. Questi agent possono memorizzare credenziali presso diversi provider di identità, anziché richiedere un ambiente esclusivamente Okta.
L’apertura rafforza la proposta di Okta verso i clienti preoccupati dal lock-in della piattaforma. Un’impresa può utilizzare agent di Microsoft, Google, Salesforce, team di sviluppo interni e fornitori minori nello stesso ambiente.
Un livello di autorizzazione portabile consentirebbe a tali agenti di incontrare decisioni di accesso coerenti. Potrebbe inoltre ridurre il lavoro di integrazione personalizzata per gli sviluppatori che vendono a imprese con sistemi di identità diversi.
Tuttavia, uno standard pubblicato non crea automaticamente interoperabilità. Le applicazioni devono implementarlo, i framework agentici devono trasportare il contesto richiesto e i provider di identità devono interpretare le richieste in modo coerente.
I team di sicurezza devono inoltre fidarsi dei metadati utilizzati in ogni decisione. Un agente può possedere un'identità valida pur ricevendo istruzioni manipolate o selezionando un'azione non sicura.
L'identità risponde alla domanda su chi o cosa stia richiedendo l'accesso. Non determina autonomamente se un piano generato sia accurato, etico o allineato con gli obiettivi aziendali.
Il meccanismo di Okta è quindi significativo, ma circoscritto. XAA può rendere l'autorizzazione più esplicita e verificabile. Non può sostituire le salvaguardie dei modelli, la governance dei dati, i controlli di rete o la convalida a livello applicativo.
L'azienda trae vantaggio se XAA diventa uno standard di connessione neutrale. Subisce una pressione maggiore se le piattaforme agentiche mantengono l'applicazione delle policy di identità all'interno dei propri piani di controllo integrati.
Questa pressione è già visibile nell'espansione dello stack di identità per agenti di Microsoft.
Microsoft Trasforma la Sicurezza delle Identità in una Sfida di Distribuzione
La principale sfida competitiva di Okta è la capacità di Microsoft di integrare l'identità degli agenti con le applicazioni, i servizi cloud e gli strumenti amministrativi già in uso nelle imprese.
Microsoft Entra Agent ID è diventato generalmente disponibile nell'aprile 2026. Fornisce costrutti di identità, autenticazione, autorizzazione, governance e controlli di sicurezza progettati per gli agenti AI.
L'argomento di fondo somiglia molto a quello di Okta. Gli agenti dovrebbero avere proprietari identificabili, cicli di vita gestiti, accessi limitati e attività verificabili. Microsoft supporta inoltre OAuth, MCP e protocolli agent-to-agent.
La differenza sta nella distribuzione. Microsoft controlla un'ampia raccolta di applicazioni aziendali, servizi per sviluppatori, infrastruttura cloud, piattaforme dati e prodotti di sicurezza.
Agent 365 funge da catalogo unificato e livello di gestione dell'azienda. Entra fornisce la base di identità sottostante, secondo la documentazione sull'identità degli agenti di Microsoft.
Microsoft può collegare un'identità agente a Conditional Access, Identity Protection, Microsoft Graph e al proprio più ampio ambiente di governance. I clienti che operano già all'interno di questo stack potrebbero preferire un'esperienza amministrativa consolidata.
Un esempio pratico emerge nell'integrazione Dataverse di Microsoft. Un agente di sviluppo commerciale può ricevere un'identità dedicata e un ruolo limitato per leggere lead, registrare attività di contatto e aggiornare record idonei.
Gli amministratori possono escludere tabelle non correlate o campi sensibili. Le azioni restano attribuibili all'agente anziché apparire sotto un account condiviso di dipendente o applicazione.
Questo scenario dimostra il rischio strategico per Okta. Microsoft non deve vendere l'identità degli agenti come categoria separata quando può incorporare la governance nell'applicazione in cui si svolge il lavoro.
La risposta di Okta è l'indipendenza. Il suo valore aumenta quando un'impresa utilizza più cloud, strumenti di creazione di agenti ed ecosistemi software. Un livello di identità neutrale può offrire policy coerenti oltre tali confini.
Kelleher ha sottolineato che l'identità agentica combina caratteristiche dell'identità umana e non umana. Okta gestisce già entrambe le categorie, acquisendo esperienza nella governance del ciclo di vita, nell'accesso alle applicazioni e nei segnali di sicurezza.
Anche il suo catalogo di integrazioni offre all'azienda un punto di partenza sostanziale. Okta ha dichiarato a marzo che la sua rete includeva oltre 8.200 integrazioni, con il supporto agli agenti che coinvolgeva Boomi, DataRobot e Google Vertex AI.
Questa ampiezza conta solo se le integrazioni offrono un'applicazione effettiva delle policy. Una voce di catalogo che registra un agente è diversa da una che autorizza singole chiamate a strumenti e supporta una revoca rapida.
Microsoft affronta lo stesso test all'interno del proprio ecosistema. L'identità centralizzata può descrivere le autorizzazioni, ma le applicazioni devono applicarle correttamente durante flussi di lavoro rapidi e in più fasi.
Altri fornitori di sicurezza aggiungono un ulteriore livello di concorrenza. Le aziende specializzate nell'accesso privilegiato possono gestire credenziali sensibili, mentre i fornitori di sicurezza per endpoint e cloud possono analizzare il comportamento attorno a un agente.
Gli specialisti della sicurezza AI possono concentrarsi su prompt injection, selezione non sicura degli strumenti, fuga di dati e comportamento dei modelli. Queste minacce non scompaiono dopo che l'agente riceve un'identità dedicata.
La probabile architettura aziendale includerà più livelli di controllo. La questione contesa è quale piattaforma diventi il luogo centrale per proprietà, policy e indagini.
Okta vuole che quel luogo sia il tessuto di sicurezza delle identità. Microsoft vuole che Agent 365 ed Entra forniscano un piano di controllo unificato, soprattutto tra le applicazioni Microsoft.
I clienti valuteranno queste affermazioni in ambienti eterogenei. Una piattaforma che governa solo i propri agenti nativi lascerà ai team di sicurezza inventari e policy frammentati.
L'indipendenza di Okta offre una risposta credibile alla frammentazione. La profondità di integrazione di Microsoft offre una risposta credibile alla complessità operativa.
Questa è la principale sfida dell'articolo: un livello di identità neutrale contro un piano di controllo integrato per applicazioni e cloud. La confusione aiuta Okta ad avviare la conversazione, ma l'interoperabilità determinerà chi la controllerà.
I Controlli di Identità Non Possono Giudicare l'Intento di un Agente
Okta può limitare ciò a cui un agente è autorizzato ad accedere, ma credenziali valide non garantiscono un ragionamento sicuro o un'azione corretta.
Un agente può autenticarsi con successo e restare entro un perimetro di autorizzazioni approvato, pur causando danni. Può interpretare erroneamente una richiesta, seguire un'istruzione dannosa o combinare azioni consentite in un risultato imprevisto.
Il prompt injection illustra questa lacuna. Un attaccante può inserire istruzioni nascoste o fuorvianti nel contenuto letto da un agente. L'agente può trattare tali istruzioni come parte del proprio compito.
I controlli di identità possono limitare il conseguente raggio d'impatto. Non possono sempre riconoscere che il processo decisionale dell'agente è stato manipolato.
La stessa limitazione si applica a una pianificazione errata. Un agente finanziario autorizzato potrebbe selezionare il conto sbagliato, duplicare un'azione o applicare una regola di approvazione alla transazione errata.
Un kill switch diventa prezioso dopo il rilevamento di un comportamento sospetto. Tuttavia, gli agenti autonomi possono eseguire molte azioni prima che un essere umano riconosca lo schema e revochi l'accesso.
L'autorizzazione in fase di esecuzione cerca di restringere questa finestra. Anziché concedere un accesso permanente e ampio, un sistema valuta le singole richieste utilizzando identità, contesto, rischio e azione prevista.
La qualità di tale valutazione dipende da un contesto affidabile. Le policy devono distinguere le variazioni ordinarie dai comportamenti non sicuri senza bloccare flussi di lavoro legittimi.
Le organizzazioni necessitano inoltre di log affidabili. Registrare le chiamate agli strumenti di un agente aiuta gli investigatori a ricostruire gli eventi, ma i log devono collegare l'agente, lo sponsor umano, l'istruzione, la decisione di autorizzazione e la modifica risultante.
Un record che mostra solo una chiamata API riuscita offre una responsabilità limitata. I team di sicurezza devono sapere perché l'agente ha chiamato l'API e quali dati hanno orientato la sua decisione.
Le funzionalità di system log e governance di Okta affrontano parti di questa catena. L'azienda afferma che chiamate agli strumenti, tentativi di accesso e decisioni di autorizzazione possono confluire nei sistemi di gestione delle informazioni e degli eventi di sicurezza.
Queste capacità restano affermazioni dell'azienda finché i clienti non le testano su framework e applicazioni agentiche diversi. L'annuncio di Okta stessa avverte inoltre che funzionalità non rilasciate potrebbero arrivare in ritardo o non arrivare affatto.
Le evidenze indipendenti restano limitate perché le implementazioni aziendali di agenti sono ancora giovani. La ricerca accademica ha iniziato a esaminare la gestione delle identità per i sistemi agentici, ma i benchmark di produzione sono ancora in fase di sviluppo.
Un'ulteriore preoccupazione riguarda la qualità della proprietà. Assegnare uno sponsor umano crea responsabilità sulla carta, ma quella persona deve comprendere dati, autorizzazioni, dipendenze e condizioni di dismissione dell'agente.
La proprietà può diventare cerimoniale quando le organizzazioni implementano agenti più rapidamente di quanto i responsabili riescano a esaminarli. Le certificazioni di accesso rischiano quindi di diventare un'altra coda di approvazioni con contesto insufficiente.
La proliferazione degli agenti peggiora il problema. Un agente principale può creare sottoagenti temporanei per ricerca, analisi o esecuzione. La policy di sicurezza deve determinare se tali identità temporanee ereditino autorizzazioni.
Un'ereditarietà ampia è facile da amministrare ma aumenta l'esposizione. Richiedere un'approvazione separata per ogni agente di breve durata può compromettere la velocità che rende attraenti i flussi di lavoro agentici.
Questo è il compromesso centrale nella sicurezza degli agenti AI di Okta. Le imprese vogliono che gli agenti operino rapidamente tra i sistemi, mentre i team di sicurezza devono fare in modo che ogni azione resti circoscritta, attribuibile e reversibile.
Troppo poco controllo crea un rischio inaccettabile. Troppa frizione trasforma un flusso di lavoro autonomo in una lenta serie di approvazioni umane.
Le implementazioni più solide inizieranno con compiti circoscritti e confini espliciti per i dati. Un agente di assistenza potrebbe classificare i ticket prima di ricevere il permesso di emettere crediti o modificare i record dei clienti.
I team dovrebbero testare i percorsi di errore, non solo le dimostrazioni riuscite. Hanno bisogno di evidenze che mostrino come il sistema gestisca proprietà scaduta, input manipolati, autorizzazioni eccessive e servizi di applicazione delle policy non disponibili.
Una knowledge base ricercabile può aiutare i team a documentare proprietari, policy e decisioni sugli incidenti. Non sostituisce il controllo degli accessi, ma preserva il contesto necessario ai revisori.
La strategia di Okta diventa più convincente quando i clienti possono collegare le decisioni di identità a privilegi ridotti e a un contenimento più rapido degli incidenti. I soli annunci di prodotto non possono dimostrare tale risultato.
Tre Segnali Mostreranno se la Spinta di Okta Sta Funzionando
L'adozione degli standard, l'espansione dei clienti e l'applicazione delle policy multipiattaforma determineranno se Okta trasformerà la confusione in una categoria duratura di sicurezza delle identità.
Il primo segnale è l'adozione di Cross App Access oltre i prodotti di Okta stessa. Gli sviluppatori di agenti, i fornitori di applicazioni e i provider di identità concorrenti devono implementare il protocollo perché diventi un'infrastruttura significativa.
Okta ha dichiarato durante la conferenza di settembre che erano imminenti annunci più ampi. Il dettaglio importante non sarà il numero di partner nominati. Gli acquirenti dovrebbero esaminare quali azioni tali integrazioni possano effettivamente autorizzare.
Il supporto alla registrazione fornisce inventario. Il supporto a un'autorizzazione circoscritta e contestuale fornisce controllo. Il supporto a una revoca rapida fornisce contenimento quando un agente devia dal proprio ruolo previsto.
Un insieme crescente di integrazioni funzionanti rafforzerebbe l'argomento di Okta come piattaforma neutrale. Un'adozione limitata lascerebbe XAA come funzionalità utile nell'ambiente Okta anziché come livello di controllo del settore.
Il secondo segnale è la natura dei rinnovi e delle espansioni dei clienti. Kelleher ha affermato che la maggior parte delle prime transazioni agentiche utilizza contratti di un anno, offrendo a clienti e Okta il tempo per comprendere l'utilizzo.
Tali rinnovi riveleranno se le imprese andranno oltre la fase di valutazione. Gli acquirenti dovrebbero cercare implementazioni che governino agenti di produzione in diversi processi aziendali, non dimostrazioni isolate.
L'espansione verso piattaforme di agenti aggiuntive sosterrebbe l'affermazione che l'identità offra un piano di controllo comune. Una crescita legata solo a progetti sperimentali suggerirebbe che la confusione resti una barriera alle vendite.
Il pricing fornirà un altro indizio. L'aumento per utente di Okta semplifica gli acquisti iniziali, ma il volume e l'attività degli agenti non seguono necessariamente il numero dei dipendenti.
Il modello potrebbe evolvere verso agenti protetti, connessioni, transazioni o eventi di autorizzazione. Qualsiasi cambiamento rivelerà ciò a cui i clienti attribuiscono valore e quali costi operativi contano di più.
Un modello stabile e comprensibile contribuirebbe alla maturazione della categoria. Una tariffazione complessa basata sull’utilizzo potrebbe reintrodurre l’incertezza che il blueprint di Okta è progettato per eliminare.
Il terzo segnale è la risposta competitiva di Microsoft e di altri fornitori di identità. Il modello Agent 365 di Microsoft combina già un inventario unificato con identità e governance supportate da Entra.
Se Microsoft estenderà una governance semplice agli agenti di terze parti, la rivendicazione di indipendenza di Okta sarà sottoposta a una prova diretta. Se Microsoft resterà più forte nel proprio ambiente, Okta avrà più spazio nelle imprese eterogenee.
I clienti dovrebbero confrontare l’applicazione delle policy tra Microsoft 365, Google Workspace, Salesforce, piattaforme cloud e applicazioni personalizzate. Il vincitore dovrà offrire più di un elenco centrale degli agenti.
Dovrà preservare l’identità degli agenti oltre i confini tra applicazioni, applicare il principio del privilegio minimo, rendere visibile la proprietà e revocare gli accessi in modo coerente. Dovrà inoltre fornire prove utilizzabili dai team di sicurezza durante indagini e audit.
Il supporto dei concorrenti a standard comuni convaliderebbe la tesi più ampia di Okta, anche se riducesse la differenziazione del prodotto. Approcci proprietari trasformerebbero l’identità degli agenti in un ulteriore confine di piattaforma.
Il messaggio di Okta alla conferenza merita attenzione perché evita di trattare la sicurezza degli agenti AI come una singola funzionalità di rilevamento. L’azienda sta inquadrando il problema attorno alla responsabilità e all’accesso lungo l’intero ciclo di vita di un agente.
Questa impostazione corrisponde alla sfida operativa. Un’impresa deve sapere chi ha creato un agente, perché esiste, quali risorse può raggiungere e come fermarlo.
Tuttavia, l’identità è uno dei diversi piani di controllo. Restano necessari protezioni del modello, validazione delle applicazioni, monitoraggio della rete, governance dei dati e revisione umana.
Gli acquirenti di soluzioni di sicurezza dovrebbero quindi trattare il blueprint di Okta come un quadro di test. Possono chiedere a ciascun fornitore di dimostrare discovery, autorizzazione, proprietà, logging e revoca lungo un flusso di lavoro reale.
La prova migliore arriverà da un’implementazione in produzione deliberatamente vincolata. I team possono iniziare con un agente che legge informazioni limitate e propone azioni per l’approvazione umana.
Possono quindi misurare richieste di autorizzazioni eccessive, dinieghi delle policy, tempi di indagine e accuratezza della dismissione. Questi risultati rivelano più di una raffinata dimostrazione autonoma.
La sicurezza degli agenti AI di Okta è in definitiva una scommessa sul fatto che le imprese non gestiranno software autonomo tramite credenziali disperse e controlli isolati. Il mercato si sta muovendo verso identità dedicate, proprietà esplicita e autorizzazione continua.
La questione irrisolta è chi fornirà questo livello nei contesti misti. Osservate prima le integrazioni XAA, poi i rinnovi in produzione e infine la portata di Microsoft verso le terze parti.
Se Okta avanzerà su tutti e tre i fronti, la confusione si trasformerà in una duratura opportunità nell’ambito dell’identità. Se l’adozione resterà frammentata, le piattaforme integrate manterranno il vantaggio.
Per i team aziendali, il prossimo passo è pratico: selezionare un agente, mappare ogni connessione e documentare ogni azione consentita. Poi chiedersi se il sistema di identità attuale sia in grado di vedere, limitare, verificare e revocare quell’agente senza interventi personalizzati.
