Permessi per gli agenti IA: come limitare strumenti, dati e azioni allo stretto necessario

L’autorità dell’agente non coincide con quella del sistema

Un agente può interpretare una richiesta, scegliere gli strumenti e concatenare operazioni. Questo non significa che debba decidere a quali risorse è autorizzato ad accedere o quali può modificare. L’autorizzazione effettiva spetta ai sistemi che contengono i dati o eseguono le azioni: il repository, il servizio di posta elettronica, l’API o la piattaforma aziendale. Il modello può proporre un’operazione; il sistema di destinazione deve verificare se l’identità che la richiede può eseguirla su quella specifica risorsa.

Questa distinzione è importante perché l’agente può sbagliare, ricevere istruzioni fuorvianti o scegliere uno strumento inadatto. Le istruzioni nel prompt e le regole che filtrano gli strumenti disponibili aiutano a orientare il comportamento, ma non dovrebbero essere l’unica misura di controllo. Se un percorso alternativo consente di eseguire la stessa operazione con credenziali ampie, il filtro degli strumenti non impedisce l’accesso. È opportuno combinare i limiti imposti nell’interfaccia dell’agente con controlli di identità e autorizzazione applicati dagli strumenti e dai servizi collegati.

L’obiettivo pratico non è rendere l’agente incapace di commettere qualsiasi errore. È ridurre ciò che può accadere se interpreta male il compito: limitare le risorse accessibili, distinguere la lettura dalla modifica, ridurre al minimo la durata dell’accesso ed evitare che una singola credenziale trasformi un errore in un’azione dalle conseguenze estese. Le raccomandazioni di questa guida sono criteri di progettazione; la loro applicazione concreta dipende dalle funzionalità e dal modello di autorizzazione di ciascuna piattaforma.

Fare l’inventario di attività, risorse ed effetti prima di concedere l’accesso

Inizia descrivendo le attività che l’agente deve svolgere, non elencando tutti i connettori che sarebbe possibile attivare. Per ciascuna attività, individua chi la richiede, di quali dati ha bisogno, quale strumento li fornisce e quale risultato ci si aspetta. Registra poi gli effetti potenziali di ogni operazione. Consultare un documento, modificarlo, inviare un messaggio ed eliminare un record sono capacità diverse, anche se sono disponibili tramite lo stesso servizio.

Separa i dati personali dell’utente da quelli condivisi con un team o un’organizzazione. La separazione deve riguardare anche la risorsa specifica: il fatto che un agente debba leggere una cartella di progetto non gli dà motivo di accedere in lettura a tutto il repository. Stabilisci inoltre se l’attività viene svolta per conto di una persona oppure come applicazione autonoma. Nelle piattaforme che distinguono i permessi delegati da quelli applicativi, questa differenza incide sull’identità rappresentata e sui limiti applicabili.

Non classificare un’operazione basandoti soltanto sul nome dello strumento. Una chiamata di “aggiornamento” può modificare un campo innocuo oppure cambiare uno stato che innesca processi successivi. Descrivi l’effetto osservabile e chi potrebbe subirne le conseguenze. Se l’impatto non è chiaro, non presumere che l’operazione sia a basso rischio: delimita il suo ambito e prova il comportamento in un ambiente controllato prima di abilitarla in produzione.

Progettare profili di minimo privilegio per attività e utenti

Dopo aver completato l’inventario, definisci un profilo per ogni attività. Specifica quale identità la esegue, quali strumenti può chiamare, su quali risorse, con quali azioni e per quanto tempo. Un profilo come “accesso alla posta” è troppo vago. Un profilo utile chiarisce, per esempio, che un’attività può consultare i messaggi di una persona per preparare un riepilogo, ma non può inviare, eliminare o modificare messaggi.

Quando è importante che l’utente mantenga i propri limiti, un’autorizzazione delegata può essere più adatta di una credenziale applicativa dotata di un accesso autonomo e ampio. La documentazione di Microsoft Graph distingue i permessi delegati, limitati a ciò che l’utente può fare, dai permessi applicativi, concessi all’applicazione. Questa distinzione non elimina la necessità di configurare permessi di minimo privilegio e non garantisce, da sola, che ogni operazione sia circoscritta correttamente: occorre verificare quali permessi richiede l’integrazione e come li usa il sistema.

In alcuni ambienti, lo scambio di token consente di ottenere credenziali destinate a una risorsa specifica o di rappresentare una delega. Lo standard OAuth per lo scambio di token descrive questo meccanismo, ma la sua disponibilità e i suoi vincoli concreti dipendono dall’implementazione. Non presentare un token temporaneo come automaticamente sicuro: verifica destinatario, soggetto, azioni autorizzate, durata e condizioni di rinnovo. Se l’ambiente non supporta credenziali circoscritte, documenta il limite e compensalo con controlli sul sistema di destinazione, separazione delle funzioni e supervisione.

Autorizzare ogni operazione nel sistema di destinazione

Una policy che limita gli strumenti disponibili può ridurre gli errori di selezione: per esempio, può fare in modo che l’agente veda solo un insieme approvato di strumenti. Tuttavia, non dimostra che la singola chiamata sia autorizzata. La documentazione di Amazon Bedrock AgentCore descrive elenchi di strumenti consentiti e avverte che questo filtro non sostituisce i permessi IAM per altri percorsi di esecuzione. In termini di progettazione, il filtro dell’agente e la policy della risorsa sono livelli distinti e vanno verificati separatamente.

Il sistema di destinazione deve verificare almeno l’identità effettiva, l’azione richiesta e la risorsa interessata. Se l’autorizzazione dipende dall’utente, non basta verificarla una volta quando viene creata la sessione e poi fidarsi senza ulteriori controlli del contesto. Definisci come viene verificata l’identità a ogni operazione e cosa succede se i permessi cambiano mentre l’attività è ancora in corso. Le modalità di implementazione dipendono dalla piattaforma; non bisogna quindi presumere che tutti i connettori rivalutino i permessi allo stesso modo.

Le policy basate sulle risorse e quelle basate sulle identità possono essere combinate con regole contestuali. AWS documenta policy basate sulle risorse per AgentCore che consentono di specificare principal, azioni e condizioni e raccomanda di concedere soltanto i permessi necessari. Usa questo tipo di documentazione per capire il modello di valutazione del servizio scelto; non copiare una policy di esempio senza verificare quale risorsa, principal e azione interessi nella tua distribuzione.

Separare preparazione, approvazione ed esecuzione delle azioni sensibili

L’approvazione umana è utile quando un’operazione può inviare informazioni a terzi, modificare dati condivisi, eliminare contenuti o cambiare permessi. Non dovrebbe consistere in un pulsante generico “continua”. Prima di decidere, la persona deve capire quale operazione verrà eseguita, su quale risorsa, con quali dati e con quale effetto previsto. Se l’anteprima omette il destinatario, il contenuto da inviare o l’ambito della modifica, l’approvazione non consente di valutare adeguatamente il rischio.

L’approvazione deve inoltre essere collegata all’operazione sottoposta a verifica. Se dopo l’approvazione cambiano la destinazione, gli argomenti, la risorsa o l’azione, è necessaria una nuova decisione. Evita di trasformare un’approvazione occasionale in un permesso generale che l’agente possa riutilizzare per altre attività. L’interfaccia deve indicare chiaramente chi approva e per conto di chi verrà eseguita l’operazione.

La documentazione dell’SDK per agenti di OpenAI descrive un flusso in cui una chiamata a uno strumento sensibile può essere sospesa per una revisione, con la possibilità di esaminare lo strumento e i suoi argomenti prima di riprendere o rifiutare l’esecuzione. È un esempio di meccanismo di revisione, non una garanzia che qualsiasi operazione sia sicura: spetta comunque al team decidere quali strumenti richiedono una sospensione e se i dati mostrati a chi approva sono sufficienti per valutarne gli effetti.

Limitare la durata e verificare la revoca dell’accesso

Concedere l’accesso per una singola sessione o attività riduce il periodo durante il quale una credenziale può essere riutilizzata, se l’ambiente supporta questa modalità. Definisci quando l’autorizzazione inizia e termina, se può essere rinnovata e chi può farlo. Non confondere una sessione breve con un ambito ristretto: una credenziale di breve durata che consente di eliminare tutti i dati può comunque avere conseguenze molto estese finché è attiva.

Progetta la revoca come un’operazione che deve poter essere verificata. Rimuovi il permesso o invalida la credenziale, quindi invia nuove richieste usando la stessa identità. Controlla anche le sessioni già aperte, i token nella cache, i processi in background e i nuovi tentativi. La risposta dipende dal fornitore: alcune modifiche possono avere effetto immediato, mentre altre possono essere soggette a propagazione o alla durata delle credenziali già emesse. Se la documentazione non chiarisce il comportamento, registra l’incertezza e verifica il caso nell’ambiente pertinente.

Per ridurre il rischio di accesso persistente, assegna, quando possibile, credenziali diverse ad agenti, ambienti e attività ed evita di copiare i segreti degli utenti in prompt, cronologie o registri. Se usi la delega o lo scambio di token, conserva soltanto le informazioni necessarie per operare e svolgere verifiche. La revoca non sostituisce la progettazione iniziale dei permessi: è un’ulteriore misura di difesa per gestire cambiamenti del personale, incidenti o attività concluse.

Registrare decisioni e risultati senza trasformare i log in un nuovo rischio

Un registro utile permette di ricostruire chi ha richiesto un’attività, quale identità è stata usata, quale strumento è stato chiamato, quale risorsa si è tentato di raggiungere, quale decisione ha preso il sistema e quale risultato si è ottenuto. Conserva identificativi delle richieste e date e orari sufficienti per correlare gli eventi tra l’agente e il servizio di destinazione. Distingui tra una chiamata tentata, un’autorizzazione concessa e un’operazione completata: non sono la stessa cosa.

Non registrare token, chiavi, password o altri segreti. Evita anche di archiviare automaticamente tutto il contenuto consultato o inviato. Definisci quali dati servono per indagare sui problemi, come proteggerli, chi può accedervi e per quanto tempo conservarli. In alcuni casi basta registrare l’identificativo della risorsa e un riepilogo del tipo di operazione; in altri può essere necessario conservare un’anteprima, adottando misure di tutela della privacy.

Usa la telemetria per individuare schemi che meritano attenzione: rifiuti ripetuti, tentativi di accedere a risorse estranee all’attività, chiamate di scrittura inattese o uso di una credenziale dopo la revoca. Uno schema osservato non prova, da solo, che si sia verificato un abuso: è un segnale da approfondire alla luce del contesto della richiesta e delle policy vigenti.

Verificare i limiti, compresi i tentativi fuori ambito

Prima della distribuzione, trasforma ogni permesso concesso in un test positivo e in diversi test negativi. Il test positivo dimostra che l’attività legittima funziona con l’ambito previsto. I test negativi verificano che lo stesso agente non possa cambiare utente, accedere a una risorsa condivisa non autorizzata, usare un’operazione di scrittura quando dispone soltanto di accesso in lettura, eliminare record o invocare uno strumento al di fuori della sua finalità. Ripeti i test quando cambiano connettori, ruoli, policy o flussi di approvazione.

Verifica sia l’interfaccia dell’agente sia il sistema di destinazione. Se l’agente non propone uno strumento vietato, controlla comunque che una chiamata diretta o un percorso alternativo non riesca a eseguire l’azione con le credenziali disponibili. Verifica che un’approvazione non autorizzi argomenti diversi da quelli esaminati e che un permesso revocato blocchi le richieste successive. Per le operazioni ad alto impatto, usa dati e risorse di prova che consentano di osservarne gli effetti senza coinvolgere persone o servizi reali.

Un test superato non dimostra che il sistema sia sicuro in ogni circostanza. Dimostra che determinati casi hanno prodotto il risultato atteso in una specifica configurazione. Conserva l’identità di prova, la policy applicata, i passaggi eseguiti e il risultato, così potrai ripetere la verifica dopo un aggiornamento. Se una piattaforma nasconde parte della valutazione dei permessi o non fornisce registri sufficienti, annotalo come limite invece di presumere che il controllo abbia funzionato.

Limiti dei controlli ed errori da evitare

I permessi riducono l’insieme delle azioni possibili, ma non garantiscono che l’agente interpreti correttamente un’attività o che la risposta sia esatta. Un permesso di lettura può esporre informazioni sensibili se l’insieme di documenti autorizzato è troppo ampio. Un permesso di scrittura circoscritto può comunque produrre una modifica sbagliata entro quell’ambito. Per questo la progettazione combina autorizzazione, convalida degli input, revisione proporzionata al rischio e test del comportamento.

Evita di concedere una credenziale amministrativa per semplificare l’integrazione, di affidarti al prompt per impedire operazioni indesiderate o di presumere che un elenco di strumenti consentiti equivalga a una policy completa. Non trasformare neppure il consenso dell’utente per un’attività in un’autorizzazione persistente per altre attività. Le istruzioni e le approvazioni guidano il processo; l’autorizzazione effettiva deve restare limitata nell’identità e nel sistema collegato.

Questa guida riguarda l’autorità tecnica e il modo di circoscriverla. È distinta da una guida sull’iniezione indiretta di istruzioni, che si concentra su contenuti non attendibili che cercano di dirigere l’agente, e da una guida al ripristino dopo i guasti, che affronta la risposta agli errori e agli effetti parziali. Gli argomenti sono collegati: un’istruzione ostile può cercare di provocare un’azione indesiderata, mentre i permessi e i controlli sul sistema di destinazione determinano quali azioni sono effettivamente possibili.

Lista di controllo prima della distribuzione e dopo ogni modifica

Esamina il modello di autorizzazione prima di attivare un agente e ripeti la verifica quando viene aggiunto uno strumento, cambia un connettore, si amplia l’insieme dei dati o viene modificata una policy. La persona responsabile deve poter spiegare quale attività giustifica ciascun permesso e quali conseguenze avrebbe una chiamata errata. Se non è possibile individuare un uso legittimo di una capacità, disattivala finché la questione non è chiarita.

Come riferimento operativo, verifica che la configurazione distingua lettura, scrittura, invio, eliminazione e modifiche degli accessi; delimiti utente e risorsa; e non si basi esclusivamente sulle istruzioni del modello. Verifica il processo di approvazione delle operazioni sensibili, le informazioni visibili a chi approva, la registrazione delle decisioni e dei risultati e la procedura di revoca dell’accesso. Esegui i test negativi descritti sopra con le identità e i sistemi che verranno usati in produzione.

Questa lista non sostituisce la revisione di sicurezza del prodotto né la documentazione specifica del fornitore. È un metodo per rendere espliciti i presupposti che spesso restano nascosti quando si collegano strumenti. Se le funzionalità dell’ambiente non consentono di applicare un limite necessario, registra la lacuna, valuta il rischio e modifica la progettazione dell’attività o del flusso prima di concedere un accesso più ampio.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.