Quando un agente AI legge le email, crea bozze d’ordine nel gestionale o aggiorna il CRM, sta facendo il lavoro di una persona. Per questo va gestito come una persona. Ogni agente ha bisogno di un account suo e di permessi minimi, cioè solo quelli che servono al compito. Le sue credenziali devono poter essere revocate in un minuto. E serve un registro delle azioni che dica chi ha fatto cosa e per conto di chi. In questo articolo spiego come imposto i permessi degli agenti AI nei progetti per le PMI, sistema per sistema. Gli esempi sono quelli tipici di un’azienda italiana: Microsoft 365 o Google Workspace, un ERP, un CRM, la PEC.
Il tema non è teorico. Commvault Italia descrive gli agenti autonomi come “dipendenti digitali” che portano un rischio nuovo dentro data center e ambienti cloud. Il rischio non arriva dall’esterno. Arriva da software a cui l’azienda stessa ha dato le chiavi.
Perché un agente non deve usare l’account di una persona
La scorciatoia più comune è questa: si prende l’utente dell’amministratore o di chi segue il progetto, si generano le credenziali e le si passa all’agente. Funziona subito, ma crea tre problemi.
- Permessi eccessivi. L’agente eredita tutto quello che può fare quella persona. Se l’utente è amministratore dell’ERP, anche l’agente lo è, compresa la cancellazione di anagrafiche e documenti.
- Log illeggibili. Nel gestionale risulta che “Mario Rossi” ha modificato 300 righe d’ordine alle 3 di notte. Dopo un errore, nessuno sa se è stato Mario o l’agente.
- Revoca impossibile senza danni. Per fermare l’agente devi cambiare la password di Mario, che così resta bloccato. Peggio ancora: se Mario lascia l’azienda e il suo account viene disattivato, l’agente si ferma senza preavviso.
La regola che applico è semplice: un agente, un’identità. Se due agenti fanno lavori diversi, per esempio uno smista le email e l’altro prepara i preventivi, hanno due identità separate.
Un’identità per ogni agente: come si fa in pratica
Ogni sistema ha il suo modo di creare identità non umane. Quelli che uso più spesso:
- Microsoft 365: una registrazione applicativa in Entra ID con permessi API limitati. Dove possibile restringo l’accesso alla posta a caselle specifiche, per esempio solo ordini@ e non tutte le caselle del tenant.
- Google Workspace: un service account dedicato. Uso la delega a livello di dominio solo quando è indispensabile, e sempre con scope ristretti.
- ERP e CRM: un utente tecnico con un ruolo creato apposta, non uno dei ruoli standard come “amministratore” o “commerciale”. Molti gestionali italiani prevedono utenze API separate. Se il gestionale non le prevede, si crea comunque un utente nominato chiaramente, per esempio agente-ordini.
- Strumenti di automazione (n8n, Make o simili): credenziali distinte per ogni workflow che usa l’agente. Non una connessione unica condivisa da tutti i flussi.
- Provider del modello AI: una chiave API per agente. Così controlli i costi per singolo agente e puoi spegnerne uno senza toccare gli altri.
A ogni identità associo un responsabile umano, cioè una persona dell’azienda che risponde di quell’agente. Senza un responsabile, l’agente diventa un account orfano. E gli account orfani sono esattamente quelli che nessuno controlla.
Permessi minimi: la matrice agente, sistema, azione
Prima di scrivere codice compilo una tabella. Le righe sono gli agenti, le colonne sono i sistemi, e in ogni cella scrivo le azioni consentite. Le azioni le divido in tre livelli.
Lettura
L’agente può consultare, ma solo i dati che servono. Un agente che classifica le richieste di assistenza deve leggere i ticket e lo storico del cliente. Non deve vedere i listini riservati o i dati del personale.
Scrittura limitata e reversibile
L’agente può creare oggetti in uno stato provvisorio: bozze d’ordine, ticket, note sul CRM, email in bozza. Sono operazioni che una persona può correggere o annullare senza conseguenze. Su questo livello si gioca gran parte del valore di un progetto, ad esempio quando si mette un agente sopra ERP e CRM.
Azioni irreversibili o con effetti esterni
Rientrano qui l’invio di email ai clienti, la conferma di un ordine, l’emissione di un documento, un pagamento, l’invio di una PEC o la cancellazione di record. Per questi casi le strade sono due. O l’agente non ha il permesso, oppure ce l’ha solo dopo una conferma umana esplicita, registrata nel log. La cancellazione la escludo quasi sempre: un agente che archivia è sufficiente.
Esempio concreto. Un agente legge la casella ordini e prepara le righe nel gestionale. Può leggere quella sola casella. Può leggere anagrafiche clienti e articoli. Può creare ordini in stato “da verificare”. Non può confermarli, non può modificare i prezzi di listino e non vede i fornitori. Se il gestionale non permette una granularità così fine, inserisco tra agente e gestionale un piccolo servizio intermedio che espone solo le operazioni consentite.
Credenziali revocabili, a scadenza e conservate bene
Un’identità separata serve a poco se le sue credenziali sono una password scritta in un file di configurazione. I punti che verifico sono questi:
- Token a breve durata dove il sistema lo consente, per esempio OAuth con refresh token, invece di chiavi statiche valide per sempre.
- Rotazione programmata delle chiavi API, con una data scritta nella documentazione del progetto.
- Conservazione in un vault, mai nel codice o nei prompt. Ne ho parlato nell’articolo sulla gestione dei secrets.
- Un interruttore unico. Revocare l’accesso di un agente deve essere un’operazione di un minuto, documentata e alla portata del responsabile interno, non solo del fornitore. Questo è il primo passo di una procedura di stop e rollback in caso di incidente.
Il registro delle azioni: chi, cosa, per conto di chi
Il log è ciò che trasforma un agente da scatola nera a collega verificabile. Per ogni azione registro:
- l’identificativo dell’agente e la versione della sua configurazione (prompt, modello, strumenti abilitati);
- l’evento che ha avviato l’azione, per esempio l’email ricevuta, la richiesta dell’utente o il job schedulato;
- lo strumento chiamato, i parametri e la risposta del sistema;
- l’eventuale conferma umana, con nome e orario;
- un ID di correlazione che lega il log dell’agente a quello del sistema di destinazione.
Conviene tenere due livelli di log: quello dell’agente e quello del sistema su cui agisce. Se coincidono, bene. Se non coincidono, hai trovato un problema. Attenzione però: i log contengono spesso dati personali di clienti e dipendenti. Vanno quindi trattati secondo il GDPR, con tempi di conservazione definiti e accesso limitato.
Agenti che lavorano per conto di un utente
C’è un caso più delicato: l’assistente interno che un dipendente interroga in chat e che può agire sui sistemi per lui. Qui l’agente non dovrebbe mai avere più permessi della persona che lo usa. Il principio corretto è l’intersezione: l’agente può fare solo ciò che è consentito sia al suo ruolo sia all’utente che ha fatto la richiesta. Se un magazziniere chiede all’assistente di mostrargli i margini per cliente, l’assistente deve rispondere che non ha accesso, anche se tecnicamente potrebbe leggerli. Nella pratica questo si ottiene passando l’identità dell’utente fino agli strumenti, con meccanismi tipo on-behalf-of. In alternativa si filtrano i dati lato server in base al ruolo. Non basta scrivere nel prompt “non mostrare i margini”.
Ciclo di vita: dall’attivazione alla dismissione
Gli agenti nascono, cambiano e vengono spenti, come gli strumenti e le persone. Per questo tengo un inventario che per ogni agente riporta:
- lo scopo e il responsabile interno;
- le identità e i sistemi a cui accede, con i permessi effettivi;
- la data dell’ultima revisione dei permessi;
- la procedura di dismissione: quali account disattivare, quali chiavi revocare, quali workflow spegnere.
La revisione periodica serve a ripulire i permessi aggiunti “temporaneamente” durante il test e mai tolti. Per le aziende rientranti nella NIS2 (d.lgs. 138/2024), controllo degli accessi e gestione degli asset sono già tra le misure di sicurezza richieste. Includere gli agenti in questi processi non aggiunge burocrazia: completa ciò che va fatto comunque.
Domande frequenti
Serve un account a pagamento per ogni agente?
Dipende dal sistema. Le registrazioni applicative e i service account di Microsoft e Google di norma non richiedono una licenza utente. Alcuni ERP e CRM invece contano le utenze API come utenti. Va verificato con il fornitore prima di progettare, perché incide sul costo del progetto.
Bastano le istruzioni nel prompt per limitare cosa fa l’agente?
No. Il prompt orienta il comportamento, ma può essere aggirato, per esempio con una prompt injection nascosta in un’email. I limiti veri sono i permessi sui sistemi: ciò che l’account non può fare, l’agente non lo farà, qualunque cosa gli venga scritto. Le altre protezioni le ho descritte nell’articolo sui guardrail per gli agenti AI.
Il gestionale non ha ruoli granulari: cosa si può fare?
Si mette un livello intermedio, cioè una piccola API o un server MCP, che espone all’agente solo le operazioni ammesse e verifica i parametri. L’agente parla con quel livello, non direttamente con il database del gestionale.
Chi risponde se l’agente sbaglia?
L’azienda che lo usa, attraverso il responsabile interno indicato nell’inventario. Per questo serve un nome per ogni agente, insieme a log completi e a una procedura di stop chiara, definiti prima di andare in produzione.
Partire con le basi giuste
Account dedicato, permessi minimi, credenziali revocabili, log e inventario non rallentano un progetto di agenti AI. Sono le condizioni che permettono di estenderlo ad altri reparti senza perdere il controllo. Se vuoi introdurre agenti o automazioni nei tuoi processi, o mettere in ordine quelli che già girano con le credenziali di qualcuno, contattami. Partiamo dalla mappa di sistemi e permessi e costruiamo da lì un’implementazione verificabile.
