Identità degli agenti IA: la domanda che ogni azienda ha saltato

La risposta breve: quando metti in funzione un agente IA nella tua azienda, ha bisogno di un'identità propria, esattamente come un dipendente ha bisogno di un account. La pratica comune oggi — inserire in modo fisso una chiave API statica nell'agente perché possa raggiungere i tuoi sistemi — è la cosa più pericolosa che tu possa fare, perché quella chiave non scade mai, nessuno sa chi la sta usando e non può essere revocata rapidamente quando serve. L'approccio corretto è dare a ogni agente un'identità registrata, permessi circoscritti e token a breve durata che scadono automaticamente.

È proprio ciò che Okta, uno dei maggiori fornitori al mondo di gestione delle identità, ha annunciato il 24 agosto 2026 con una nuova funzionalità chiamata Agent SSO. L'idea sembra semplice in superficie e ha conseguenze profonde: registrare l'agente IA come identità di prima classe nella directory aziendale, accanto ai dipendenti umani, così che sia soggetto agli stessi strumenti per concedere, monitorare e revocare gli accessi.

Perché questa domanda è diventata urgente proprio ora

Negli ultimi due anni l'IA aziendale è passata da «un bot che risponde alle domande» a «un agente che svolge il lavoro». L'agente di oggi apre il tuo CRM, legge gli ordini, aggiorna un record di magazzino, invia un messaggio a un cliente e può persino preparare una fattura. Ognuno di questi passaggi significa accedere a un sistema reale che contiene dati reali.

Il problema è che gli strumenti di sicurezza della maggior parte delle aziende sono stati costruiti su un unico presupposto: che chi accede ai sistemi sia un essere umano. Un dato sorprendente citato da Okta nel suo annuncio fotografa il divario: solo il 34% delle organizzazioni applica agli agenti IA gli stessi controlli di sicurezza che applica ai lavoratori umani. In altre parole, circa due terzi delle aziende fanno operare entità automatizzate nei propri sistemi senza lo stesso livello di governance.

Quando un agente non ha un'identità chiara, i problemi si accumulano e sono tutti dello stesso tipo: non sai quanti agenti operano nella tua attività, non sai chi ha autorizzato ciascuno, non puoi rispondere alla semplice domanda di un revisore — «chi ha eseguito questa azione?» — e non hai un unico pulsante da premere per fermare un agente che è andato fuori strada.

Che cosa fa davvero Agent SSO

Il servizio si basa su un protocollo aperto chiamato Cross App Access (XAA), un'estensione del noto standard OAuth, adottata come estensione ufficiale di autorizzazione gestita dall'azienda per MCP — il protocollo diventato la lingua comune tra agenti e sistemi. In breve, quando un agente IA che supporta questo protocollo tenta di connettersi a una delle tue applicazioni aziendali, succede quanto segue:

  • Registrazione: l'agente viene registrato come identità con un nome nella directory aziendale, non come chiave anonima.
  • Autorizzazione: riceve un token di accesso a breve durata che scade automaticamente, invece di una chiave statica conservata in un file di configurazione.
  • Governance: un amministratore gestisce i permessi dell'agente dalla stessa console usata per i permessi dei dipendenti.
  • Revoca istantanea: l'accesso dell'agente può essere interrotto con una sola azione nel momento in cui il suo comportamento appare anomalo.

Da notare che Okta ha incluso Agent SSO nella sua offerta principale di single sign-on senza costi aggiuntivi — un segnale che vuole diffondere questo modello come standard anziché venderlo come funzione premium. Il suo annuncio ha anche citato le aziende che collaborano con essa su questo approccio, tra cui Anthropic, Atlassian, Slack, Notion, Datadog e Figma.

La nuova regola: ogni agente IA che opera nella tua azienda deve avere un nome, un responsabile umano che ne risponda, permessi circoscritti e una data di scadenza. Esattamente come un dipendente.

Che cosa significa per un imprenditore in Arabia Saudita

In un anno che il Regno ha designato come Anno dell'Intelligenza Artificiale, le aziende si stanno muovendo rapidamente per introdurre agenti IA nel servizio clienti, nelle vendite e nelle operazioni. E il passaggio dal progetto pilota alla vera produzione è esattamente il momento in cui identità e permessi smettono di essere un dettaglio tecnico e diventano una preoccupazione centrale.

C'è anche una dimensione normativa. La Legge sulla protezione dei dati personali (PDPL) impone a un'organizzazione di controllare chi accede ai dati personali e per quale scopo, e di essere in grado di dimostrarlo in sede di audit. Se il tuo agente IA legge i dati dei clienti tramite una chiave condivisa che non appartiene a nessuno in particolare, di fatto non puoi rispondere alla domanda «chi ha avuto accesso a questi dati?» — e non si tratta solo di una debolezza tecnica, ma di una lacuna di conformità.

Passi pratici da cui partire oggi

Non ti serve una piattaforma globale per iniziare. Gli stessi principi valgono per qualsiasi sistema interno costruito correttamente:

  • Fai l'inventario dei tuoi agenti: elenca ogni strumento di IA collegato oggi ai tuoi sistemi — il numero ti sorprenderà.
  • Un account separato per ogni agente: non condividere mai l'account di un dipendente o una chiave generica tra più strumenti.
  • Privilegio minimo: se l'agente deve solo leggere, non concedergli il permesso di modificare o eliminare.
  • Token a breve durata: sostituisci le chiavi permanenti con token che scadono e si rinnovano automaticamente.
  • Una traccia di audit completa: ogni azione compiuta dall'agente viene registrata con il suo nome, l'orario e il sistema interessato.
  • Un responsabile umano: ogni agente ha un dipendente responsabile che ne rivede periodicamente i permessi e può fermarlo.
  • Approvazione umana per le operazioni sensibili: i trasferimenti finanziari, la cancellazione dei dati e i messaggi massivi ai clienti richiedono un punto di controllo umano.

Come la vediamo in Origami

Quando costruiamo un sistema su misura per un cliente e vi colleghiamo un agente IA, trattiamo quell'agente fin dal primo giorno come un utente con un account, dei permessi e un registro — non come uno script che gira con la chiave dell'amministratore. Questa semplice scelta architetturale evita al cliente una ricostruzione successiva e rende il sistema pronto per gli audit fin dall'inizio, invece di doverlo rattoppare alla prima domanda di un revisore o al primo incidente di sicurezza.

L'annuncio di Okta è importante perché trasforma quella che prima era una scelta discrezionale dei singoli sviluppatori in uno standard di settore sostenuto dai principali fornitori di strumenti. Chi costruisce oggi su queste basi si troverà automaticamente allineato con ciò che diventerà un requisito di base tra uno o due anni.

In sintesi: l'IA nella tua azienda non è più uno strumento che usi, è una parte che agisce per tuo conto. E qualsiasi parte che agisce per tuo conto ha bisogno di un'identità e di confini chiari — altrimenti stai gestendo un rischio che non puoi vedere.

Fonti