I rischi del ciclo di vita degli agenti AI espongono le lacune della sicurezza aziendale tradizionale
Google News ha riportato un'analisi di Hacker News del 22 luglio con un avvertimento netto: le aziende stanno implementando agenti AI più rapidamente di quanto i controlli sulle identità riescano a tenere il passo.
Il rapporto sostiene che gli agenti ereditano permessi, attraversano i confini tra applicazioni e prendono decisioni senza approvazione umana a ogni passaggio. Questa combinazione crea un conflitto che la tradizionale gestione di identità e accessi non è stata progettata per risolvere.
La questione centrale non è se un modello AI produca una risposta errata. È se un'identità software possa trasformare quella risposta in un'azione autorizzata. Un agente potrebbe interrogare un database, modificare un record cliente, inviare un messaggio o delegare il lavoro a un altro agente.
Questo cambia la domanda sulla sicurezza. Un tempo le organizzazioni si chiedevano se un utente dovesse accedere a un'applicazione. Ora devono decidere se un agente possa perseguire un obiettivo, utilizzare uno strumento specifico, trasferire l'autorità e mantenere l'accesso dopo che il suo scopo è cambiato.
L'analisi di Hacker News presenta il problema come un fallimento del ciclo di vita dell'identità. L'argomento è tempestivo, ma si tratta anche in parte di commento di esperti sostenuto da fornitori, anziché di un'indagine indipendente su una violazione.
La preoccupazione di fondo gode di un sostegno più ampio. NIST, OWASP e Cloud Security Alliance hanno tutti pubblicato lavori che affrontano identità degli agenti, autorizzazione, delega, eccessiva autonomia e governance del ciclo di vita.
Il consenso emergente è scomodo per gli acquirenti aziendali. Modelli migliori non producono automaticamente agenti più sicuri. La sicurezza dipende dalle identità, dalle credenziali, dalle policy, dagli strumenti, dalla memoria e dai sistemi di audit che circondano questi modelli.
Cosa ha messo a fuoco Google News
Il rapporto riformula la sicurezza degli agenti AI come un problema continuo di identità, non come un'approvazione una tantum dell'applicazione.
Un'applicazione convenzionale opera in genere attraverso percorsi di codice prevedibili. Gli amministratori assegnano permessi, gli sviluppatori definiscono le azioni previste e i team di sicurezza monitorano eventi riconoscibili.
Un agente AI aggiunge un livello di pianificazione probabilistico. Interpreta un obiettivo, sceglie passaggi intermedi, seleziona strumenti e modifica il proprio piano al variare delle condizioni. In questo contesto, AI agentica indica software in grado di decidere e agire verso un obiettivo con un intervento umano limitato.
Questa distinzione conta perché l'autorizzazione avviene spesso prima che sia nota l'intera sequenza di azioni. Un utente potrebbe chiedere a un agente di riconciliare un conto. L'agente potrebbe ispezionare record, chiamare un servizio esterno, generare un file e inviare il risultato.
Ogni singola chiamata a uno strumento potrebbe essere consentita. La sequenza completa potrebbe comunque produrre un esito non sicuro.
L'articolo di Hacker News identifica diversi schemi pratici di fallimento. Tra questi vi sono token di lunga durata con ambito eccessivo, agenti delegati con accesso più ampio dei loro orchestratori e credenziali che sopravvivono ai cambiamenti del ciclo di vita.
Non si tratta di difetti isolati del modello. Sono debolezze nel modo in cui le organizzazioni creano, identificano, autorizzano, monitorano, modificano e dismettono gli attori software.
NIST è giunto a una conclusione compatibile dopo aver raccolto contributi pubblici sulla sicurezza degli agenti. La sua analisi delle risposte sulla sicurezza del maggio 2026 ha rilevato un ampio consenso sul fatto che i principi di cybersecurity esistenti restino pertinenti. I partecipanti hanno però anche affermato che tali principi devono essere adattati agli agenti.
Questa conclusione evita una reazione eccessiva troppo semplice. Le aziende non devono abbandonare la gestione delle identità, lo sviluppo sicuro, il logging o la risposta agli incidenti. Devono applicare questi controlli a sistemi i cui piani e le cui scelte di strumenti cambiano durante l'esecuzione.
Google News non ha scoperto una singola vulnerabilità appena divulgata. Ha amplificato un avvertimento più strutturale. Le aziende stanno collegando gli agenti ai sistemi operativi prima di poter tracciare in modo affidabile ogni identità, permesso, delega e azione risultante.
Questo divario è il vero evento. L'implementazione degli agenti è entrata a tal punto nei flussi di lavoro aziendali che la sicurezza del ciclo di vita sta diventando un requisito operativo anziché una questione di ricerca.
La tempistica riflette anche un cambiamento più ampio negli standard. NIST ha lanciato una AI Agent Standards Initiative nel febbraio 2026, mentre OWASP ha pubblicato un quadro dedicato ai rischi delle applicazioni agentiche nel dicembre 2025.
Questi sforzi indicano che la sicurezza degli agenti ha superato le linee guida generiche per chatbot. Un chatbot produce contenuti che una persona può esaminare. Un agente può convertire contenuti generati in modifiche attraverso sistemi connessi.
Questa distinzione aumenta il costo di un errore. Una risposta allucinata è di solito un problema di qualità delle informazioni. Un piano allucinato eseguito con credenziali valide diventa un problema di sicurezza e di processi aziendali.
La domanda importante, quindi, non riguarda solo ciò che un agente sa. Riguarda ciò a cui può accedere, ciò che può modificare e se tali azioni possono essere annullate.
I sistemi di identità affrontano un divario di governance alla velocità degli agenti
Le revisioni degli accessi incentrate sugli esseri umani si muovono troppo lentamente per agenti che possono comparire, cambiare ruolo e delegare autorità all'interno di flussi di lavoro automatizzati.
La governance tradizionale delle identità segue un ciclo di vita familiare. Una persona entra in un'organizzazione, riceve accessi, cambia ruolo, viene sottoposta a revisioni periodiche e infine se ne va.
Gli account di servizio hanno complicato questo modello, ma sono rimasti relativamente statici. I team potevano associare un account a un'applicazione, assegnare credenziali e documentare uno scopo stabile.
Gli agenti AI sono più difficili da contenere in questa struttura. Un agente persistente può mantenere memoria e integrazioni tra sessioni. Un agente temporaneo potrebbe esistere solo il tempo necessario per completare un'attività.
Un orchestratore può anche creare sotto-agenti. Questi sotto-agenti potrebbero utilizzare modelli, strumenti o credenziali differenti, producendo una catena di delega che cambia mentre il flusso di lavoro è in esecuzione.
Ogni partecipante diventa un'identità non umana, ovvero un attore software che si autentica e agisce senza essere una persona. La sua identità deve comprendere più di un nome o di una chiave API.
I team di sicurezza devono sapere chi ha creato l'agente, quale persona ha avviato l'attività, quale scopo è stato approvato e quali strumenti sono disponibili. Devono inoltre conoscere il modello attuale dell'agente, la versione, il perimetro della memoria e l'autorità delegata.
Il framework sull'identità degli agenti della Cloud Security Alliance descrive l'identità di un agente come un profilo dinamico che copre origine, scopo, capacità, comportamento, relazioni e attestazioni.
Questo approccio mette in luce una debolezza delle credenziali statiche. Un token può confermare che un chiamante possiede un segreto. Non può spiegare autonomamente se l'obiettivo attuale dell'agente corrisponda allo scopo per cui è stato concesso l'accesso.
Questo produce un divario di autorizzazione tra identità e intenzione.
Supponiamo che un dipendente autorizzi un agente a riassumere il feedback dei clienti. L'agente potrebbe necessitare di accesso in lettura alle risposte ai sondaggi e ai ticket di assistenza. Non dovrebbe ottenere automaticamente il permesso di modificare gli account clienti o inviare messaggi esterni.
Un account di servizio con privilegi ampi può cancellare questi confini. Se l'agente incontra istruzioni malevole all'interno di un ticket, una prompt injection potrebbe reindirizzarne il comportamento mentre le stesse credenziali restano valide.
Prompt injection significa che istruzioni ostili entrano attraverso contenuti elaborati dal modello. L'input può influenzare il piano dell'agente anche se non sfrutta codice software convenzionale.
Il privilegio minimo riduce il danno, ma solo se applicato a livello di azione. Un agente che deve leggere un dataset per una sola attività non dovrebbe ricevere accesso permanente a ogni repository connesso.
La delega rende il problema più difficile. Un orchestratore potrebbe trasferire un'attività a un agente specializzato. Se il secondo agente dispone di autorizzazioni più ampie, il primo può raggiungere indirettamente sistemi a cui non è mai stato autorizzato ad accedere.
Ciò assomiglia a un'escalation dei privilegi, ma il percorso passa attraverso una normale orchestrazione. Ogni evento di autenticazione può apparire legittimo mentre la catena complessiva dell'autorità viola la policy.
Le organizzazioni devono inoltre preservare il contesto utente. Se un dipendente non può accedere a un record finanziario, un agente che agisce per quel dipendente non dovrebbe ottenerne l'accesso tramite la propria identità di servizio.
Le restrizioni dell'essere umano originale devono seguire l'attività in ogni passaggio di consegne. Altrimenti, un agente diventa un meccanismo per aggirare l'autorizzazione a livello utente.
Ciò esercita pressione sui responsabili della sicurezza delle informazioni, sui team di identità, sugli ingegneri di piattaforma e sui proprietari delle applicazioni. Nessuno può risolvere il problema da solo.
I team di identità controllano credenziali e policy. I team di piattaforma determinano le connessioni agli strumenti. Gli sviluppatori modellano il comportamento degli agenti, mentre i responsabili aziendali definiscono gli esiti accettabili.
La risposta imposta è un modello di controllo condiviso. Ogni agente di produzione necessita di un proprietario nominativo, uno scopo dichiarato, autorizzazioni delimitate, delega tracciabile e una scadenza o un evento di revisione.
La sola documentazione non riuscirà a tenere il passo. I controlli del ciclo di vita devono integrarsi con le pipeline di distribuzione, affinché un agente non possa entrare in produzione senza metadati relativi a proprietà e autorizzazione.
Questo ricorda la disciplina già utilizzata per l'infrastruttura come codice. I team dovrebbero trattare identità e autorizzazioni degli agenti come configurazione versionata, sottoposta a revisione insieme a modelli, prompt, strumenti e codice applicativo.
Il vero compromesso è tra autonomia e contenimento
Un agente diventa più utile man mano che acquisisce strumenti e autorità decisionale, ma quelle stesse capacità aumentano i danni derivanti da manipolazioni o errori.
Le organizzazioni adottano gli agenti perché possono completare attività in più passaggi. Un assistente che si limita a redigere testo comporta un rischio operativo limitato. Un agente in grado di recuperare dati, aggiornare record e comunicare esternamente offre più valore.
Crea anche un raggio d'impatto più ampio.
Il compromesso non è semplicemente tra sicurezza e convenienza. È tra autonomia e contenimento. Ogni strumento aggiunto amplia l'insieme degli esiti raggiungibili, compresi quelli che il progettista non aveva previsto.
Il framework sui rischi agentici di OWASP è stato sviluppato con il contributo di oltre 100 esperti, ricercatori e professionisti. Include rischi quali dirottamento degli obiettivi, uso improprio degli strumenti, abuso dell'identità, avvelenamento della memoria, comunicazione insicura tra agenti e fallimenti a cascata.
Queste categorie mostrano perché proteggere solo il modello di base sia insufficiente. Il modello si trova all'interno di un sistema di esecuzione più ampio.
La memoria può conservare contenuti non attendibili. Uno strumento può esporre una funzione distruttiva. Un messaggio da agente ad agente può trasferire contesto errato. Una credenziale valida può autorizzare un passaggio non sicuro.
L'intero sistema determina se un errore del modello resta un cattivo suggerimento o diventa un incidente operativo.
Si consideri un agente che aiuta un ingegnere a indagare su un'interruzione in produzione. Ha bisogno di log, dati di monitoraggio, contesto del codice e forse accesso agli strumenti di distribuzione.
L'accesso in sola lettura supporta la diagnosi con un impatto limitato. L'autorità di distribuzione consente all'agente di tentare una riparazione, ma un piano errato può ora modificare un sistema attivo.
Aggiungere l'approvazione umana prima delle modifiche in produzione riduce questo rischio. Limita però anche la velocità e l'autonomia che rendevano l'agente interessante.
Questo non significa che ogni azione richieda una persona. Le attività a basso rischio e reversibili possono ricevere un'autonomia più ampia. Le operazioni ad alto impatto o irreversibili meritano controlli più rigorosi.
Una policy efficace distingue le azioni in base alle conseguenze. Leggere un documento pubblico è diverso dall'esportare dati dei clienti. Creare una bozza è diverso dall'inviarla. Suggerire una modifica alla configurazione è diverso dall'applicarla.
La stessa distinzione dovrebbe modellare le credenziali. Un'autorizzazione di breve durata e limitata al compito restringe il periodo e le risorse disponibili a un agente compromesso.
Le chiavi statiche creano la condizione opposta. Possono sopravvivere alla fine di un'attività, comparire nei log o restare associate a un esperimento abbandonato.
La progettazione degli strumenti conta quanto quella delle credenziali. Un agente dovrebbe ricevere funzioni ristrette che incorporano i vincoli aziendali, anziché un accesso diretto a interfacce amministrative generiche.
Per esempio, una funzione di rimborso vincolata può imporre limiti di importo e richiedere un identificativo della transazione. Un ampio accesso in scrittura al database richiede al modello di far rispettare tali regole solo attraverso il ragionamento.
Gli agenti necessitano anche di garanzie transazionali. Un'esecuzione di prova può mostrare le modifiche pianificate prima dell'esecuzione. Le operazioni reversibili possono preservare una possibilità di ripristino, mentre i passaggi di conferma possono bloccare modifiche irreversibili.
I registri di audit devono acquisire più della chiamata API finale. Gli investigatori hanno bisogno dell'utente che ha avviato l'azione, dell'identità dell'agente, della decisione di policy, della richiesta allo strumento, degli attori delegati e della conseguente modifica di stato.
Le tracce di ragionamento in linguaggio naturale richiedono cautela perché possono contenere dati sensibili e potrebbero non spiegare in modo affidabile il comportamento del modello. I record strutturati degli eventi offrono una traccia di sicurezza più affidabile.
Il sistema dovrebbe registrare ciò che è stato richiesto, ciò che la policy ha consentito, quale strumento è stato eseguito e cosa è cambiato. Questi fatti contano più di una narrazione generata sul perché l'agente abbia agito.
Questo approccio protegge anche i flussi di lavoro basati sulla conoscenza. I team che usano una base di conoscenza consultabile dovrebbero separare il recupero delle informazioni dall'autorità di modificare i sistemi sorgente.
Un agente può aiutare a individuare il contesto interno senza ricevere il permesso di modificare ogni repository connesso. Questo confine preserva gran parte del beneficio limitando al contempo il rischio d'azione.
Il contenimento non può eliminare l'incertezza. I modelli restano probabilistici e gli aggressori possono cercare input che producono piani imprevisti.
L'obiettivo pratico è rendere i percorsi non sicuri difficili, visibili, limitati e recuperabili. L'autonomia dovrebbe aumentare solo quando queste salvaguardie sono state testate rispetto a flussi di lavoro realistici.
I controlli del ciclo di vita devono sopravvivere a ogni modifica dell'agente
La creazione è solo il primo punto di controllo della sicurezza, perché scopo, strumenti, modello, memoria e autorizzazioni di un agente possono tutti cambiare in seguito.
Molte organizzazioni concentrano le proprie revisioni sul lancio. Un team approva un agente, fornisce le credenziali, verifica gli strumenti iniziali e lo porta in produzione.
Questo processo presuppone che il sistema approvato resti stabile. Gli agenti raramente lo fanno.
Un aggiornamento del modello può modificare la selezione degli strumenti. Una nuova integrazione può ampliare i dati raggiungibili. Un prompt rivisto può cambiare il modo in cui l'agente interpreta il proprio ruolo.
La memoria persistente può introdurre nuovo contesto nel tempo. Un team aziendale potrebbe anche riutilizzare un agente senza ripetere la revisione di sicurezza originale.
Ogni modifica può invalidare una precedente decisione di autorizzazione. La gestione del ciclo di vita deve quindi collegare l'accesso alla configurazione attuale dell'agente, non soltanto alla sua registrazione iniziale.
Il documento concettuale sull'identità di NIST del febbraio 2026 si è concentrato sull'applicazione di standard e migliori pratiche in materia di identità agli agenti software e AI.
Il documento ha richiesto contributi su identificazione, autorizzazione, audit, non ripudio e difese contro l'iniezione di prompt. Tale ambito riflette il numero di livelli di controllo che devono operare insieme.
La registrazione dovrebbe creare un record univoco dell'agente con un proprietario umano, una finalità aziendale, un ambiente approvato e una scadenza definita. L'accesso dovrebbe restare bloccato finché questi campi non esistono.
Il provisioning dovrebbe emettere credenziali adeguate all'attività invece di copiare i privilegi di uno sviluppatore. I segreti dovrebbero evitare l'archiviazione hardcoded e supportare la rotazione o la scadenza automatica.
Il deployment dovrebbe associare l'identità approvata a una versione specifica della configurazione dell'agente. Modifiche sostanziali dovrebbero attivare una nuova valutazione e certificazione degli accessi.
L'operatività richiede un monitoraggio continuo. I team di sicurezza dovrebbero rilevare sequenze insolite di strumenti, destinazioni dati inattese, deleghe anomale e attività al di fuori della finalità approvata.
La risposta agli incidenti deve supportare la revoca immediata in ogni sistema connesso. Disabilitare l'interfaccia visibile dell'agente non è sufficiente se token, account di servizio o identità delegate restano attivi.
Il ritiro è la prova finale. Un agente inutilizzato può lasciare dietro di sé credenziali, trigger, archivi di memoria, integrazioni e autorizzazioni a valle.
Se questi componenti restano, l'agente non è davvero scomparso. È diventato un'identità orfana con una proprietà non chiara e un accesso potenzialmente valido.
Questo rischio è facile da trascurare perché non resta alcun dipendente a lamentarsi di un account non funzionante. Gli accessi software inattivi possono persistere silenziosamente finché un aggressore non li scopre.
La dismissione completa dovrebbe revocare le credenziali, interrompere i trigger pianificati, disabilitare le richieste in ingresso, rimuovere le connessioni agli strumenti e applicare le regole di conservazione dell'organizzazione al contesto archiviato.
I team dovrebbero poi confermare che i sistemi a valle non accettino più l'identità ritirata. Un ticket di chiusura non è prova di revoca.
Il punto difficile è la scala. I fogli di calcolo manuali non possono tracciare in modo affidabile gli agenti che compaiono e cambiano attraverso sistemi di sviluppo automatizzati.
Le organizzazioni hanno bisogno di un inventario collegato all'infrastruttura di deployment e identità. Ogni agente dovrebbe essere individuabile per proprietario, finalità, ambiente, insieme di strumenti, insieme di credenziali e stato attuale del ciclo di vita.
Questo inventario supporta anche l'analisi degli incidenti. I team di sicurezza possono chiedersi quali agenti abbiano utilizzato un connettore compromesso, ereditato uno strumento vulnerabile o eseguano ancora una configurazione del modello obsoleta.
Tuttavia, l'inventario non equivale al controllo. Una dashboard può rivelare un agente con privilegi eccessivi senza impedirne l'azione successiva.
I sistemi di ciclo di vita più efficaci rendono l'accesso condizionato alla policy attuale. Proprietà mancante, finalità scaduta o modifiche non approvate alla configurazione dovrebbero limitare automaticamente l'esecuzione.
Esiste anche il rischio di trattare le affermazioni dei fornitori come prove consolidate. L'articolo di Hacker News presenta un'argomentazione coerente sulla sicurezza delle identità, ma le sue raccomandazioni dovrebbero essere testate nell'architettura di ciascuna organizzazione.
Le imprese differiscono per il modo in cui gli agenti sono costruiti, autenticati e connessi. Un agente temporaneo per la programmazione presenta rischi diversi rispetto a un agente di assistenza clienti con memoria persistente.
I controlli dovrebbero seguire le capacità e le conseguenze effettive. Applicare un unico modello di governance a ogni agente può creare burocrazia senza ridurre i rischi più elevati.
I team di sicurezza necessitano di test basati su scenari. Dovrebbero valutare cosa accade quando un agente riceve contenuti ostili, delega in modo inatteso, perde il proprio proprietario o conserva le credenziali dopo il ritiro.
Le esercitazioni di red team dovrebbero testare flussi di lavoro completi anziché prompt isolati. Un'iniezione bloccata ha un significato limitato se un altro percorso tramite strumenti raggiunge la stessa azione sensibile.
L'obiettivo è un contenimento misurabile. I team dovrebbero sapere se la policy impedisce azioni non autorizzate, se gli avvisi arrivano tempestivamente e se le credenziali possono essere revocate in tutte le integrazioni.
Tre segnali indicheranno se la sicurezza degli agenti sta recuperando terreno
La prossima fase sarà decisa da standard applicabili, prove di deployment e controllo misurabile sulle identità degli agenti.
Il primo segnale è una guida concreta dalla NIST AI Agent Standards Initiative. NIST ha dichiarato che il programma affronterà interoperabilità, infrastruttura di identità, autenticazione e valutazione della sicurezza.
Architetture di riferimento dettagliate rafforzerebbero l'idea che l'identità degli agenti richieda controlli distinti. Principi vaghi senza indicazioni di implementazione lascerebbero le imprese dipendenti da modelli concorrenti dei fornitori.
I risultati più utili definirebbero come l'intento umano si trasmette attraverso la delega. Specificherebbero inoltre quali prove un agente presenta quando richiede l'accesso e come i sistemi verificano tali prove.
Questo segnale è importante perché standard frammentati creano anelli deboli. Una piattaforma può emettere un'identità dell'agente dettagliata, mentre un'altra la riduce a un token bearer riutilizzabile.
Il secondo segnale è il modo in cui le organizzazioni implementano i rischi agentici di OWASP. La pubblicazione di una Top 10 crea un linguaggio comune, ma l'adozione richiede modifiche ingegneristiche.
Gli acquirenti dovrebbero osservare se le piattaforme per agenti espongono controlli di policy a livello di chiamata dello strumento. Dovrebbero inoltre esaminare il supporto per credenziali di breve durata, delega vincolata e registri immutabili delle azioni.
Le valutazioni di sicurezza dovrebbero andare oltre i test basati solo sui prompt. Un test significativo deve osservare se un input manipolato può produrre modifiche di stato non autorizzate lungo un flusso di lavoro completo.
Le prove di test riproducibili rafforzerebbero l'argomento secondo cui l'autonomia può espandersi in sicurezza. La dipendenza continua da ampi account di servizio dimostrerebbe che il deployment resta avanti rispetto alla governance.
Il terzo segnale sono i dati sul ciclo di vita provenienti dagli ambienti aziendali. I responsabili della sicurezza hanno bisogno di misure di base prima di poter affermare di avere il controllo.
Tali misure includono la percentuale di agenti con proprietari nominati, finalità approvate, date di scadenza e credenziali con ambito limitato. I team dovrebbero anche monitorare la rapidità con cui possono revocare ogni credenziale collegata a un agente.
La copertura conta più del numero di avvisi. Una policy di monitoraggio perfetta offre poca protezione se metà degli agenti dell'organizzazione resta sconosciuta.
Lo stesso principio vale per il ritiro. Le organizzazioni dovrebbero verificare se gli agenti dismessi perdono l'accesso in ogni applicazione connessa, non soltanto nella piattaforma principale.
Google News continuerà a far emergere avvertimenti man mano che i deployment degli agenti si diffondono, ma gli acquirenti dovrebbero guardare oltre il ciclo delle notizie. Le prove decisive proverranno dal comportamento di autorizzazione all'interno di sistemi reali.
Un'impresa può ricondurre ogni azione dell'agente a una persona e a una finalità approvata? Può fermare una delega non sicura prima dell'esecuzione?
Può modificare le autorizzazioni quando cambia il ruolo dell'agente? Può ritirare l'identità completa senza lasciare indietro token, memoria o integrazioni?
Queste domande offrono uno standard pratico per sviluppatori, team di sicurezza e acquirenti aziendali. Trasformano una preoccupazione generale sul rischio dell'AI in controlli osservabili.
L'argomentazione di Hacker News è più solida se letta come un avvertimento sul ciclo di vita, non come prova che ogni sistema di identità esistente abbia fallito. I controlli tradizionali restano essenziali, ma necessitano di trigger più rapidi e di un contesto più ricco.
Le organizzazioni dovrebbero iniziare dai propri agenti con le conseguenze più rilevanti. Identifichino cosa tali agenti possono modificare, quali credenziali utilizzano e come l'autorità si muove attraverso ogni passaggio di consegne.
Poi testino uno scenario scomodo: se un agente viene manipolato oggi, l'organizzazione può contenere le sue azioni e rimuoverne completamente l'accesso?
Se la risposta non è chiara, il deployment è già più avanti della sua governance.
