Permessi minimi per agenti AI: come applicare la least authority

Un agente legge Jira, Slack e allegati email per preparare un riepilogo del lavoro. Non deve pubblicare messaggi né inviare posta, ma usa ancora le credenziali di amministratore impiegate durante lo sviluppo. Se viene indotto a cambiare compito, quelle credenziali potrebbero consentirgli anche di modificare o divulgare dati.

La categoria ASI03 Identity & Privilege Abuse di OWASP riguarda proprio l'abuso di identità e permessi. La distinzione pratica è fra ciò che l'agente dovrebbe fare e ciò che i sistemi collegati gli permettono davvero. La guida alle dieci categorie OWASP inquadra anche gli altri rischi.

Per iniziare, scegli un flusso che deve soltanto leggere dati e chiedi a chi lo gestisce quali permessi usa. Compila due colonne: azioni necessarie e azioni effettivamente consentite. Il nome tecnico dell'identità usata dal software è service account; IAM indica il sistema che gestisce identità e accessi.

Cos'è il principio della least authority

Il minimo privilegio, o least privilege, assegna a un'identità soltanto i permessi necessari. Per un agente conviene controllare anche come quei permessi vengono usati: da quale strumento, su quali dati, per quanto tempo e con quale possibilità di revoca.

In questa guida, minima autorità, o least authority, significa limitare l'autorizzazione anche al singolo compito. Un'autorizzazione circoscritta a un'azione e a una risorsa viene chiamata capability. Per esempio, leggere un ticket e confermare un pagamento richiedono poteri diversi anche quando li chiede lo stesso agente.

La domanda da fare diventa quindi: quale strumento può eseguire questa azione, su quale risorsa, fino a quando e come gli tolgo l'accesso? È uno dei controlli descritti nella guida alla sicurezza agentica per le PMI.

Se il flusso è solo lettura su dati pubblici, il disegno può restare semplice. Se scrive, invia o paga, questa distinzione diventa una misura concreta del danno massimo.

Tre modi in cui i permessi diventano troppo ampi

Amministratore su tutti i sistemi. Durante lo sviluppo era comodo usare un account potente e nessuno lo ha più sostituito. OWASP cita fra i propri scenari di attacco anche le chiavi SSH, credenziali per l'accesso remoto, conservate nella memoria dell'agente. Un agente compromesso può sfruttare i poteri delle credenziali che riesce a raggiungere, anche se il suo compito abituale è innocuo.

Permessi di sviluppo rimasti in produzione. L'ambiente di prova usa accessi più ampi e il sistema pubblicato eredita la stessa identità. Confronta regole di accesso e credenziali dei due ambienti: il nome assegnato al ruolo non dimostra quali operazioni consenta.

Permessi aggiunti e mai riesaminati. L'agente parte con accessi adeguati, poi ogni nuovo strumento ne aggiunge altri alla stessa identità. Confronta la configurazione attuale con quella approvata in precedenza e chiedi il motivo di ogni aggiunta. Nei sistemi di autorizzazione, l'insieme di azioni e risorse consentite viene spesso chiamato scope.

Nei tre casi, dopo una modifica nessuno ha verificato che i permessi reali corrispondessero ancora al compito e alle regole documentate.

Come progettare un service account per agente, in concreto

Quattro principi operativi basati sulla OWASP Authorization Cheat Sheet.

Identità separate. Evita che l'agente erediti un'identità amministrativa o giri come root. Dagli un'identità tecnica revocabile e osservabile; il meccanismo può essere OAuth client credentials, workload identity o l'equivalente della piattaforma.

Credenziali a durata breve. Il componente che esegue gli strumenti riceve un token, cioè una credenziale temporanea, valido per il tempo necessario. Alla fine del compito serve una revoca effettiva o una scadenza applicata dal servizio. Durata e ampiezza sono due limiti indipendenti: un token amministrativo valido pochi minuti conserva poteri amministrativi durante quei minuti.

Autorizzazioni limitate all'azione. Lo strumento riceve solo i poteri necessari al compito. Per leggere un ticket Jira, per esempio, deve avere accesso in sola lettura al progetto pertinente, per il tempo previsto. Un token amministrativo globale resta troppo ampio anche se l'agente lo usa abitualmente per leggere un solo ticket.

Registro delle operazioni. Per ogni azione registra identità, strumento, permessi usati, data e ora ed esito. Queste informazioni devono consentire di ricostruire l'accaduto senza conservare indiscriminatamente tutte le conversazioni. La guida ai log degli agenti AI mostra quali informazioni raccogliere.

I principi non richiedono per forza un nuovo prodotto, ma hanno costo di progettazione, migrazione e gestione. La verifica è concreta: compromettendo un tool di test, l'accesso resta confinato alla risorsa e alla durata previste.

Come provare i permessi in sicurezza

Per confrontare permessi reali e regole documentate servono quattro verifiche. Assegna chi le esegue, quando ripeterle e dove conservare gli esiti; puoi partire dagli strumenti che hai già.

Controllo delle credenziali attive. Elenca le identità tecniche degli agenti e i relativi permessi, poi confrontali con le regole approvate. Per ogni accesso non documentato assegna una persona che ne chiarisca l'uso e una data entro cui decidere se mantenerlo. Ripeti il controllo con una frequenza adeguata al ritmo dei cambiamenti.

Prova con permessi limitati. Restringi le credenziali in un ambiente di prova isolato. Per il report, leggere un ticket del progetto consentito deve riuscire; modificare lo stesso ticket deve essere negato dal sistema di autorizzazione. Se il servizio non offre questa granularità, usa un componente intermedio limitato o lascia manuale il passaggio. Un errore generico non dimostra un problema di permessi: verifica nei log il rifiuto autorizzativo.

Prova indipendente dei limiti. In un ambiente isolato, chiedi a una persona diversa da chi ha costruito il flusso di tentare un'azione vietata, per esempio inserendo istruzioni ostili in un documento o in un messaggio fra agenti. Se riesce, correggi il percorso che ha permesso l'accesso. Se il tentativo viene bloccato, conserva la prova senza scambiarla per una garanzia contro ogni attacco. Ripetila in base al rischio e dopo modifiche rilevanti.

Revisione dei permessi aggiunti. Confronta la configurazione corrente con quella precedente. Quali accessi sono stati aggiunti? Quale strumento li usa? Servono ancora? Rimuovi quelli senza un compito attivo e verificato.

Il tempo necessario dipende da agenti e permessi. Hai concluso questa prima verifica quando l'inventario corrisponde al sistema reale, ogni accesso aggiunto ha una motivazione e una persona è responsabile di ciascuna autorizzazione ampia ancora necessaria.

Da quale modifica cominciare

Restringere i permessi di un sistema già in uso richiede lavoro e può interrompere operazioni lecite se la modifica viene fatta alla cieca. Per questo conviene partire da un accesso preciso e provarne la sostituzione prima della produzione.

Se un cliente chiede di vedere permessi, responsabili e controlli dell'agente, devi poter rispondere dalla configurazione reale. La stessa ricostruzione ti serve per sapere che cosa puoi restringere senza bloccare il lavoro.

Comincia dall'inventario: per ogni identità tecnica dell'agente, annota i permessi attuali e quelli necessari al compito. Restringi il primo permesso eccessivo nell'ambiente di prova, esegui casi consentiti e vietati e conserva gli esiti. Prima di passare in produzione prepara la configurazione precedente per il ripristino e assegna chi controllerà il risultato.

La modifica è pronta quando la configurazione ristretta supera le prove critiche nell'ambiente isolato, i permessi rimossi non ricompaiono e hai assegnato la verifica successiva.

Aspettare l'incidente sposta il refactor nel momento peggiore, quando hai meno tempo e più incertezza.

Per applicare queste verifiche al tuo caso, porta descrizione del flusso, permessi e risultati delle prove al servizio di controllo e sicurezza degli agenti AI. Partiamo dalla prima lacuna concreta e definiamo come verificarne la correzione.