Okta Agent SSO: identità di prima classe per agenti AI

Il 24 agosto 2026 Okta ha reso disponibile in general availability Agent SSO. La funzione porta lo standard aperto Cross App Access dentro il prodotto di identità usato da oltre 20.000 clienti, secondo l'annuncio ufficiale^[1].

Agent SSO stabilisce un modello di identità di prima classe per gli agenti AI al punto di connessione.

La funzione arriva inclusa nei piani core di Okta SSO a costo zero. Questo è un segnale di pricing preciso: Okta tratta l'identità dell'agente come componente base, il valore economico si sposta verso il livello Okta for AI Agents. Quel livello superiore scopre, onboarda, protegge e governa ogni agente dell'azienda.

L'agent identity gap che Okta descrive

Le aziende deployano agenti AI più velocemente di quanto riescano a governarli. Il 34% delle organizzazioni applica agli agenti AI gli stessi controlli di sicurezza dei lavoratori umani, secondo il report Okta AI Agents at Work 2026 ripreso da SecurityBrief^[2]. Il dato implica che due terzi delle organizzazioni non lo fanno. Quegli agenti operano fuori dal perimetro di policy definito per gli umani.

La maggior parte degli agenti raggiunge i dati aziendali tramite chiavi API statiche, grant OAuth isolati e integrazioni custom costruite applicazione per applicazione. Operano come traffico anonimo: privi di owner, privi di policy, privi di audit trail. Questo è il debito tecnico che si accumula quando la produzione precede l'hardening. Senza audit trail, un incidente non è ricostruibile a posteriori: manca il registro che lega l'azione a un'identità.

Il problema si moltiplica con la crescita delle popolazioni di agenti. Le aziende devono gestire tre popolazioni insieme: agenti costruiti internamente, agenti incorporati nel software acquistato e agenti deployati dai dipendenti fuori dall'approvazione centrale. Ogni popolazione ha un owner diverso. La terza, quella fuori dall'approvazione centrale, è la più difficile da inventariare perché nasce senza passare dal governance layer.

Come funziona Agent SSO a livello tecnico

Agent SSO si applica agli agenti che supportano Cross App Access. Quando un agente si connette a un'applicazione aziendale, Okta lo registra come identità di prima classe in Universal Directory accanto ai dipendenti umani.

Al posto delle credenziali memorizzate, il sistema emette token a vita breve e governati dall'identità. Gli amministratori assegnano, monitorano e aggiornano la policy dell'agente dalla stessa console usata per i dipendenti. La console unica riduce il costo operativo: non serve un secondo strumento per la popolazione degli agenti.

L'esempio citato da Okta riguarda Claude di Anthropic: i team di sicurezza governano il suo accesso in modo nativo. I dipendenti evitano di condividere credenziali statiche o approvare consensi ripetuti.

Il meccanismo di rischio che questo chiude

Le chiavi API statiche sono il vettore. Una chiave rubata concede accesso persistente, privo di scadenza e difficile da revocare in modo mirato. I token a vita breve riducono questa superficie perché scadono e restano legati a un'identità tracciabile. La scadenza limita la finestra di sfruttamento. Il legame con l'identità rende la revoca selettiva.

Resta un rischio che Agent SSO lascia aperto: il prompt injection. Un documento recuperato da un sistema di retrieval è un vettore di attacco con le stesse credenziali dell'utente.

L'identità governata risponde alla domanda su chi è l'agente. La validazione dell'input recuperato è un problema architetturale distinto, da affrontare a livello di pipeline RAG. La maggior parte delle architetture RAG in produzione tratta i documenti come input fidato. Questo è sbagliato. Un token a vita breve non cambia questo esito: l'agente autenticato esegue comunque l'istruzione ostile contenuta nel documento, con le proprie credenziali legittime.

Standardizzazione come vero moat

La mia posizione resta ferma: la standardizzazione dei protocolli sarà il moat competitivo nell'AI agentivo, più della performance dei modelli. Chi controlla il layer di comunicazione tra agenti controlla l'architettura.

Cross App Access è uno standard aperto, questo conta. Uno standard che esce dalla sfera di un singolo vendor riduce il rischio di lock-in architetturale. La specifica è uno standard da adottare, più che un prodotto vendor da valutare.

Okta guadagna comunque posizione: possiede l'implementazione di riferimento e il directory. La governance aperta dello standard limita il potere di quella posizione. Il limite regge finché la specifica resta governata fuori dal vendor. Se l'implementazione di riferimento anticipa lo standard, il vantaggio torna a Okta.

Tre domande per l'enterprise AI team

Prima di rinegoziare qualsiasi contratto, il team deve mappare la propria esposizione. Tre domande definiscono lo scope operativo.

1. Quanti agenti in produzione oggi si autenticano con chiavi API statiche prive di owner?
2. Quali agenti supportano Cross App Access e quali restano esterni allo standard?
3. La pipeline RAG tratta i documenti recuperati come input fidato oppure come input ostile?

Le risposte determinano quanto sei vicino al modello che Okta descrive. Una popolazione di agenti anonimi indica debito tecnico che matura in fretta. La prima domanda misura la superficie da migrare. La terza misura un rischio che questa release non copre.

Decisioni di procurement per il prossimo planning cycle

Decisioni per CTO e Head of Engineering nel prossimo planning cycle. Valutate quanto il vostro provider di identità supporta Cross App Access in modo nativo. Un provider ancorato a integrazioni custom eredita il debito che questo standard elimina.

Per il CFO il calcolo cambia. Agent SSO incluso a costo zero abbassa la barriera d'ingresso, il costo reale vive nel livello Okta for AI Agents e nel lavoro di migrazione. Il costo a costo zero è il token, non il progetto: la migrazione dalle chiavi statiche resta lavoro interno da stimare.

Per il Technology Procurement Committee il punto è la rinegoziazione. Un contratto identity firmato prima dell'era degli agenti merita una clausola sul supporto agli standard aperti.

Okta for AI Agents copre anche gli agenti esterni allo standard, secondo TechNode^[3]. Questa copertura è la leva che sposta il valore dal livello gratuito a quello a pagamento.

Il verdetto

Agent SSO è production-ready per gli agenti che parlano Cross App Access. Per tutto il resto la governance vive nel livello a pagamento, questa distinzione pesa nel budget.

L'architettura diventa un vantaggio competitivo quando lo standard resta aperto e governato fuori dal singolo vendor. Diventa una trappola quando l'implementazione di riferimento detta i termini del layer di comunicazione.

Il segnale di stabilità della general availability è reale, il lavoro di hardening resta a carico dell'azienda. Trattate questa release come una base, il grosso del lavoro sulla identità degli agenti AI resta interno.