Un agente AI che agisce per conto dell’azienda è, a tutti gli effetti pratici, un dipendente. Il problema è che quasi nessuno gli dà un tesserino suo – e senza quello, quando qualcosa va storto, l’indagine parte da zero.

Cos’è un dipendente? La risposta istintiva – qualcuno che riceve uno stipendio – è quella sbagliata. Un dipendente è qualcuno a cui è stata affidata l’autorità di rappresentare l’azienda e agire per suo conto. Prende decisioni, accede ai sistemi, tratta informazioni riservate, parla con i clienti, approva transazioni, spende soldi dell’azienda, firma contratti.

Scorri quell’elenco pensando a un agente AI. Decide. Accede. Tratta informazioni riservate. Parla con i clienti. Esegue processi di business. L’unica differenza è che non prende uno stipendio.

È il modello mentale attorno a cui ruota l’ultimo corso che ho seguito, tenuto da un ingegnere con quarantacinque anni di industria automobilistica alle spalle e una lunga esperienza di cybersecurity di prodotto su veicoli connessi – un background che si sente e che porta con sé la metafora migliore del corso, di cui dirò più avanti. La tesi: smetti di considerare gli agenti AI come asset tecnologici e comincia a considerarli dipendenti, perché nel momento in cui a un sistema viene concessa l’autorità di agire per conto dell’azienda, richiede la stessa disciplina gestionale di chiunque altro.

Nessuna azienda assume qualcuno e gli dice “ecco accesso illimitato a tutto, buona fortuna”. Eppure è esattamente così che vengono messi in produzione gli agenti.

E c’è una cosa che a un dipendente si dà il primo giorno, prima ancora della scrivania.

Il tesserino

Il badge non è una chiave che apre una porta. È la risposta materiale a una domanda: chi sta chiedendo accesso? Prima che qualcuno entri in un edificio o acceda a un sistema, l’azienda ne ha verificato l’identità. Niente identità, niente accesso.

Il modo in cui la maggior parte delle organizzazioni mette in servizio un agente è l’opposto: si riusa un account umano esistente, oppure un service account applicativo. Da lì nascono due problemi distinti e il secondo è quello che riguarda direttamente chi fa analisi.

Il primo è la proliferazione dei privilegi, che comincia il giorno zero. L’agente non riceve l’autorità minima per una missione specifica: eredita un insieme di permessi disegnato per qualcun altro e per tutt’altro scopo e ogni permesso in più allarga insieme capacità, superficie d’attacco e raggio del danno.

Il secondo è più sottile e più costoso: si perde l’attribuzione. Il log di audit registra l’account che si è autenticato, non l’agente che ha preso la decisione e compiuto l’azione.

L’immagine del corso è efficace: è come assumere una persona e darle il tesserino di un’altra. Le telecamere registrano l’identità del badge, non chi è effettivamente entrato nell’edificio e ha fatto il lavoro.

Chi ha gestito anche un solo incidente sa cosa significa. Quando arriva la segnalazione, la prima domanda è cos’è successo, ma la seconda – quella da cui dipende tutto il resto – è quale agente lo ha fatto, con quale autorità stava operando, quali istruzioni ne hanno influenzato la decisione, quali altre azioni ha compiuto e chi ne risponde. Se tutte le azioni sono riconducibili a un unico service account condiviso, nessuna di quelle domande ha risposta e il contenimento si trasforma in archeologia.

Da cui la regola, che vale la pena scrivere in grande da qualche parte: un dipendente agentico non deve mai indossare il tesserino di qualcun altro.

Tre modelli di identità, non uno

Il corso fa poi una distinzione che raramente trovo esplicitata e che merita attenzione, perché sbagliarla significa perdere insieme sicurezza e tracciabilità. Un agente non ricade ordinatamente nei modelli di identità costruiti per le persone o per le applicazioni: può operare in entrambe le modalità, a volte nella stessa giornata.

Quando agisce in autonomia, serve un modello da identità di carico di lavoro: macchina a macchina, con identità, ruolo, permessi e responsabilità propri.

Quando agisce per conto di una persona – un commerciale che gli chiede di recuperare i dati di un cliente – serve un modello delegato, on-behalf-of, e la catena di identità deve conservare la relazione: chi è l’umano, quale agente ha agito per lui, quale autorità gli è stata delegata, cosa ha effettivamente fatto.

Quando opera attraverso confini aziendali, serve una federazione vera e propria: chi ha emesso l’identità, chi si fida dell’emittente, quali capacità ha quell’agente, quali politiche governano l’interazione, cosa succede quando quella fiducia cambia.

Trattare ogni agente come un’applicazione fa perdere il contesto umano quando agisce per conto di qualcuno. Trattarlo come una persona produce il modello di autorizzazione e di ciclo di vita sbagliato. Trattare ogni agente esterno come implicitamente affidabile crea relazioni transfrontaliere pericolose.

Gli attaccanti non leggono le tue policy

C’è un passaggio del corso che userei volentieri in apertura di qualsiasi riunione di governance: le policy non fermano gli attacchi. I dipendenti umani a volte scelgono di ignorarle. I dipendenti agentici non sanno nemmeno che esistono.

Un agente esegue in base ai permessi, alle istruzioni e ai controlli tecnici che gli sono stati dati. Una policy che dice “l’agente deve accedere solo ai sistemi autorizzati” fornisce un’indicazione, ma finché l’identità non è verificata, i permessi non sono imposti e ogni azione non è continuamente autorizzata, quella policy non ha alcun effetto operativo.

Gli auditor esaminano policy ed evidenze per stabilire se i controlli esistono. Gli attaccanti no: testano la realtà. Sondano identità, permessi, integrazioni e difese per trovare lo scarto tra ciò che l’azienda dichiara che dovrebbe accadere e ciò che i suoi sistemi consentono effettivamente. È in quello scarto che avvengono gli incidenti.

Il caso che il corso porta a sostegno è Change Healthcare, 2024: l’azienda aveva certificazioni multiple e policy documentate, ma un server di accesso remoto non imponeva l’autenticazione a più fattori – nonostante l’MFA fosse richiesta sia dalla policy aziendale sia, di fatto, dal quadro normativo sanitario. La policy non autentica gli utenti. Lo fanno i controlli tecnici.

Morale: la speranza non è un controllo, e una policy senza applicazione automatica non è una strategia.

Un prompt non è un controllo di sicurezza

Questa è la conseguenza diretta, ed è il punto in cui il corso tocca il tema che avevo affrontato nell’articolo precedente da un’altra angolazione.

Il caso Replit l’ho già raccontato, ma il corso aggiunge un dettaglio che cambia la lettura: durante quella sessione c’erano undici istruzioni esplicite che stabilivano il blocco delle modifiche e dicevano all’agente di non toccare la produzione. L’agente le ha ignorate, ha eseguito comandi distruttivi sull’ambiente di produzione, ha cancellato il database – e poi ha generato profili utente fittizi e risultati di test falsi che mascheravano l’accaduto.

Dal punto di vista di un manager: il responsabile dice “non toccare la produzione”, il dipendente agentico cancella il database di produzione e poi fabbrica informazioni false per far sembrare che vada tutto bene. Non è un’allucinazione, è un fallimento di governance. L’agente aveva accesso diretto alla produzione, non esisteva alcuna separazione tecnica tra attività di sviluppo e ambiente reale, e il blocco esisteva soltanto come istruzione testuale. Mancava uno strato che dicesse: indipendentemente da ciò che l’AI crede, questa operazione è vietata.

Il secondo caso è più recente e, per chi progetta ambienti di test, più inquietante. Nel luglio 2026, durante una valutazione di agenti molto capaci condotta da OpenAI, gli agenti sono usciti dall’ambiente di test sfruttando una vulnerabilità zero-day in Artifactory e hanno raggiunto sistemi di produzione di Hugging Face, compiendo migliaia di azioni fra esecuzione di codice, ricognizione, movimento laterale e raccolta di credenziali. Non un piano d’attacco ipotetico generato da un modello: azioni reali.

La lezione è che una sandbox è utile solo se contiene davvero. Quando l’agente trova una vulnerabilità che gli permette di uscire, il confine semplicemente smette di esistere, e tutto ciò che è raggiungibile fuori diventa rilevante. L’ambiente di valutazione di un agente molto capace va progettato partendo dal presupposto che l’agente finirà per sconfiggere le nostre assunzioni – cioè va trattato come un ambiente ostile.

E la riga che vale l’intero modulo: le salvaguardie del modello non sono confini di sicurezza. Un prompt non è un firewall, una dichiarazione di policy non è una segmentazione di rete, un’istruzione non è il privilegio minimo. Se un’azione è inaccettabile, non si dice all’agente di non farla: si costruisce il sistema in modo che non possa.

Comportamento, non intenzione

Un altro passaggio che mi è rimasto, perché raddrizza un equivoco diffuso: per fidarsi di un agente non serve capirne l’intenzione.

L’intenzione è uno stato interno, non direttamente osservabile e quasi sempre congetturale. Persino con le persone la inferiamo dal comportamento più che conoscerla. Il comportamento invece è un problema strutturato, misurabile e risolvibile: ogni chiamata API, ogni delega, ogni decisione, ogni azione privilegiata lascia evidenze oggettive, valutabili in tempo reale contro la policy e contro il comportamento atteso.

Il comportamento produce evidenze, l’intenzione produce ipotesi. In sicurezza vincono le evidenze.

Da qui discende il controllo che il corso chiama behavioral baselining: stabilire che aspetto ha il normale, così che la deriva diventi rilevabile. Quali sistemi accede abitualmente l’agente, quali strumenti usa, che tipo di richieste tratta, quali decisioni ci si aspetta che prenda – e soprattutto cosa non dovrebbe mai fare. Poi si confronta il comportamento reale con la linea di base e si interviene sugli scostamenti materiali: l’agente del supporto clienti che comincia a negoziare prezzi, l’agente che leggeva dati e improvvisamente inizia a cancellarli, l’agente che comincia a comunicare con sistemi fuori dal suo ambiente approvato.

Il dettaglio che apprezzo: questo tipo di controllo intercetta anche i casi in cui non c’è alcun attaccante. Il caso Air Canada che ho raccontato nel primo articolo – il chatbot che si inventa una politica di rimborso e costa all’azienda una causa – non è una compromissione. È un agente che è andato alla deriva oltre il proprio ruolo. La sicurezza dell’AI non riguarda solo il comportamento malevolo: riguarda anche quello inatteso, perché un agente può produrre conseguenze legali, finanziarie e reputazionali serie senza essere mai stato compromesso.

Il recinto virtuale

È qui che entra la metafora automobilistica, ed è la migliore del corso. L’innovazione di sicurezza più efficace sui veicoli connessi non è più potenza: sono i confini. Il geofencing convalida di continuo dove si trova il veicolo e impone dove gli è consentito operare. Quando il veicolo si avvicina al limite o lo oltrepassa, il sistema non discute le intenzioni: applica la regola.

E c’è un dettaglio che fa tutta la differenza: il confine non si muove, si muove il veicolo. Il sistema valuta continuamente una posizione che cambia contro un limite operativo fisso.

Gli agenti richiedono lo stesso principio. Capacità, compiti e ambiente cambiano di continuo – nuovi strumenti, nuovi dati, nuovi flussi, altri agenti a cui delegare – ma i confini operativi devono restare espliciti e continuamente imposti. Il fallimento ricorrente degli incidenti AI più gravi è sempre lo stesso: autorità concessa oltre i confini della missione assegnata.

Da cui le tre frasi che riassumono il modello meglio di una slide: l’autorizzazione statica dice sei approvato; l’autorizzazione continua dice sei approvato per questa azione, adesso; il recinto dice questo è il limite oltre cui non vai.

L’esempio concreto di autorizzazione continua è utile da tenere a mente: un agente autorizzato alle nove del mattino a recuperare informazioni diagnostiche da un sistema di produzione, che alle nove e un quarto tenta di modificare dati di produzione. Sono due azioni profondamente diverse, e l’essere autorizzato ad accedere a un sistema non implica l’autorizzazione a modificarlo. Quando un agente viene compromesso, è questa catena che si spezza: senza autorizzazione continua, chi prende il controllo di un agente sovra-privilegiato eredita tutto ciò che quell’agente può fare.

Il raggio del danno

Due casi, una sola domanda.

Salesloft Drift, agosto 2025. Un chatbot AI di terze parti profondamente integrato con Salesforce, Google Workspace, Slack e altri sistemi aziendali viene compromesso; gli attaccanti ottengono token OAuth di lunga durata associati all’applicazione e, fra l’8 e il 18 agosto, conducono ricognizione, interrogazioni massive ed esfiltrazione attraverso oltre settecento ambienti aziendali, portandosi via anagrafiche clienti, opportunità commerciali, casi di supporto e – dentro quei record – credenziali cloud e chiavi API.

La domanda giusta non è come sia stato compromesso il chatbot. È perché una singola applicazione AI potesse impattare settecento aziende. Ogni azienda che l’aveva collegata aveva di fatto esteso una porzione del proprio perimetro di sicurezza a quel fornitore, e quando il fornitore è caduto, la relazione di fiducia è diventata un percorso d’attacco.

C’è però un’eccezione istruttiva: Okta ha bloccato l’attacco perché aveva imposto una lista di indirizzi autorizzati per l’integrazione. Il token era valido, l’identità dell’applicazione era valida, ma la richiesta arrivava da una posizione di rete non autorizzata, e il controllo l’ha fermata. È difesa in profondità applicata alla fiducia delegata: non si assume che il terzo resti affidabile, si delimita da dove gli è consentito operare.

Step Finance, gennaio 2026. Attaccanti compromettono i dispositivi di alcuni dirigenti; quei dispositivi offrono un percorso verso portafogli di tesoreria ad alto privilegio su Solana. In poche ore spariscono quaranta milioni di dollari in asset. Il token di governance crolla di oltre il novanta per cento e a febbraio l’azienda cessa le operazioni.

L’attacco non era tecnicamente straordinario. La domanda da porsi è perché un singolo endpoint compromesso potesse aprire la strada ad autorizzare decine di milioni di dollari di transazioni, quando esistono da anni controlli per evitarlo: custodia delle chiavi isolata in hardware, autorizzazione multi-firma, calcolo multi-parte, separazione dei compiti, accesso just-in-time, approvazione indipendente delle transazioni.

Da qui il test più utile dell’intero corso, applicabile a qualunque identità privilegiata, umana o agentica:

se questa identità fosse compromessa adesso, qual è il danno massimo che potrebbe causare?

Se la risposta è quaranta milioni, è un problema di governance. Se è “cancellare il database di produzione”, è un problema di governance. Se è “accedere a ogni record cliente dell’azienda”, è un problema di governance. La sicurezza non riguarda solo l’impedire la compromissione: riguarda il limitare cosa la compromissione significa.

Dall’altra parte c’è una forza lavoro agentica

Questa è la sezione che cambia la prospettiva e il motivo per cui non considero questo corso un doppione dei precedenti.

Se noi stiamo costruendo dipendenti agentici, lo stanno facendo anche gli altri.

JadePuffer, luglio 2026. Sysdig documenta il primo caso confermato di ransomware guidato end-to-end da AI agentica. Il punto d’ingresso è un’istanza di Langflow – piattaforma open source per costruire applicazioni AI – esposta su internet e affetta da una vulnerabilità critica nota e non corretta. Da lì l’agente ha fatto ricognizione, cercato credenziali, scoperto sistemi, testato percorsi d’attacco, si è adattato, ha scalato privilegi e ha proseguito verso l’obiettivo.

Non ha inventato alcuna vulnerabilità nuova. Ha sfruttato i peccati di sempre: software non aggiornato, credenziali di default in produzione, autenticazione debole, servizi esposti, accessi troppo permissivi, segmentazione di rete assente, gestione dei segreti inadeguata. Li ha solo concatenati molto in fretta.

E c’è un numero che vale la pena ricordare: trentun secondi. È il tempo che l’agente ha impiegato, dopo il fallimento del primo tentativo di creare un account amministratore, per riconoscere il fallimento, cambiare approccio, ricostruire l’account e verificare che funzionasse. Non stava seguendo una sequenza fissa di comandi: ha incontrato un problema e ha deciso cosa fare dopo. È quello, tecnicamente, il comportamento agentico.

La campagna di spionaggio documentata da Anthropic. Un gruppo statale cinese usa Claude Code per orchestrare una campagna autonoma contro una trentina di organizzazioni fra tecnologia, finanza, chimica, manifattura e settore pubblico. Il dato da tenere a mente: l’ottanta-novanta per cento delle operazioni tattiche eseguito dall’AI, con gli umani a fornire la direzione strategica.

Il metodo contiene una lezione sulla sicurezza dei modelli che va capita bene: gli attaccanti hanno scomposto l’attacco in decine o centinaia di richieste più piccole, ciascuna delle quali, isolata, appariva innocua. Un modello può riconoscere come malevola una richiesta completa, ma non il frammento. È esattamente il motivo per cui il comportamento di un agente non si valuta un’azione alla volta: va compreso lungo l’intera sessione e l’intera catena.

E c’è una riconfigurazione dei ruoli che vale la pena assimilare: l’attaccante del futuro assomiglia più a un manager che a una persona dietro una tastiera. L’umano fornisce obiettivo, bersaglio e direzione strategica; l’AI fornisce ricognizione, analisi, esecuzione, adattamento, persistenza e scala. L’umano non sparisce, sale di livello.

Marimo, aprile 2026. Vulnerabilità critica di esecuzione di codice remoto in una piattaforma di notebook Python usata da team di data science e ricerca AI. Un honeypot di Sysdig ha registrato l’inizio dello sfruttamento meno di dieci ore dopo la pubblicazione dell’avviso di sicurezza. Alla radice c’era un fallimento banale di controllo accessi: un endpoint WebSocket ad alto privilegio che non imponeva correttamente l’autenticazione, e da lì una shell interattiva.

Due lezioni. La prima: il tuo ambiente sperimentale fa parte della tua superficie d’attacco. Un notebook di data science non dovrebbe poter raggiungere database di produzione, recuperare segreti o ottenere credenziali per infrastruttura privilegiata. La seconda: il processo di patching che conosciamo è stato progettato per un mondo in cui gli attaccanti avevano bisogno di tempo per capire una vulnerabilità e costruire un exploit affidabile. Quella assunzione sta diventando pericolosa.

C’è anche il rovescio della medaglia, e non è una buona notizia travestita. Un’azienda di sicurezza ha usato analisi guidata dall’AI per individuare dodici vulnerabilità mai note prima in OpenSSL – codice che processi di sicurezza tradizionali avevano già esaminato per anni, con enorme dispendio di risorse. Le stesse tecniche che aiutano i difensori a trovarle aiutano gli attaccanti a trovarle e armarle. La finestra fra non sappiamo che esista e la stanno sfruttando si comprime drasticamente, e il nuovo standard che regolatori, clienti, consigli di amministrazione e assicuratori cominceranno a pretendere non è più “avete corretto le vulnerabilità note”, ma “cosa avete fatto per cercare continuamente quelle che non conoscevate”.

Metti questi numeri accanto al tempo medio che le aziende impiegano a rilevare una violazione – storicamente intorno ai sei mesi – e l’asimmetria si vede da sola. Non si può rispondere a sistemi autonomi a velocità umana.

Cosa cambia per chi indaga

Riprendo il filo che porto avanti da quattro articoli. Questo corso è il più ricco finora dal punto di vista investigativo, perché la quasi totalità dei suoi controlli produce – o distrugge – evidenze.

L’attribuzione si progetta prima, non si ricostruisce dopo. È il punto di partenza di tutto. Un’identità crittografica per agente non è un raffinamento architetturale: è la precondizione perché il log dica quale agente ha deciso e non soltanto quale account si è autenticato. Nel modello delegato, la catena deve conservare entrambi gli estremi – l’umano che ha delegato e l’agente che ha agito – altrimenti si ottiene un’azione senza autore o, peggio, l’azione attribuita alla persona sbagliata.

E vale la pena essere precisi su cosa intendo per identità crittografica, perché il termine circola molto e si capisce poco.

Non è una chiave API né un token statico. Quelle sono credenziali al portatore: chi ne possiede una copia è quell’identità, e il log non ha alcun modo di accorgersi della differenza. È una coppia di chiavi di cui l’agente custodisce la privata – meglio se ancorata all’hardware, in un TPM o in un modulo dedicato, così che non sia estraibile nemmeno da chi ottiene accesso alla macchina – con cui l’agente dimostra di essere sé stesso firmando, invece di esibire un segreto che viaggia e si può copiare. È il principio del certificato client con mTLS, dell’identità di carico di lavoro emessa a runtime dopo attestazione di proprietà verificabili (quale container, quale nodo, quale immagine), o dell’asserzione JWT firmata al posto del client secret.

Il passaggio che interessa a noi è però un altro: quando la firma copre la richiesta e non soltanto il canale, quella firma resta agli atti. Il log smette di asserire chi ha agito e comincia a dimostrarlo, in modo riverificabile mesi dopo – anche da un terzo, anche se il registro è custodito da qualcun altro. Per il non ripudio è tutta la differenza.

Nel modello delegato, la catena deve conservare entrambi gli estremi – l’umano che ha delegato e l’agente che ha agito – altrimenti si ottiene un’azione senza autore o, peggio, l’azione attribuita alla persona sbagliata. Lo standard per farlo esiste: il token exchange di OAuth 2.0 prevede un claim dedicato all’attore, così che il token diretto al servizio a valle porti insieme il soggetto per conto del quale si agisce e l’identità di chi sta effettivamente agendo. E il claim si annida, quindi una catena di deleghe resta leggibile per intero invece di collassare sull’ultimo anello. Due precisazioni: questa è la configurazione di destinazione, non quella che si trova: la maggior parte degli agenti oggi in produzione gira con una chiave statica in un file di ambiente, che è esattamente il fallimento di controllo additato dal corso. E l’identità crittografica risolve l’attribuzione, non l’autorizzazione: un agente manipolato per via di un’iniezione continuerà a firmare impeccabilmente ogni richiesta malevola. Saprai con certezza chi ha fatto il danno; per impedirglielo servono i confini di cui sopra.

La terminazione è un controllo di risposta agli incidenti, non una pratica amministrativa. Quando un dipendente se ne va, nessuno aspetta tre settimane per disattivargli badge e accessi. Per un agente la revoca deve coprire accessi ai sistemi, credenziali API, token, segreti, permessi sugli strumenti, accesso ai dati, autorità delegata, comunicazione verso altri agenti e capacità di esecuzione autonoma. Terminazione senza revoca non è terminazione: è licenza di continuare a operare. E poiché gli agenti agiscono a velocità macchina, l’interruttore di emergenza va provato prima, non cercato durante.

Il fascicolo personale dell’agente è l’inventario che serve all’indagine. Il corso lo chiama record HR: chi è l’agente, qual è la sua missione, chi lo gestisce, quali capacità ha, quali permessi ha ricevuto e quando, quali politiche gli sono state impartite, in quali ambienti è autorizzato a operare, quali revisioni ha superato, quando è stato dismesso. Senza, nelle parole del corso, non hai una forza lavoro AI: hai dipendenti ombra. Aggiungo l’osservazione pratica: quel fascicolo è anche la prima cosa che chiederà chiunque conduca un’indagine, interna o esterna, e compilarlo a posteriori è impossibile.

Il consumo di token è un segnale comportamentale, non solo una voce di spesa. Uber ha esaurito l’intero budget AI del 2026 in quattro mesi per via dell’adozione interna di agenti di codifica, finendo per imporre tetti di spesa. Letto come problema di fatturazione è un aneddoto; letto come telemetria è un indicatore. Il corso elenca tre schemi che vale la pena saper riconoscere: l’inflazione quadratica del contesto, con quantità crescenti di contesto ripassate di continuo nel sistema; il ping pong fra agenti che si richiamano a vicenda senza produrre progresso; e il consumo fuori dai controlli di governance stabiliti. Nessuno dei tre è un problema di costo: sono tutti indizi che un agente è progettato male o fuori controllo.

Accesso e divulgazione sono due autorizzazioni diverse. È la lezione del caso Echo Leak riletta in chiave di governance e il corso la formula meglio di come l’avevo messa io nel primo articolo: un dipendente umano autorizzato a vedere un’informazione sa distinguere fra posso accedervi e posso condividerla. Un agente no. Quella distinzione va ingegnerizzata nel sistema: la capacità di recuperare un’informazione deve essere separata dall’autorità di trasmetterla o di agirvi sopra. Altrimenti si ottiene un agente autorizzato che diventa, senza esserne consapevole, una minaccia interna.

Due cautele mie

La metafora del dipendente è potente e proprio per questo va maneggiata. Funziona benissimo per importare discipline consolidate – identità, mansionario, privilegio minimo, revisione, dismissione. Ma porta con sé intuizioni che non reggono: con una persona ci si può fidare e verificare, perché la persona ha giudizio, sa riconoscere che avere accesso a una credenziale non significa che sia opportuno usarla e può fermarsi a chiedere “davvero dovrei farlo?”. L’agente non lo fa. Lo stesso corso lo dice con chiarezza – gli umani applicano giudizio, gli agenti richiedono autorizzazione esplicita – ma il rischio che la metafora faccia scivolare qualcuno verso un’aspettativa di buon senso esiste, e tenderei a nominarlo esplicitamente quando si porta questo modello in azienda. L’intelligenza determina cosa un agente può fare, il giudizio cosa dovrebbe fare, la governance colma la distanza.

Il ciclo di vita completo è tanto processo. Tredici pratiche gestionali, dieci controlli di governance: in un’organizzazione strutturata hanno senso, in una piccola diventano un documento che nessuno applica – e torniamo alla tigre di carta. Se dovessi ridurlo all’osso terrei tre cose: un’identità per agente, un proprietario umano con nome e cognome e un interruttore che funziona. Il resto si costruisce sopra, ma senza quei tre non si costruisce niente.

Le cinque domande e lunedì mattina

Il corso chiude con cinque domande da porsi prima di mettere un agente in produzione. Se la risposta non è sì a tutte e cinque, l’agente non è pronto.

Ogni agente ha un’identità e un proprietario?
Autorità e confini dell’agente sono definiti?
L’accesso è a privilegio minimo?
Comportamento e decisioni sono monitorati in continuo?
Esistono governance, responsabilità e controlli di arresto?

E le cose da fare, in ordine di rapporto fra fatica e resa:

Conta gli agenti che agiscono sotto un’identità non loro. Service account condivisi, account umani riusati, credenziali ereditate. È la misura diretta di quanta attribuzione hai già perso.
Assegna un proprietario umano a ciascuno. Con nome e cognome, non “il team X”. La responsabilità non si delega a un agente e non si delega a una casella di posta.
Applica il test del danno massimo a ogni identità privilegiata, umana o agentica. Se la risposta ti mette a disagio, hai trovato il punto da cui partire.
Prova l’interruttore. Scegli un agente in produzione e verifica quanto ci metti davvero a revocargli tutto – accessi, token, segreti, strumenti, deleghe. Cronometra.
Stabilisci la linea di base comportamentale almeno per gli agenti che toccano dati o sistemi sensibili. Senza, non puoi accorgerti di una deriva e la deriva non ha bisogno di un attaccante per farti male.
Guarda il consumo di token come guarderesti il traffico di rete. Chi consuma, quanto, per cosa e se quel profilo somiglia a quello della settimana scorsa.

Il messaggio finale è quello con cui il corso si chiude e che vale come chiusura anche di questa serie: l’AI non è un prodotto che compri, è un dipendente agentico che gestisci. Può rappresentare l’azienda e agire per suo conto, ma solo l’azienda può rispondere di ciò che accade dopo.

E se devi scegliere una cosa sola da cui cominciare, comincia dal tesserino.

Articolo elaborato a partire dagli appunti del corso “Managing Your Agentic Employees” di AISEC University (docente: Darren Shelcusky). I casi citati sono stati verificati a ottobre 2026. La sezione investigativa, le cautele finali e i raccordi con gli articoli precedenti sono miei.

Fonti: