(1/3) Non c'è più nessuno alla tastiera

Da qualche giorno rifletto molto sull'identità — personale e pubblica, umana e sintetica — e non ho pubblicato nulla per ritagliarmi il tempo di lavorarci. Mi sono immerso in un solo problema, leggendo specifiche e bozze di protocolli fino a tardi, perché credo che stia per diventare uno dei problemi portanti del nostro campo e quasi nessuno, al di fuori di una manciata di gruppi di standard, ne parla in termini chiari.

Il problema è questo: ogni sistema di identità che abbiamo costruito negli ultimi trent'anni dà per scontato che ci sia un umano davanti alla tastiera. Qualcuno fa login. Qualcuno vede una schermata di consenso. Qualcuno clicca «accetta» e può, dopo, essere ritenuto responsabile di ciò che accade. L'autenticazione risponde a chi sei, l'autorizzazione a cosa puoi fare, e il log di audit a chi ha fatto questo. Tutte e tre poggiano sullo stesso presupposto silenzioso: che dietro ogni azione ci sia qualcuno. Gli utilizzi che sfuggivano a quel «qualcuno» li abbiamo coperti alla meglio con account di servizio, artefatti vari, sistemi di permessi.

Gli agenti rompono questo presupposto e mescolano le azioni degli account di servizio con quelle degli utenti reali.

Noi che siamo ingegneri senior gestiamo l'IAM, la risposta agli incidenti e i guardrail che stanno fra un servizio e ciò che ha il permesso di chiamarlo. Quindi quando dico che il modello attuale non si estende abbastanza da coprire gli agenti autonomi, non è una previsione. È che sono andato a vedere dove sono le cuciture, e si stanno già scucendo.

Un agente agisce con le tue credenziali, indistinguibile da te

Partiamo dal caso più semplice, perché è già in produzione ovunque. Dai a un assistente accesso alla tua casella di posta, al tuo calendario, al tuo repository. Sotto il cofano riusa i tuoi token, i tuoi cookie, la tua sessione. Per qualsiasi servizio a valle, l'agente sei tu. Il recente gruppo di lavoro dell'OpenID Foundation l'ha detto con chiarezza: gli agenti «spesso agiscono in modo indistinguibile dagli utenti, creando lacune di responsabilità e rischi di sicurezza».

È il problema del confused deputy, solo che ora il delegato ragiona, improvvisa e continua a girare per ore dopo che ti sei alzato dalla sedia. Un client tradizionale agisce su «input utente strutturati e privi di ambiguità» — un clic su un pulsante, l'invio di un modulo, una concessione di intento chiara e verificabile. Un agente interpreta istruzioni non strutturate, un thread di email inoltrato, uno screenshot, e decide cosa fare al momento dell'inferenza. Il segnale di consenso esplicito e leggibile dalla macchina su cui è stato costruito tutto il mondo di OAuth è sparito. Resta software che agisce con tutta la tua autorità e niente del tuo giudizio, e un log che non sa distinguervi l'uno dall'altro.

Chiunque può coniare un client anonimo, e nessuno lo firma

Scendi di un livello, a come gli agenti ottengono la loro identità in partenza, e peggiora. Il Model Context Protocol — lo standard di connessione su cui è converso gran parte del tooling per agenti — si è appoggiato a Dynamic Client Registration per restare senza attriti: qualsiasi client può registrarsi su un server e ottenere credenziali, senza scartoffie. Comodo, e un buco di sicurezza attraverso cui passa un'intera flotta. Come lo descrive il paper di OpenID, «un endpoint di registrazione pubblico e non autenticato consente di creare client senza alcun legame con uno sviluppatore reale… una totale assenza di tracciabilità documentale», aperto all'«abuso dell'endpoint (per es., DoS tramite registrazione di massa)».

Così la popolazione di agenti sta esplodendo, e gran parte è anonima per costruzione. Non c'è alcuna parte responsabile dall'altro lato della credenziale. Quando uno di quei client fa qualcosa che non dovrebbe, non puoi seguire il filo fino a nessuno a cui chiedere conto. Gli autori di OpenID danno al risultato il nome esatto: «un buco nero per la responsabilità e l'analisi forense». Quella frase mi è rimasta in testa per una settimana, perché ho fissato log così. Vedi l'azione. Non trovi l'attore.

La delega si rompe nel momento in cui attraversa il confine di un'azienda

Dentro una singola azienda, un team di piattaforma competente può tamponare gran parte di tutto questo. Dai all'agente un'identità di workload, fallo passare per l'IdP aziendale, limitane i permessi, e il caso di un singolo dominio di fiducia oggi funziona ragionevolmente bene. Voglio essere onesto su questo: i pezzi fondamentali — OAuth 2.1, PKCE, token a vita breve e ambito limitato — sono solidi, e per un agente che chiama strumenti interni sono, per ora, sufficienti.

La cucitura si lacera nel momento in cui un agente attraversa un confine organizzativo. Un agente finanziario che attinge dalla tua banca, da una API di dati di mercato e da un'agenzia di credito opera in tre domini di fiducia distinti, e nessun provider di identità è la fonte di verità per tutti e tre. I framework di identità di workload come SPIFFE/SPIRE si basano sul controllo di un'infrastruttura condivisa e, per usare le parole del paper, «non si estendono naturalmente tra organizzazioni». La vera delega richiede che il token di accesso porti due identità distinte — la persona che ha delegato e l'agente che agisce — e che l'ambito si attenui a ogni salto quando un agente sub-delega a un altro. La delega ricorsiva tra aziende, con la traccia di audit intatta da capo a fondo, è in gran parte irrisolta. E l'economia aperta di agenti tra organizzazioni verso cui tutti corrono vive interamente dall'altro lato di quella cucitura.

Mille richieste di approvazione equivalgono a nessuna approvazione

La correzione istintiva a tutto questo è «tieni un umano nel ciclo: che l'agente chieda». Non sopravvive al contatto con la scala. Un solo agente di marketing che ottimizza un budget può scatenare centinaia di azioni distinte in pochi secondi; una sola persona può avere alle spalle decine di agenti che prendono migliaia di decisioni al giorno. L'EU AI Act, giustamente, impone una «vigilanza effettiva» per i sistemi ad alto rischio. Ma chiedere a un umano di approvare ogni azione autonoma produce quella che il paper chiama affaticamento da consenso: «un diluvio ingestibile di richieste di autorizzazione» che «riduce paradossalmente la sicurezza», perché una persona che clicca «accetta» quattrocento volte al giorno non sta esercitando alcun giudizio. Timbra senza guardare, e a un attaccante basta che timbri una volta.

La vigilanza che non scala non è vigilanza. È teatro, con una modalità di guasto peggiore del non averne affatto, perché sembra controllo.

Revocare un agente è ancora un problema in gran parte irrisolto

Supponi ora che sia successo il peggio: un agente è compromesso, o semplicemente si comporta male. Lo vuoi fuori. Anche qui la risposta onesta nel 2026 è che non siamo ancora bravi a farlo. Gli autori di OpenID definiscono la revoca «un problema critico, e in gran parte irrisolto», e con gli agenti si fa più acuta, perché una singola identità compromessa può «innescare un guasto a cascata attraverso un intero ecosistema di sub-agenti» a cui aveva già delegato. Revocare un token al portatore non arriva in fondo a una catena di autorità già passata di mano.

E la revoca è soltanto il freno d'emergenza. Il requisito più profondo è il de-provisioning: cancellare in modo permanente l'identità di un agente e ogni autorizzazione che ha accumulato, in tutti i sistemi che ha toccato, abbastanza in fretta da impedire che una credenziale compromessa e dormiente venga riattivata più tardi. Un agente opera a velocità di macchina con l'autorità delegata di un umano e un raggio d'impatto enormemente amplificato. La capacità di farne sparire uno, in modo verificabile e ovunque, non è una comodità operativa. È una condizione preliminare per lasciarli girare, anche solo un po'.

Puoi avere la responsabilità o la privacy, e oggi devi scegliere

Ho tenuto per ultimo quello che non riesco a togliermi dalla testa, perché è il nodo di cui parla il resto di questa serie.

Tutto ciò che precede ti spinge verso una sola risposta: per rendere responsabile un agente, legagli un'identità reale e nota. Collega ogni azione dell'agente a una persona con un nome e il buco nero si chiude. Ma fallo e avrai costruito qualcos'altro: un sistema in cui ogni agente che chiunque esegue resta legato per sempre alla sua identità reale, in cui la tracciabilità che hai aggiunto per gli audit «abilita un tracciamento cross-dominio» e lascia che chiunque componga «profili comportamentali completi e potenzialmente sensibili» di ciò che gli agenti della gente fanno tutto il giorno. Hai risolto la responsabilità cancellando la privacy.

Lo si presenta, quasi dappertutto, come un dilemma chiuso. O gli agenti sono anonimi e irresponsabili, o sono responsabili e sorvegliati. Il paper di OpenID è insolitamente onesto nell'ammettere che forse c'è una terza porta — tecniche di divulgazione selettiva, «prove a conoscenza zero e credenziali anonime», che lasciano a un agente dimostrare un'affermazione precisa senza rivelare chi ci sta dietro —, ma è altrettanto onesto nel riconoscere che «integrare queste tecniche con gli standard di identità e i requisiti normativi esistenti resta una sfida considerevole». Strada indicata. Porta non ancora costruita.

Fai un passo indietro da questi sei dolori e vedrai che condividono una stessa origine. Impersonificazione, client anonimi, delega che si rompe attraversando i confini, affaticamento da consenso, agenti che non puoi revocare con pulizia, responsabilità che ti costa la privacy: non sono sei problemi separati. Sono sei sintomi di una sola garanzia che manca: che dietro ogni azione c'è una persona precisa e responsabile che puoi trovare. L'autenticazione, l'autorizzazione e il log di audit sono stati costruiti tutti su quella garanzia. Gli agenti ci hanno tolto la capacità di riconoscere con chiarezza chi detiene l'autorità.

Un agente può essere autonomo — è tutto il senso di costruirne uno —, ma la responsabilità deve restare. Un agente non è una persona giuridica: non puoi citarlo in giudizio, né multarlo, né farlo sedere a chiedergli cosa avesse in mente. Quindi, per quanti strati di delega si accumulino nel mezzo, la responsabilità deve finire per posarsi su un umano reale e perseguibile che ha scelto di metterlo in campo. È tutto qui il problema di questa serie: come rendere quel legame — questa azione risale a quella persona responsabile — dimostrabile a chiunque debba verificarlo, senza esporre la persona a tutti quelli che non ne hanno bisogno. Un agente che non risale a nessuno non è autonomia. È rischio senza padrone, che corre a velocità di macchina: tutti a valle lo subiscono, e nessuno può essere chiamato a risponderne.

Dove porta tutto questo

Niente di tutto ciò è fantascienza, e niente è lontano. La scala, da sola, impone la questione: gli autori di OpenID descrivono la destinazione come «un mondo popolato da milioni di attori non umani», e le proiezioni dei vendor — indicative, non oro colato — collocano gli agenti a molte volte il numero di utenti umani nel giro di pochi mesi. Stiamo per schierare una popolazione di attori autonomi più grande di quella umana, sopra uno stack di identità che dà per scontato che ciascuno di loro sia una persona capace di cliccare un pulsante.

Così sono andato a cercare la mappa più chiara di questo terreno, e ne ho trovata una. Il prossimo post di questa serie ne è una lettura attenta: Identity Management for Agentic AI, dell'OpenID Foundation, lo studio più onesto di questi problemi che abbia letto, compresi quelli che ammette nessuno abbia risolto. Dopo, abbozzerò come affronterei davvero il nodo più difficile — responsabilità e privacy allo stesso tempo —, perché ho fatto qualcosa di più che leggere.

Se stai costruendo sistemi agentici oggi e vuoi il pezzo adiacente, quello che delimita ciò che a un agente è permesso fare una volta che sai chi c'è dietro, ho scritto sulla governance verificabile per l'IA agentica all'inizio dell'anno. L'identità è la domanda del chi; quella è la domanda del cosa. Ti servono entrambe. E siamo a corto di entrambe.