Un agente AI dovrebbe avere esattamente gli accessi necessari al compito assegnato, non quelli comodi. In pratica: un'identità dedicata e riconoscibile, permessi in sola lettura dove basta leggere, nessun privilegio lasciato aperto «perché potrebbe servire» e una revisione periodica che revoca ciò che non serve più. Configurato così, il privilegio minimo non blocca il lavoro: lo rende verificabile.
L'agente come identità: account, ruoli, ambiti
Il primo passo è smettere di trattare l'agente come un pezzo di software invisibile e iniziare a trattarlo come un'identità di servizio: un account proprio, distinto da quelli delle persone, con un nome che dica cosa fa («agente-reportistica», non «srv01»), un proprietario umano indicato e un ambito definito. Se l'agente lavora con le credenziali di un tecnico, ogni sua azione risulta compiuta da quel tecnico: la tracciabilità muore lì.
Questo approccio ha un riferimento consolidato. La pubblicazione NIST SP 800-207 sull'architettura zero trust stabilisce due principi che si traducono direttamente sulla governance degli agenti: nessuna fiducia implicita per posizione di rete o proprietà dell'asset, e autenticazione e autorizzazione come funzioni discrete da eseguire prima di ogni sessione verso una risorsa. In altre parole: il fatto che l'agente «giri sul nostro server» non gli concede nulla; ogni accesso va autorizzato come per qualsiasi altro soggetto. Attenzione a non trasformare il riferimento in un'etichetta: SP 800-207 non è una certificazione di prodotto, e dichiarare un agente «conforme zero trust» non significherebbe nulla di verificabile.
Concedere per compito, non per comodità
La domanda giusta non è «a cosa potrebbe servire accesso?» ma «di quali accessi questo compito non può fare a meno?». Per definirli, rispondi per iscritto a cinque domande prima dell'attivazione:
- Quali fonti deve leggere? Elenca sistemi e dati, non categorie generiche: «i log del firewall X e del server Y», non «la rete».
- Deve scrivere o solo leggere? La maggior parte dei compiti di osservazione e analisi richiede sola lettura. La scrittura va concessa solo dove il compito la richiede davvero.
- Su quali sistemi può proporre interventi? L'ambito delle proposte va limitato come quello degli accessi.
- In quali orari? Se il compito è diurno, i privilegi notturni vanno giustificati.
- Chi è il proprietario? Ogni account di servizio ha una persona che ne risponde e che riceve le richieste di modifica.
Un punto architetturale conta più degli altri: separare osservazione e intervento. Se un agente di monitoraggio deve poter proporre un'azione correttiva, i privilegi per eseguirla non dovrebbero stare nel suo account: dovrebbero essere concessi solo al momento dell'intervento approvato, per quell'intervento specifico. Così anche un errore o un abuso dell'agente resta confinato alla lettura. Il NIST AI Risk Management Framework, quadro volontario per l'affidabilità dei sistemi di intelligenza artificiale, colloca proprio nella funzione di governance la definizione di ruoli, responsabilità e limiti: i privilegi minimi sono la traduzione tecnica di quel principio.
Revisione periodica e revoca dei privilegi
I privilegi crescono quasi sempre in buona fede: un'integrazione urgente, una prova mai chiusa, un accesso temporaneo diventato permanente. Il fenomeno ha un nome, privilege creep, e si scopre solo guardando. Tre controlli pratici lo rendono visibile:
- Confronto con la configurazione approvata. Documenta quali accessi sono stati autorizzati e confronta periodicamente lo stato reale: ogni differenza è una variazione da spiegare.
- Privilegi inutilizzati. Un accesso mai usato nell'ultimo periodo di osservazione è un candidato alla revoca, non un motivo per tenerlo.
- Variazioni senza richiesta. Ogni modifica ai privilegi dovrebbe corrispondere a una richiesta approvata: una variazione senza riferimento è un segnale da verificare, non un dettaglio.
La revoca, quando serve, deve essere mirata e documentata: si rimuove l'accesso specifico non più necessario, si registra chi ha deciso e perché, si verifica che il lavoro dell'agente continui. La frequenza della revisione va concordata rispetto al rischio e al ritmo dei cambiamenti della tua organizzazione: non esiste una cadenza universale valida per tutti, ma esiste la regola che una revisione mai fatta equivale a privilegi mai controllati.
Esempio illustrativo: l'account che leggeva troppo
Esempio illustrativo. Lo scenario seguente è inventato per mostrare il meccanismo; non descrive un evento reale né un cliente.
In una società di servizi, un agente di reportistica settimanale legge i dati del gestionale e produce sintesi per la direzione. Il suo account di servizio era stato creato con accesso in sola lettura al solo gestionale. Nel corso di un anno, per esigenze mai formalizzate, ha accumulato l'accesso al CRM commerciale e alla cartella condivisa della contabilità. Alla prima revisione periodica, il confronto con la configurazione approvata mostra due variazioni senza richiesta e i registri mostrano che l'agente non ha mai letto la cartella contabile. Il proprietario dell'account revoca i due accessi in eccesso dopo aver verificato che le sintesi non li usano: il lavoro dell'agente continua identico, ma la superficie esposta in caso di errore o compromissione dell'account si riduce a ciò che serve davvero. La revisione viene fissata con cadenza concordata e la richiesta di nuovi accessi torna a passare dal flusso di approvazione.
Il contributo di Athena e Themis in OverZeus
In OverZeus due agenti lavorano su questo fronte. Athena controlla identità, gruppi e privilegi: spiega le autorizzazioni rilevate e mette in evidenza le variazioni da verificare, come un account aggiunto a un gruppo amministrativo senza una richiesta approvata nelle fonti collegate. La sua proposta arriva al responsabile con privilegi precedenti, nuovi accessi e possibili impatti di una revoca; solo dopo l'approvazione viene rimossa l'appartenenza indicata, con verifica del risultato. Themis fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: un'operazione che arriva al controllo di esecuzione con un'autorizzazione non più valida viene bloccata prima dell'avvio, non dopo. Il meccanismo delle richieste di approvazione è descritto nell'articolo sulla supervisione umana degli agenti; i controlli applicati fuori dal modello sono approfonditi in perché i limiti devono stare fuori dal modello, mentre la scadenza delle autorizzazioni è il tema de la durata delle autorizzazioni concesse agli agenti.
Il privilegio minimo come abitudine
Limitare l'ambito di un agente AI non è una configurazione fatta una volta: è un'abitudine fatta di identità dedicate, concessioni per compito e revisioni che revocano. Il risultato non è un agente più lento, ma un agente di cui puoi spiegare e difendere ogni accesso, davanti alla direzione come davanti a un audit.
Guarda come vengono presentati e autorizzati gli interventi degli agenti.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.