L'Estonia intende rilasciare identità digitali ufficiali, gli "AI ID code", agli agenti AI. L'ufficio del Primo Ministro Kristen Michal afferma che l'obiettivo è permettere all'AI di "agire per conto di persone, aziende o organizzazioni entro limiti chiaramente definiti e in modo verificabile e auditabile". Se il progetto andrà in porto, l'Estonia diventerà il primo Paese a dare agli agenti AI un'identità riconosciuta dallo Stato. È una mossa genuinamente utile, ed è anche la parte facile. La parte difficile è tutto ciò che l'identità dovrebbe portare con sé.

Io costruisco con agenti che detengono credenziali reali, quindi la mia reazione è meno "è distopico?" e più "a cosa deve effettivamente legarsi l'identità?". Un identificatore di per sé è un numero. Ciò che lo rende rilevante è quello che vi colleghi: autorità, una catena di delega e responsabilità. Sbaglia questi elementi e avrai rilasciato una chiave primaria dall'aspetto molto ufficiale.

Cosa ha annunciato davvero l'Estonia

Il piano prevede di assegnare a ogni agente un identificatore con un duplice scopo: identificazione, e limitazione dell'ambito di ciò che l'agente è autorizzato a fare. L'impostazione data dall'ufficio di Michal è quella giusta: "deve essere chiaro chi sta agendo per conto di chi e con quali diritti, e chi è in ultima istanza responsabile". Philipp Pointner, responsabile dell'identità digitale di Jumio, l'ha definito un precedente per "come dobbiamo auditare ciò che gli agenti possono fare per conto di un individuo", sottolineando che i sistemi di identità ora devono distinguere tra identità umana e autorità dell'agente.

Quella distinzione è tutto. Un'identità umana risponde alla domanda "chi sei". Un'identità di agente deve rispondere a una domanda più difficile: "chi ti ha autorizzato, a fare cosa e per quanto tempo".

Perché questa non è solo burocrazia

Se hai collegato un LLM a degli strumenti, sai già che lo stato dell'arte attuale sono le credenziali prese in prestito. L'agente gira come service account, o peggio, con il token OAuth di un essere umano e una API key a lunga durata copiata in una variabile d'ambiente. L'IAM incentrato sull'uomo è stato costruito attorno a una persona che effettua il login occasionalmente, clicca su una schermata di consenso e agisce a velocità umana. Un agente non effettua mai il login, ha ricevuto il proprio accesso da qualcun altro e agisce migliaia di volte al minuto.

Così, quando un agente fa qualcosa di sbagliato, i log dicono che è stato un service account a farlo, oppure che è stato un essere umano, perché quello era il token presente nella richiesta. L'azione è reale e la responsabilità è una finzione. L'istinto dell'Estonia, dare all'agente una propria identità in modo che le sue azioni siano attribuibili a esso e tracciabili fino a chi le ha autorizzate, è esattamente la lacuna che va colmata. L'istinto è giusto. È nell'implementazione che diventa costoso.

Le tre cose che un'identità di agente deve portare con sé

1. Autorità con ambito definito, non solo un nome

Un'identità che dimostra "questo è l'agente X" e nient'altro è una targhetta col nome. Il valore sta nei permessi a essa associati: quali sistemi, quali operazioni, quali dati, a quali condizioni, con quali limiti di spesa o di frequenza. È questa la parte a cui il comunicato stampa allude con "limiti chiaramente definiti", ed è la parte che richiede anni per essere fatta bene, perché un ambito troppo ampio ricrea il problema originale e un ambito troppo ristretto rende l'agente inutile. Per questo abbiamo già delle primitive, gli OAuth scope, la workload identity, i capability token, ma un livello di identità nazionale deve interoperare con esse, non sedersi al di sopra come una quarta fonte di verità in competizione.

2. Una catena di delega che si possa davvero seguire

"Chi sta agendo per conto di chi" non è un singolo salto. Una persona autorizza un agente, l'agente chiama uno strumento, lo strumento genera un sub-agent, il sub-agent contatta una API di terze parti. Ogni passaggio restringe, o dovrebbe restringere, l'autorità. Se l'identità non cattura la catena, ottieni il classico confused-deputy problem a velocità di macchina: un componente con accesso legittimo viene ingannato per usarlo per lo scopo di qualcun altro, e il log di audit mostra una chiamata pulita e autorizzata. Un'identità di agente vale solo quanto la sua capacità di registrare e vincolare quella catena, non solo l'attore finale.

3. Una responsabilità che ricada su un essere umano

Ecco la parte che la tecnologia non può risolvere. Puoi dare a un agente un'identità, un portafoglio e un ambito, ma quando svuota un conto o firma un contratto sbagliato, la responsabilità non si ferma all'agente. Risale a una persona o a un'organizzazione. L'identità è il meccanismo che rende possibile quel tracciamento all'indietro, il che è positivo, ma non decide chi sia responsabile: il principal che ha delegato, lo sviluppatore che ha costruito l'agente, o il fornitore che ha rilasciato il modello. L'Estonia sta facendo la cosa responsabile portando questa domanda allo scoperto fin da subito. Nessuno ha ancora una risposta pulita.

L'identità è necessaria, non sufficiente

Una recente frase di BCG, citata nella copertura mediatica, coglie il problema più profondo: "I valori non sono regole. Sono convinzioni e principi formati attraverso migliaia di decisioni umane, plasmati dal contesto, dall'eccezione e dal precedente". Un AI ID code può codificare regole. Non può codificare il giudizio. Un agente con un'identità perfetta, con ambito completamente definito e completamente auditata può comunque compiere un'azione tecnicamente consentita e palesemente sbagliata. L'identità ti dà attribuzione e revoca. Non ti dà un buon comportamento. Sono problemi diversi, e confonderli è il modo in cui finisci per fidarti di un agente più di quanto il suo design giustifichi, solo perché ha un bel distintivo.

Cosa significa questo se costruisci con gli agenti

Non devi aspettare un registro governativo per applicare questo ragionamento. Il piano dell'Estonia è solo la versione su scala nazionale delle scelte che dovresti già stare facendo:

  • Dai a ogni agente la propria identità. Non un service account condiviso, non il token di un essere umano. Un principal per agente, così che le sue azioni siano attribuibili a esso soltanto.
  • Limita l'ambito al compito, poi falla scadere. Credenziali a breve durata e con ambito ristretto battono ogni volta le chiavi a lunga durata. Un agente che deve solo leggere non dovrebbe mai detenere un token che può scrivere.
  • Registra la catena di delega, non solo la chiamata. Annota chi ha autorizzato l'agente e con quale ambito, così che "chi sta agendo per conto di chi" sia una query, non uno scavo forense.
  • Rendi la revoca istantanea. La prima cosa che vuoi quando un agente si comporta male è un interruttore di spegnimento che funzioni in secondi, non una rotazione di chiavi che richiede un giorno.
  • Mantieni intenzionalmente un essere umano responsabile. Decidi, prima del deployment, chi possiede le azioni dell'agente. Non lasciare che l'organigramma lo scopra durante un incidente.

L'Estonia ha ragione sul fatto che gli agenti che operano a velocità di macchina abbiano bisogno di una responsabilità integrata, e ha ragione sul fatto che un'identità sia il punto di partenza. Basta tenere chiaro l'ordine di difficoltà. Rilasciare l'identità è l'annuncio. Vincolare l'autorità, tracciare la delega e decidere chi risponde per l'agente è il lavoro, ed è lo stesso lavoro sia che tu sia un piccolo team che collega un modello che usa strumenti, sia che tu sia un Paese che rilascia codici a tutta l'economia degli agenti.

Leggi questo dopo

Per il lato infrastruttura e piattaforma della gestione sicura degli agenti, le field notes sul cloud sono su ercan.cloud. Per consulenza su AI, identità e lavoro di piattaforma, o anche solo per salutare, parti da ercanermis.com.