Cos'è OIDC-A?

OIDC-A (OpenID Connect for Agents) è una proposta di estensione a OpenID Connect che definisce come rappresentare l'identità di un agente AI, validare la catena di delega che lo collega all'utente o al sistema che lo ha autorizzato, e verificare un'attestazione crittografica delle sue proprietà prima di concedergli accesso a un servizio. È stata pubblicata come paper nel settembre 2025 da Subramanya Nagabhushanaradhya, discussa pubblicamente su GitHub e Hacker News, e resta a oggi una proposta tecnica aperta, non uno standard ratificato dalla OpenID Foundation. Il problema che affronta è specifico e tecnico: le identità non umane degli agenti AI pongono già oggi un problema di scala e governance, ma OIDC-A si occupa di un livello più a monte, il protocollo con cui un sistema autentica un agente, verifica chi lo ha delegato ad agire e decide quali capacità concedergli, invece di limitarsi a trattarlo come un service account con un token fisso.

Leggi anche: Non-Human Identity (NHI) · Un'identità digitale che appartiene a un software, non a una persona: service account, pipeline, bot e ora agenti AI che agiscono sui sistemi aziendali.

Come estende OIDC classico

OpenID Connect autentica un utente umano e restituisce un ID Token con claim su chi è. OIDC-A aggiunge claim pensati per un agente: chi lo ha creato, quale modello lo alimenta, e soprattutto una catena di delega, la sequenza di passaggi che parte dall'utente originale e attraversa eventualmente più agenti intermedi prima di arrivare a chi esegue l'azione finale. Ogni passaggio della catena può essere verificato singolarmente, così un servizio a valle non deve fidarsi ciecamente dell'ultimo anello ma può risalire fino alla richiesta umana che ha avviato tutto. A questo si affianca l'attestazione, una prova crittografica dell'integrità e dell'origine dell'agente compatibile con framework esistenti come IETF RATS e gli Entity Attestation Token, e l'autorizzazione capability-based, dove i permessi non sono assegnati all'agente come blocco unico ma alle singole capacità che gli servono per il task specifico.

Perché emerge proprio ora

Finché gli agenti AI eseguivano compiti singoli e supervisionati, un token OAuth generico bastava. Con agenti che agiscono per conto di altri agenti, in catene di delega che possono avere tre o quattro passaggi prima di toccare un sistema di produzione, l'autenticazione classica non distingue più "chi ha chiesto cosa" lungo la catena: un sistema riceve solo l'ultima richiesta, senza sapere se l'agente che l'ha generata aveva davvero l'autorità per farlo. OIDC-A nasce per colmare esattamente questo vuoto protocollare, non per sostituire i meccanismi di comunicazione tra agenti come MCP o A2A, che risolvono come un agente parla con uno strumento o con un altro agente, non chi è l'agente né cosa può fare.

Un esempio enterprise

Un agente di procurement riceve da un manager l'istruzione di rinnovare un contratto software entro un tetto di spesa, e per farlo delega a un agente finanziario il controllo del budget disponibile. Con OIDC-A, il sistema finanziario che riceve la richiesta può verificare la catena completa, manager, agente di procurement, agente finanziario, e concedere solo la capacità "leggi il budget della categoria X", non un accesso generico all'intero sistema contabile. Senza questo livello, il sistema finanziario vede solo un token valido e non ha modo di sapere se la richiesta ha davvero avuto origine da un'autorizzazione umana legittima.

Perché conta per chi decide

OIDC-A non è ancora pronto per un'adozione prescrittiva: è una proposta, non uno standard ratificato dalla OpenID Foundation con conformità testata su larga scala, e va trattato come tale nelle roadmap di sicurezza. Ma il problema che affronta, autenticare e autorizzare agenti che delegano ad altri agenti, non lo risolve nessun controllo perimetrale esistente, ed è la direzione in cui i grandi fornitori di identity management si stanno già muovendo. Chi progetta oggi l'architettura di identità per agenti AI aziendali dovrebbe seguirne l'evoluzione da vicino, anche solo per non ritrovarsi a dover ripensare da zero la gestione dei permessi quando la standardizzazione arriverà.