# L'identità degli agenti è infrastruttura di produzione

Gli agenti autonomi trasformano l'identità da dettaglio di login a superficie di controllo per tool call, approvazioni e recovery.

Published: 2026-08-29

## 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.