L'identità degli agenti è infrastruttura di produzione

L'identità è scesa sotto la chat

L'AI agentica non risponde soltanto: sceglie strumenti, chiama API, tocca file e può cambiare stato esterno. L'autenticazione iniziale non basta più. In produzione conta quale identità agisce, per conto di chi, con quale capability, per quale task e per quanto tempo.

Nell'agosto 2026 NIST ha descritto un pattern familiare: team che inseguono velocità e valore immediato prima di costruire una base solida di identità per gli agenti. Con gli agenti, questo diventa accesso eccessivo, azioni non autorizzate, approvazioni non tracciabili o secret che sopravvivono al task.

Il modello non deve essere il principal

Il principal di sicurezza deve essere una workload identity limitata creata dall'harness per uno specifico task. Il modello propone l'azione; l'ambiente decide se autorizzarla. L'autorizzazione resta fuori dal prompt e dalla memoria controllata dal modello.

La catena utente, sessione prodotto, run dell'agente, chiamata tool e servizio downstream deve portare prove proprie: repository, branch, motivo, task id e finestra temporale per leggere codice; contenuto ed effetto esatti per pubblicare.

• Separare identità utente e workload identity dell'agente
• Usare credenziali brevi per un solo task
• Autorizzare i tool server-side
• Registrare decisione, input, output e rollback per ogni write

Le capability sono l'unità del least privilege

I ruoli sono troppo grossolani per gli agenti. Un run di solito richiede un repo, un branch e poche operazioni. Ogni tool dovrebbe essere una capability con input tipizzati, precondizioni, postcondizioni, budget e scadenza.

Così si riduce anche la permission fatigue: letture sicure e controlli deterministici non devono interrompere l'utente; l'approvazione umana va conservata per pubblicare, cancellare, spendere, concedere accessi o inviare dati sensibili.

L'audit trail deve reggere l'incident response

Servono intento utente, versioni di modello e prompt, evidenze, capability concesse, input/output dei tool, decisioni di policy, provider id ed effetti finali. Senza questa catena non si distingue un cattivo suggerimento da un bug dell'harness, credenziali rubate o approvazione errata.

L'incidente Hugging Face pubblicato da OpenAI nel luglio 2026 mostra perché la ricostruzione delle traiettorie conta: Hugging Face ha ricostruito migliaia di azioni su più giorni. Identità e telemetria vanno progettate prima del primo incidente serio.

Checklist di produzione

Partire da deny-by-default. Ogni run ha un task id, capability esplicite, secret mediati da broker all'ultimo momento responsabile, rete limitata e write idempotenti. Poi provare revoca, quarantena e conservazione delle prove senza leak di secret.

Un sistema sano è spiegabile: quale identità ha agito, perché era consentito, cosa è cambiato, come tornare indietro e quale monitor scatterà la prossima volta.