Permessi minimi per AI agents: principio della least authority applicato

Nota di metodo: tutti i casi descritti sono pattern composti da audit reali, modificati per garantire la riservatezza dei clienti coinvolti. Nessun caso identifica un singolo cliente specifico.

Febbraio 2026, audit informale a una software house torinese, ventiquattro persone, agenzia di sviluppo per industria 4.0. Il founder mi sta mostrando l'agente che hanno costruito per assistere i loro PM nei progetti cliente. (Lo chiamano Marco, perché ai loro clienti piace pensarlo come una persona.) L'agente legge ticket Jira, chat Slack, allegati email, e produce status report settimanali.

Funziona bene, dice il founder. Apro la configurazione.

Marco ha un service account su Jira con permessi admin, su Slack con permessi enterprise admin, su Google Workspace con accesso lettura a tutte le caselle aziendali. Perché admin, chiedo. Perché in dev funzionava. Marco non ha mai scritto su Jira, non ha mai pubblicato su Slack, non ha mai mandato email. Eppure se domani un attaccante riesce a fargli leggere un ticket in modo sbagliato, Marco può cancellare tutto.

Questo è il pattern centrale di ASI03 Identity & Privilege Abuse della Top 10 OWASP Agentic 2026 (approfondito nel cluster su OWASP Top 10 Agentic mappato alle PMI italiane). Il rischio non è una vulnerability esotica, è il modo in cui quasi tutte le PMI italiane oggi assegnano permessi ai loro agenti.

Cos'è il principio della least authority

Esiste un principio classico in sicurezza che si chiama "least privilege" (POLP). Dai a un utente solo i permessi necessari al suo ruolo. Il problema è che POLP è stato pensato per umani che hanno ruoli stabili e identità conoscibili.

Per gli agenti AI serve qualcosa di più stretto, che si chiama "least authority" (POLA), formulato in modo formale da Mark Miller nella sua tesi PhD del 2006 alla Johns Hopkins University, "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control", che ha originato il linguaggio di programmazione E e l'intera tradizione object-capability security. La differenza pratica con POLP: POLP regola permessi per identità (utente o service account ha permessi minimi del suo ruolo), POLA regola permessi per capability passate da un'azione all'altra. Per gli agenti, dove l'identità è fluida e ogni invocazione di tool è un'azione potenzialmente diversa, POLA è il modello giusto.

In termini concreti per una PMI: non basta dire "questo agente è autorizzato come questo service account". Devi dire "questo agente, quando esegue questa specifica catena di azioni, ha capability X, Y, Z, scoped a questa specifica risorsa, valid per i prossimi quindici minuti". È uno dei sette principi operativi raccolti nella pillar sulla sicurezza agentica per le PMI italiane.

Sembra over-engineering. Lo è solo se non hai mai avuto un incident.

Tre pattern di excessive authority che vedo sempre

Negli audit alle PMI italiane (esperienza diretta non statisticamente pubblicata, da prendere come tale), tre pattern di permessi eccessivi tornano sempre.

Admin everywhere. È il pattern di Marco sopra. Il service account dell'agente ha permessi admin su tutti i sistemi a cui è connesso, perché in dev era comodo, perché il refactor sembrava complicato, perché "tanto solo l'agente lo usa". OWASP nelle attack scenarios documentate cita esplicitamente la cache di SSH keys in agent memory come vector reale: se l'agente ha accesso a credenziali admin per qualunque ragione, prima o poi un attacker convince l'agente a esfiltrarle.

Leftover dev permissions. L'agente è stato sviluppato in un ambiente staging dove aveva permessi rilassati per consentire iterazione veloce. Quando è stato promosso a produzione, qualcuno avrebbe dovuto restringere quei permessi alla baseline minima. Quasi mai succede. Il deploy di produzione eredita le credenziali dev, e nessuno se ne accorge finché non c'è un audit.

Scope creep over time. Il caso più sottile. L'agente è stato deployato a gennaio con permessi corretti. A marzo qualcuno ha aggiunto un tool nuovo che richiedeva permessi aggiuntivi, e per fretta lo ha aggiunto allo stesso service account. Ad aprile altro tool. A giugno l'agente ha quattro volte i permessi originari, nessuno ha tracciato la progression, e il "minimo necessario" del giugno è completamente diverso da quello di gennaio.

I tre pattern hanno in comune una causa: l'IAM policy non è un documento vivo. È stata scritta una volta, mai ri-letta.

Come progettare un service account per agente, in concreto

Quattro principi operativi che funzionano, basati sulla OWASP Cheat Sheet Series Authorization plus pratica diretta dalle audit.

Identità separate. L'agente non eredita l'identità dell'utente che lo ha invocato e non gira come root del sistema. Ha la sua identità tecnica, scopable, revocable indipendentemente, monitorabile in modo distinto. OAuth 2.0 con client credentials flow è il pattern moderno standard per questo. La separation è la base di tutto: senza identità separata, non puoi nemmeno pensare di scoping.

Credenziali short-lived. Token che scadono in minuti, non mesi. X.509 certificates ephemeral, SSH certificates temporanei, JWT con TTL ridotto. Il pattern just-in-time access significa che l'agente non ha credenziali permanenti pre-caricate, le richiede al runtime quando servono, le perde quando finisce il task. Riduce drasticamente il blast radius di un agente compromesso.

Capability scoping per azione. Quando l'agente chiede di eseguire un tool, la capability che riceve è strettamente quella necessaria a quel tool, non l'unione dei permessi di tutti i tool. Se Marco deve leggere un ticket Jira, riceve un token con scope read-only su quel singolo project, valid per quella sessione. Non un token admin globale che usa per leggere quel ticket.

Audit log granulare. Ogni privilege use dell'agente è loggato: cosa ha chiesto, perché, con quale scope, quando, con che esito. Cinque campi minimi. Permette di rispondere a domande tipo "tre giorni fa Marco ha cancellato un ticket, è stata azione legittima o exploitation?" in trenta secondi invece che in tre giorni di forensic. Pattern operativo completo nel cluster audit-ready agents: il logging che ti salva.

I quattro principi insieme costano tempo di design e zero soldi (sono pattern, non prodotti). Implementare anche solo i primi due cambia in modo radicale il rischio di un attacco ASI03.

Come testare senza romperti

Quattro check pratici per verificare se la tua IAM policy effettiva matcha quella documentata. Non servono tool a pagamento, servono trenta minuti di disciplina.

Audit periodico delle credenziali attive. Una volta al mese, listare tutti i service account associati ad agenti, per ognuno enumerare i permessi correnti, verificare che matchino il documento di IAM policy. Quasi sempre c'è almeno un agent che ha permessi non documentati. Quel finding è il fix del mese.

Dry run mode in staging con permessi bloccati. Cambia configurazione staging in modo che Marco abbia permessi minimi documentati. Lascia girare per una settimana. Vedi cosa rompe. Se qualcosa rompe e in produzione era seamless, vuol dire che produzione sta usando permessi non documentati che servivano per qualche edge case. È il pattern più comune.

Penetration test mirato a privilege escalation. Una volta a trimestre, chiedi a uno (idealmente esterno) di provare a far escalation di privilege via prompt injection o via cross-agent trust abuse. Se ci riesce, sei nel perimetro ASI03 senza saperlo. Se non ci riesce, il tuo modello ha tenuto. Documenta il test, è artefatto DORA-utile.

Review dello scope drift trimestrale. Confronta l'IAM policy del trimestre corrente con quella del trimestre precedente. Quanti permessi sono stati aggiunti? Erano necessari? Sono ancora necessari adesso? Quasi sempre la risposta è "qualcuno è stato aggiunto e nessuno l'ha mai usato in produzione". Quei permessi vanno rimossi.

I quattro check insieme richiedono mezza giornata al trimestre. Sono il fattore differenziale tra una PMI con agenti production-ready e una con agenti che funzionano "finché non succede qualcosa".

Il refactor doloroso che evita l'incident catastrofico

Quando ti rendi conto che la tua IAM policy attuale è il pattern di Marco, la tentazione è ignorare il problema. Tre giorni di refactor sembrano un investimento alto rispetto a un rischio teorico.

Il modo concreto di pensarci è chiedersi: se domani un cliente importante ti chiede una RFP DORA-style, e una delle clausole standard è "documentare che il vostro agente AI usa il principio del minimo privilegio", qual è il tempo che impieghi per produrre quella documentazione? Se la risposta è meno di un giorno, sei a posto. Se la risposta è "dovremmo prima refactorare", il refactor non è teorico, è il blocker della prossima vendita.

Il punto di partenza pragmatico, in tre step. Step uno: catalogare ogni service account associato ad agente, per ognuno listare i permessi attuali e quelli minimi necessari. Step due: per ogni agent, identificare il singolo permesso più ampio non strettamente necessario, e rimuoverlo o restringerlo. Step tre: deploy della configurazione restretta in staging per una settimana, raccogli incident report, fix se serve, deploy in prod.

Tre step, due settimane di lavoro spalmato, zero overhead operativo successivo.

L'alternativa è aspettare l'incident e refactorare durante la crisi. È sempre più costoso.

Vuoi un audit IAM policy sul tuo agente in produzione? Il calendario è pubblico, prenota un appuntamento e parliamone. Trenta minuti gratis, poi se ha senso costruiamo insieme. Danilo Lapegna · DL Solutions