Nel primo movimento abbiamo provato a rimettere in ordine una formula che sembra semplice soltanto finché non la guardiamo da vicino: il controllo non si perde da solo. Un sistema può diventare difficile da prevedere, può produrre strategie che nessuno aveva anticipato e può perfino cercare strade che non erano state immaginate da chi lo ha progettato; ma perché una di quelle strade produca conseguenze fuori dal modello occorre che esista un passaggio ulteriore. Il sistema deve poter raggiungere qualcosa. Deve poter leggere, scrivere, modificare, inviare, acquistare, autorizzare, aprire, cancellare, eseguire.
È qui che la parola autonomia rischia di diventare troppo generica. Diciamo che un agente è autonomo quando può compiere molte operazioni senza chiedere conferma, ma quell’autonomia non è una sostanza che cresce spontaneamente dentro il modello. È anche un insieme di porte aperte attorno al modello: credenziali, API, account, cartelle, reti, database, terminali, strumenti, permessi e identità digitali. Prima di domandarci che cosa abbia fatto l’agente, conviene allora porre una domanda più concreta: chi gli ha dato le chiavi?
Una capacità non è ancora un accesso
Un modello può essere capace di scrivere una query SQL senza poter entrare in alcun database. Può sapere come si invia una mail senza possedere un account dal quale spedirla. Può conoscere perfettamente i comandi necessari per cancellare un file e non avere nessuna cartella sulla quale quei comandi possano essere eseguiti. La capacità descrive ciò che il sistema saprebbe fare se ne avesse la possibilità; l’accesso descrive il punto nel quale qualcuno decide che quella possibilità debba diventare operativa.
La distinzione sembra tecnica, ma in realtà è una distinzione di responsabilità. Quando un agente viene collegato alla posta elettronica, a un archivio documentale, a un sistema di pagamento o a un’infrastruttura aziendale, non stiamo semplicemente aumentando la sua intelligenza. Stiamo costruendo un ponte fra ciò che il modello può generare e ciò che può accadere nel mondo. La qualità del modello conta, naturalmente, ma il tipo di ponte che decidiamo di costruire conta almeno altrettanto.
È un punto che avevamo già incontrato, da una prospettiva diversa, in Chi ha fatto la barca?. Anche quando l’esecuzione diventa molto autonoma, il compito non nasce nel vuoto: qualcuno stabilisce che un processo debba iniziare, definisce almeno una parte dello scopo e prepara l’ambiente nel quale l’esecuzione potrà svolgersi. Con gli agenti la stessa domanda si sposta un passo più avanti. Non basta chiedere chi ha aperto il compito. Bisogna chiedere anche chi ha aperto le porte.
Il permesso più comodo tende a diventare quello più largo
Esiste una ragione molto semplice per cui i sistemi finiscono spesso per ricevere più accessi di quanti ne richiederebbe il compito specifico: è più comodo. Creare un account con privilegi ampi è spesso più veloce che progettare autorizzazioni granulari. Collegare un agente a uno strumento generale può essere più semplice che costruirgli una funzione capace di svolgere una sola operazione. Consentire lettura e scrittura può evitare di dover distinguere in anticipo i casi nei quali la scrittura sarà davvero necessaria. Ogni semplificazione riduce il lavoro iniziale, ma contemporaneamente aumenta ciò che il sistema potrà fare quando qualcosa andrà diversamente dal previsto.
Il problema non appartiene soltanto all’intelligenza artificiale. La sicurezza informatica conosce da decenni il principio del privilegio minimo: ogni utente o processo dovrebbe ricevere soltanto gli accessi necessari a svolgere il compito assegnato. L’arrivo degli agenti rende quel principio ancora più interessante perché il processo al quale concediamo un permesso non esegue soltanto istruzioni statiche; interpreta contesti, pianifica passaggi intermedi e sceglie quali strumenti utilizzare. Più è flessibile il sistema, più diventa importante delimitare dall’esterno ciò che quella flessibilità può raggiungere.
Un agente incaricato di riassumere una casella di posta può aver bisogno di leggere messaggi; non ne segue che debba anche poterli cancellare o inviare. Un agente che consulta un catalogo prodotti può aver bisogno di leggere un database; non ne segue che debba poter modificare prezzi o eliminare record. Un assistente che prepara una fattura può avere bisogno di compilarla; non ne segue che debba anche autorizzarne il pagamento. La differenza fra questi casi non è nel modello. È nel perimetro che qualcuno ha deciso di costruirgli attorno.
Le credenziali non sono un dettaglio tecnico
Quando diciamo che un agente “accede” a un servizio utilizziamo una parola che nasconde una quantità enorme di scelte. Con quale identità entra? Usa le credenziali della persona che lo sta utilizzando oppure un account tecnico condiviso? Quel profilo può vedere soltanto i dati dell’utente o quelli di un’intera organizzazione? Il permesso scade al termine dell’operazione oppure rimane disponibile? Le azioni vengono registrate? Esiste un modo per distinguere ciò che ha fatto la persona da ciò che ha fatto il sistema per suo conto?
Queste domande diventano ancora più importanti quando l’agente attraversa servizi differenti. Un accesso a un calendario può sembrare innocuo finché non viene combinato con una casella di posta, una rubrica, un archivio di documenti e la possibilità di inviare messaggi. Nessuna di quelle connessioni, osservata da sola, descrive necessariamente un potere enorme; ma insieme possono costruire un sistema capace di raccogliere informazioni, prendere decisioni e agire con una libertà che nessuna singola autorizzazione lasciava intuire.
È uno dei motivi per cui l’ecosistema delle decisioni conta più del singolo modello. Il comportamento finale nasce dall’incontro fra capacità del sistema, strumenti disponibili, identità utilizzate, regole di autorizzazione, conferme richieste e obiettivi assegnati. Attribuire tutto ciò alla “volontà dell’IA” significa comprimere una rete di decisioni in un solo soggetto narrativo, proprio nel momento in cui avremmo bisogno di distinguerne i nodi.
Il confine importante non è tra leggere e agire, ma tra reversibile e irreversibile
Non tutti i permessi hanno lo stesso peso. Leggere una bozza e inviarla a un cliente sono due operazioni diverse. Preparare un ordine e confermare il pagamento non sono la stessa cosa. Individuare un file inutile e cancellarlo definitivamente appartengono a due livelli differenti di rischio. Eppure, quando progettiamo un flusso automatizzato, la tentazione è spesso quella di eliminare proprio il punto nel quale un essere umano dovrebbe fermarsi a confermare l’azione, perché quel punto rallenta il processo e riduce il vantaggio dell’automazione.
Qui la supervisione umana smette di essere una formula astratta e diventa una scelta architetturale. Possiamo decidere che un agente prepari ma non invii, proponga ma non applichi, selezioni ma non elimini, compili ma non paghi. Possiamo anche decidere il contrario e concedergli l’intero percorso. Non esiste una risposta identica per ogni applicazione, ma esiste sempre una decisione sul punto nel quale il sistema può passare dall’elaborazione all’effetto.
Il paradosso è che più un agente diventa utile, più cresce la pressione a rimuovere quelle interruzioni. Se deve chiedere conferma a ogni passaggio, ci domandiamo quale vantaggio offra rispetto a un normale assistente. Se invece gli permettiamo di completare l’intero flusso, otteniamo il beneficio dell’autonomia proprio aumentando ciò che potrebbe accadere senza che nessuno intervenga. Il potere operativo nasce esattamente in questa tensione: non quando il modello diventa improvvisamente libero, ma quando noi decidiamo che interromperlo troppo spesso ne ridurrebbe il valore.
La chiave può essere data una volta sola e continuare ad aprire porte
C’è poi un problema temporale. Una decisione presa oggi può continuare a produrre effetti molto dopo che abbiamo smesso di pensarci. Un token di accesso può restare valido. Un’integrazione può rimanere attiva. Un account creato per una prova può finire in produzione. Un permesso temporaneamente allargato per risolvere un problema può non essere più ristretto. La storia della sicurezza informatica è piena di autorizzazioni sopravvissute allo scopo per cui erano state concesse; con gli agenti, però, quelle autorizzazioni possono essere utilizzate da sistemi capaci di combinare strumenti e informazioni in modi non previsti al momento della configurazione.
Per questo il controllo non riguarda soltanto ciò che concediamo, ma anche ciò che rivediamo, revochiamo e limitiamo nel tempo. Un permesso non è una proprietà naturale del sistema. È una decisione che può essere modificata. Quando smettiamo di trattarla come tale, l’accesso comincia a sembrare parte dell’agente stesso e la responsabilità della configurazione arretra nuovamente sullo sfondo.
Chi consegna le chiavi decide anche quanto può costare un errore
Un agente può sbagliare per molte ragioni: interpretare male un’istruzione, ricevere informazioni manipolate, seguire un obiettivo nel modo sbagliato, combinare strumenti in una sequenza inattesa o comportarsi in maniera che il progettista non aveva anticipato. Ma il danno possibile non dipende soltanto dalla qualità del ragionamento. Dipende anche da ciò che il sistema è autorizzato a toccare.
Lo stesso errore può produrre conseguenze molto diverse in un ambiente di prova e in un sistema collegato a dati reali. La stessa istruzione può essere innocua se l’agente può soltanto leggere e pericolosa se può anche modificare. Lo stesso comportamento inatteso può fermarsi davanti a una richiesta di conferma oppure trasformarsi immediatamente in un’azione irreversibile. Parlare di sicurezza senza parlare di permessi significa quindi osservare soltanto una metà del rischio.
La domanda “chi ha dato le chiavi?” non serve a trovare un colpevole automatico. Serve a ricostruire la catena. Chi ha scelto lo strumento? Chi ha deciso l’identità con cui avrebbe operato? Chi ha stabilito i permessi? Chi ha ritenuto superflua una conferma? Chi ha valutato che il beneficio dell’automazione giustificasse quel livello di accesso? Solo dopo queste domande possiamo capire che cosa appartiene davvero al comportamento del modello e che cosa, invece, appartiene all’ambiente che abbiamo costruito perché quel comportamento potesse produrre effetti.
La domanda da cui partire
È possibile che gli agenti del futuro siano molto più capaci di quelli attuali e che riescano a individuare autonomamente vulnerabilità, concatenare strumenti e trovare percorsi che nessun progettista aveva immaginato. Proprio per questo il problema degli accessi non diventa meno importante; diventa più importante. Più un sistema è capace di scegliere come raggiungere un obiettivo, più dobbiamo sapere quali territori gli abbiamo reso attraversabili.
La macchina può trovare una porta che non avevamo previsto. Può perfino scoprire un modo inatteso di usare una chiave. Ma prima che quella chiave possa aprire qualcosa, qualcuno deve aver deciso che il sistema potesse averla.
Per questo, davanti a un agente che compie un’azione sorprendente, la seconda domanda di Dietro la macchina è ancora più concreta della prima: chi gli ha dato le chiavi, quali porte aprivano e perché abbiamo deciso che dovesse poterle usare?
Fonti e riferimenti
National Institute of Standards and Technology, Least privilege e NIST SP 800-171 Rev. 3. Il principio stabilisce che utenti e processi dovrebbero ricevere soltanto le autorizzazioni e le risorse minime necessarie a svolgere i compiti assegnati, con revisione e rimozione dei privilegi quando non sono più necessari.
OWASP Gen AI Security Project, LLM06:2025 Excessive Agency. La vulnerabilità viene ricondotta in particolare a funzionalità eccessive, permessi eccessivi e autonomia eccessiva; fra le mitigazioni sono indicati la riduzione degli strumenti disponibili, il privilegio minimo e l’approvazione umana per le azioni ad alto impatto.
Anthropic, Measuring AI agent autonomy in practice, 2026. L’analisi studia l’autonomia attraverso l’uso concreto degli strumenti e mostra come permessi limitati e richieste di approvazione umana siano già componenti osservabili delle architetture agentiche reali, distinguendo l’autonomia del modello dalle condizioni operative nelle quali viene utilizzato.