Identità e autenticazione degli agenti IA per gli MVP

Un agente IA può chiamare API, leggere documenti, inviare messaggi o aggiornare record per conto di un utente. Se ogni azione usa una chiave di servizio condivisa o le credenziali complete dell’utente, il sistema non può rispondere in modo affidabile a domande basilari: quale agente ha agito? Chi ha delegato l’autorità? Che cosa poteva fare? È possibile revocare quell’autorità senza interrompere il lavoro di tutti gli altri?

L’identità dell’agente è il fondamento per rispondere a queste domande. Va progettata come sicurezza del workload, non come personalità, nome visualizzato o istruzione nel prompt.

Distingui le identità coinvolte

Come minimo, distingui il soggetto umano o di sistema, il workload dell’agente e lo strumento o la risorsa a cui si accede. Conserva la relazione tra questi elementi in ogni richiesta sensibile.

Un utente può autorizzare un agente per la revisione delle spese a leggere le fatture di un’organizzazione. L’identità dell’agente dimostra quale workload ha effettuato la chiamata; il contesto delegato identifica l’utente e il tenant; la policy di autorizzazione limita i record e le azioni consentiti. Lo strumento autentica comunque la propria identità presso l’agente o il gateway.

Questo modello è in linea con il lavoro concettuale NIST del 2026 sull’identità degli agenti software e IA, che evidenzia identificazione, autenticazione, autorizzazione, delega, audit e rischi di prompt injection.

Tratta separatamente autenticazione e autorizzazione

L’autenticazione risponde a «chi o che cosa è questo?» L’autorizzazione risponde a «può eseguire questa azione adesso?» Una credenziale valida dell’agente non dovrebbe implicare un accesso ampio.

Usa credenziali del workload a breve durata e mantieni i segreti fuori dal prompt e dal contesto della conversazione del modello. Valuta la policy presso un gateway degli strumenti affidabile o al confine del servizio. Quando possibile, circoscrivi le autorizzazioni per tenant, risorsa, azione, scopo e durata.

Controllo	Implementazione per l’MVP
Identità	Identificatore univoco dell’agente/workload
Autenticazione	Credenziale firmata a breve durata o identità di workload consolidata
Delega	Contesto di utente e tenant con ambito esplicito
Autorizzazione	Decisione consenti/nega/sospendi lato server
Revoca	Disabilitazione indipendente di agente, credenziale o autorizzazione
Audit	Registrazione di attore, soggetto, strumento, decisione, risultato e orario

Istruzioni nel prompt come «non eliminare mai i dati» sono utili indicazioni comportamentali, ma non costituiscono un confine di controllo degli accessi. Un output del modello compromesso o errato deve passare da un controllo policy indipendente.

Applica il minimo privilegio agli strumenti

Non dare a un agente una chiave API universale. Crea capacità ristrette: leggere record approvati, preparare un messaggio o inviare una modifica proposta. Se le conseguenze sono rilevanti, separa «preparare» da «eseguire».

Convalida gli argomenti degli strumenti rispetto a uno schema e applica i confini del tenant usando il contesto autenticato, non gli ID forniti dal modello. Aggiungi limiti di frequenza, spesa e volume. Richiedi l’approvazione umana per azioni irreversibili, finanziarie, visibili esternamente o insolitamente ampie.

La guida alle protezioni per gli agenti IA mostra come i permessi lavorino insieme alla convalida degli input e alla revisione umana.

Conserva delega e responsabilità

Quando un agente agisce per una persona, il log a valle non dovrebbe fondere entrambe le identità in una sola. Registra il soggetto responsabile, la versione dell’agente, l’autorizzazione attiva, lo strumento richiesto, la decisione della policy e l’esito. Evita di registrare il contenuto sensibile dei prompt, salvo quando sia necessario e adeguatamente protetto.

La delega dovrebbe attenuare l’autorità, non ampliarla. Un sotto-agente non può ereditare in sicurezza ogni permesso posseduto dal chiamante. Trasmetti solo la capacità necessaria per il sotto-compito, con una scadenza breve e una richiesta padre tracciabile.

Il lavoro IETF emergente descrive gli agenti IA come workload che possono usare standard di identità consolidati mantenendo il contesto utente delegato. Questi documenti sono ancora bozze: non presentare quindi protocolli sperimentali come standard definitivi. Costruisci su primitive mature e mantieni sostituibile il livello di identità.

Valuta se servono un registro o una blockchain

Un registro può aiutare le organizzazioni a individuare chiavi, proprietari, stato e metadati degli agenti. Un registro basato su blockchain o decentralizzato può essere rilevante per soggetti privi di un’autorità d’identità condivisa, ma introduce questioni di privacy, revoca, governance e integrazione.

La maggior parte dei prodotti nelle fasi iniziali opera all’interno di un’organizzazione o con pochi partner noti. Un provider d’identità convenzionale, credenziali del workload, token firmati e un servizio policy sono di solito più semplici. Aggiungi la verifica tra organizzazioni solo quando un’interazione reale lo richiede.

Testa i fallimenti dell’identità prima del lancio

Simula una credenziale scaduta, un agente revocato, un tenant errato, una richiesta riprodotta, un argomento alterato, una spesa eccessiva e un servizio di approvazione non disponibile. Verifica che il comportamento predefinito sia sicuro e che gli operatori possano comprendere il rifiuto.

Testa anche la prompt injection indiretta. Il contenuto non affidabile di una pagina o di un documento non deve poter concedere strumenti o modificare la policy. Limita ciò che il contenuto recuperato può influenzare e mantieni le credenziali inaccessibili al modello. Consulta il threat modeling per gli agenti IA prima di ampliare l’accesso agli strumenti.

Un MVP non ha bisogno di un protocollo universale per l’identità. Ha bisogno di attori distinti, autorità circoscritta e revocabile, applicazione indipendente e una traccia di audit che supporti le indagini. Questi controlli permettono al team di aggiungere autonomia gradualmente senza perdere responsabilità.

Crea un inventario delle identità degli agenti

Mantieni un piccolo registro anche se è solo un archivio di configurazione interno. Per ogni agente distribuito, registra proprietario, scopo, ambiente, versione, strumenti consentiti, emittente delle credenziali, autorità massima, policy di approvazione e stato corrente. Separa le identità di sviluppo da quelle di produzione, così un agente di test non può raggiungere le risorse dei clienti.

Definisci gli eventi del ciclo di vita. Eroga l’identità tramite un processo revisionato, ruota automaticamente le credenziali e disabilita un agente quando il proprietario lascia l’organizzazione, il workflow viene ritirato o compare un comportamento sospetto. La revoca deve avere effetto nel punto di applicazione; modificare un prompt o rimuovere una voce visualizzata non è sufficiente.

Esamina l’accesso effettivo, non quello previsto. Permessi degli strumenti, ambiti utente delegati, percorsi di rete, token memorizzati nella cache e autorizzazioni dei sotto-agenti possono combinarsi creando un’autorità più ampia. Verifica se un utente con pochi privilegi può indurre un agente a leggere o modificare i dati di un altro tenant. Registra i tentativi negati, così i team di sicurezza possono distinguere gli errori di policy dai pattern di attacco.

Infine, rendi l’identità visibile agli operatori e agli utenti quando ciò supporta un’approvazione consapevole. Una schermata di approvazione dovrebbe indicare quale agente propone quale azione, per chi, su quale risorsa e con quale conseguenza. Questo contesto trasforma un pulsante di conferma generico in una decisione di autorizzazione significativa e riduce la probabilità che le persone approvino per abitudine azioni rischiose.

Mantieni deliberatamente piccola la prima architettura d’identità: un emittente, un confine di applicazione, credenziali a breve durata e un archivio di audit chiaro possono bastare per un workflow circoscritto. La complessità dovrebbe seguire le reali esigenze di federazione o delega. Anche questo piccolo progetto richiede test per disallineamento degli orologi, rotazione delle chiavi, servizi d’identità non disponibili e richieste duplicate. Un rifiuto sicuro non dovrebbe compromettere il lavoro dell’utente: conserva una bozza o accoda il lavoro sicuro, così un’interruzione dell’autenticazione non spinge gli operatori ad aggirare i controlli.

Domande frequenti

Un agente IA ha bisogno di una propria identità?

Un agente che chiama strumenti o accede ai dati deve essere distinguibile dall'essere umano, dall'applicazione e dagli altri agenti coinvolti. Questo consente permessi circoscritti, revoca e registri di audit utili.

L'autenticazione di un agente è la stessa cosa dell'autorizzazione?

No. L'autenticazione stabilisce quale workload sta agendo; l'autorizzazione decide quale risorsa e quale azione può utilizzare nell'attuale contesto delegato. Entrambe sono necessarie.

Un MVP dovrebbe usare la blockchain per l'identità degli agenti?

Solo se la verifica tra organizzazioni richiede davvero un registro decentralizzato e i compromessi sono giustificati. La maggior parte degli MVP dovrebbe iniziare con un'identità di workload consolidata, delega in stile OAuth, credenziali a breve durata e applicazione delle policy lato server.