(2/3) La mappa migliore che abbiamo del problema dell'identità agentica
Nel primo post di questa serie ho spiegato perché l'IA agentica manda in pezzi lo stack dell'identità: ogni sistema che abbiamo costruito dà per scontato che ci sia un umano davanti alla tastiera, e gli agenti smontano quel presupposto il primo giorno. Avevo promesso la mappa più chiara del terreno che fossi riuscito a trovare. Eccola.
Quasi tutto ciò che oggi gira con l'etichetta «identità per l'IA» è un vendor che spiega perché la risposta è esattamente la cosa che quel vendor vende. Questo è l'opposto, ed è proprio per questo che mi fido. Identity Management for Agentic AI è stato preparato per l'OpenID Foundation, curato da Tobin South, scritto nell'arco del 2025 insieme all'AI Identity Management Community Group e alla Loyal Agents Initiative di Stanford, e rivisto da una lunga schiera di ingegneri dell'identità. È l'analisi di un organismo di standard, non una proposta commerciale. Ti dice cosa già funziona, cosa sta emergendo e — la parte rara — cosa nessuno ha ancora risolto. L'ho letto a fondo. Ecco cosa mi è rimasto.
Lo stack di oggi funziona — dentro una sola azienda, per un agente che aspetta
Il paper si divide nettamente in due: le soluzioni immediate per gli agenti che spediamo oggi, e i problemi futuri per gli agenti che stiamo per spedire. Il verdetto onesto sulla prima metà sta in una frase, e intorno a quella frase imposterei l'intero campo:
«Gli agenti e gli attuali pattern di autenticazione e autorizzazione possono funzionare per agenti sincroni che usano più strumenti all'interno di un singolo dominio di fiducia, ma non in contesti asincroni o multi-dominio.»
Rileggila due volte. Dentro una sola azienda, per un agente che agisce mentre tu aspetti, le fondamenta tengono. OAuth 2.1 con PKCE mette in sicurezza il flusso. Esternalizzi la decisione a un provider di identità o a un policy decision point invece di cablarla nel codice — la separazione fra Policy Enforcement Point e Policy Decision Point che il NIST ha messo nero su bianco dieci anni fa. Gestisci il ciclo di vita dell'agente con la stessa macchina che usi per i dipendenti: SSO per il login, e SCIM per il provisioning e, soprattutto, per il de-provisioning. Il paper indica lavori sperimentali per dare a SCIM un tipo di risorsa AgenticIdentity di prima classe, così che un agente diventi un'entità gestita, con proprietari e appartenenze a gruppi, anziché una API key orfana. Niente di tutto questo è esotico. Un team di piattaforma competente può costruirlo già adesso.
Due condizioni reggono però l'intero quadro: sincrono, e singolo dominio di fiducia. Rompine una e sei nella seconda metà del paper, dove i problemi risolti finiscono.
Dare un nome preciso ai problemi futuri
Dai a un problema un nome preciso e sei già a metà strada dal risolverlo — e questo paper, come il mio stesso lavoro, si rifiuta di accennare vagamente alle parti difficili. Le elenca, con la franchezza di chi ha davvero provato a costruire tutto questo.
Si parte dalla domanda più basilare di tutte: cos'è, alla fine, l'identità di un agente? Il paper espone quattro modelli architetturali. Il service account potenziato (un'identità di workload arricchita con metadati come agent_model e agent_version — il pattern enterprise più probabile nel breve termine). La sotto-identità utente delegata (un'identità derivata dalla sessione dell'utente e legata a essa, il vero flusso «on-behalf-of»). La fiducia federata (un tessuto interoperabile fra domini, costruito su qualcosa come OpenID Federation). E l'identità sovrana e portabile (ogni agente custodisce le proprie chiavi e un identificatore globalmente unico, tramite schemi come i DID). Proposte come OpenID Connect for Agents stanno provando a standardizzare i claims di identità che stanno sotto. Non possiamo ancora incoronare un vincitore — devi imparare il territorio prima di poterne uscire costruendo.
La spina dorsale è la delega, non l'impersonificazione
Se dovessi comprimere l'argomento del paper in una sola mossa, è questa: smetti di far impersonare l'utente agli agenti, inizia a farli agire con autorità delegata. Oggi un agente agisce con le tue credenziali e il log di audit non riesce a distinguervi — il buco nero che ho descritto la volta scorsa. La correzione è un vero flusso on-behalf-of in cui il token di accesso porta due identità distinte: l'utente che ha delegato (nel claim sub) e l'agente che agisce (nel claim act). Un legame pulito e verificabile fin dal primo passo.
La potenza, e insieme la difficoltà, salta fuori con la delega ricorsiva — un agente che passa un sotto-compito, e una fetta della propria autorità, a un altro. Come una matrioska, dice il paper, e lo intende come un avvertimento. Un resource server in fondo a una catena di cinque salti deve verificare crittograficamente l'intero percorso a ritroso fino all'umano originario, non solo l'ultimo agente che l'ha chiamato. Questo richiede l'attenuazione dello scope: restringere in modo dimostrabile i permessi a ogni passo. Il paper è piacevolmente concreto sulle opzioni — OAuth 2.0 Token Exchange per gli assetti centralizzati, hub-and-spoke, e i capability token come Biscuit e Macaroon per quelli decentralizzati, dove chi detiene un token può coniarne offline una versione più ristretta, con l'autorità incorporata nella credenziale stessa secondo un modello object-capability. È la parte che gran parte dei sistemi di agenti in produzione, nel 2026, sbaglia. Fanno girare ogni agente allo stesso livello di autorizzazione, con tutti gli strumenti, e chiamano «confine» un system prompt.
E il problema che fa ombra su tutto il resto: la revoca, che gli autori definiscono senza giri di parole «un problema critico, e in gran parte irrisolto». I token attenuati offline la peggiorano: revoca il padre e non c'è alcun modo pulito per raggiungere i figli già delegati a valle. Le risposte emergenti sono oneste ma parziali: lo Shared Signals Framework per propagare gli eventi di revoca quasi in tempo reale, e la mossa pragmatica di limitare una credenziale a un numero massimo di esecuzioni, così che una revoca tardiva ponga comunque un tetto al danno.
La governance deve passare dal clic al codice
Nel primo post di questa serie ho sostenuto che la supervisione umana nel ciclo, sotto la scala, collassa in affaticamento da consenso. La risposta del paper è quella che darei io, ed è strutturale. Non risolvi l'affaticamento da consenso chiedendo alle persone di stare più attente. Sposti la governance fuori dal clic e dentro il codice.
Tre pattern, in ordine di sofisticazione crescente. Policy-as-code: un amministratore definisce una volta sola l'inviluppo operativo dell'agente — limiti di budget, livelli di accesso ai dati, velocità delle chiamate — e il sistema lo applica in modo programmatico. Autorizzazione basata sull'intento: l'utente approva un intento di alto livello in linguaggio naturale («prenotami il viaggio per la conferenza»), e il sistema lo compila in un fascio di permessi a privilegio minimo. Autorizzazione dinamica basata sul rischio: le azioni di routine passano in automatico, e solo una richiesta anomala innesca un'approvazione umana fuori banda tramite CIBA. L'idea che li tiene insieme è un ibrido: usa il modello per tradurre l'intento umano sfumato in una policy formale, leggibile dalla macchina, e poi lascia che il sistema deterministico tenga la linea anche se l'agente fraintende l'istruzione. L'umano approva qualcosa di intuitivo; il runtime applica qualcosa di esatto. È in quello scarto, fra l'intuitivo e l'esatto, che la sicurezza vive davvero.
E poi c'è il denaro
La sezione che non mi aspettavo fosse la più illuminante è quella economica. L'utilità reale di un agente emerge quando può transare — comprare dati, pagare una API, saldare un acquisto — e l'intero modello di sicurezza dell'e-commerce dà per scontata la presenza di un umano al punto vendita. Togli l'umano e ti servono binari nuovi.
Il paper mappa tre strati che si stanno già formando. FAPI, il profilo ad alta sicurezza dell'OpenID Foundation, irrobustisce OAuth per le azioni finanziarie irreversibili con token vincolati al mittente. L'Agent Payments Protocol di Google introduce il Mandate — un artefatto di intento firmato crittograficamente, diviso in un Intent Mandate («ecco cosa ho autorizzato») e un Cart Mandate («ecco l'acquisto specifico che lo soddisfa»), così che per una transazione autonoma esista una traccia di audit non ripudiabile. E KYAPay propone un processo «Know Your Agent» che, nelle parole del paper, estende «la tradizionale verifica d'identità KYC/KYB all'agente stesso», emettendo un token che mette insieme identità verificata e informazioni di pagamento. Soffermati su quella formula — Know Your Agent. Il mercato sta già allungando la mano verso una responsabilità di forma KYC per gli agenti. Solo che non l'ha fatto in un modo che protegga l'umano dietro l'agente. Tienilo a mente per me.
L'unico nodo che il paper lascia aperto
Per quanto ampio sia il suo raggio, il documento continua a tornare su una sola tensione, troppo onesto per fingere di risolverla, ed è quella attorno a cui giro da una settimana.
«La stessa tracciabilità necessaria agli audit abilita un tracciamento cross-dominio capace di creare profili comportamentali completi e potenzialmente sensibili. I meccanismi di divulgazione selettiva — che fanno leva su tecniche crittografiche come le prove a conoscenza zero e le credenziali anonime — offrono una via d'uscita… ma integrare queste tecniche con gli standard di identità e i requisiti normativi esistenti resta una sfida considerevole.»
Eccolo di nuovo, dichiarato da chi è meglio posizionato per saperlo. Per rendere responsabile un agente gli leghi un'identità; lega un'identità e costruisci sorveglianza. Le prove a conoscenza zero e le credenziali anonime vengono indicate come il varco attraverso il muro — dimostrare «c'è un umano reale e perseguibile dietro di me» senza rivelare quale umano — e poi definite, con altrettanta chiarezza, non ancora integrate con gli standard e i regolatori che le renderebbero reali.
La conclusione stessa del paper inquadra il lavoro di questo decennio come tre spostamenti: vera delega anziché impersonificazione, governance scalabile anziché affaticamento da consenso, e fiducia interoperabile anziché silos proprietari. Ci aggiungerei la frase che gli autori mettono quasi di sfuggita, perché è il vincolo che esclude le risposte pigre: qualunque cosa costruiamo, «non deve diventare un giardino recintato». La mossa ben finanziata, qui, è un servizio centralizzato di identità per agenti che noleggi. Il paper, giustamente, dice che l'economia aperta degli agenti non può girare sul permesso di una sola azienda.
Questa è la mappa: le fondamenta sono reali, i problemi futuri sono nominati con cruda onestà, e il più difficile fra loro — responsabilità e privacy allo stesso tempo, senza alcun guardiano centrale — resta una sfida aperta, con una direzione crittografica e nessuna strada già costruita.
Io quella strada la sto costruendo. Nel terzo e ultimo post abbozzerò, ad alto livello, come scioglierei quel nodo aperto — come un agente può dimostrare che dietro di sé c'è un umano reale, perseguibile e verificato senza che nessuno venga mai a sapere chi. Stavolta non come rassegna delle idee altrui. Come l'approccio su cui sto passando le notti — e che inseguo dal 2014, da quando ho iniziato a costruire con le identità digitali.
Fonte: OpenID Foundation, Identity Management for Agentic AI (curatore principale Tobin South, con l'AI Identity Management Community Group e la Loyal Agents Initiative di Stanford), ottobre 2025. Tutto il testo citato è tratto dal paper.
