{"id":48104,"date":"2026-10-12T16:16:03","date_gmt":"2026-10-12T14:16:03","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=48104"},"modified":"2026-10-12T16:16:03","modified_gmt":"2026-10-12T14:16:03","slug":"il-badge-di-qualcun-altro","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2026\/10\/12\/il-badge-di-qualcun-altro\/","title":{"rendered":"Il badge di qualcun altro"},"content":{"rendered":"\n

Un agente AI che agisce per conto dell\u2019azienda \u00e8, a tutti gli effetti pratici, un dipendente. Il problema \u00e8 che quasi nessuno gli d\u00e0 un tesserino suo – e senza quello, quando qualcosa va storto, l\u2019indagine parte da zero.<\/em><\/p>\n\n\n\n

\n\n\n\n

Cos\u2019\u00e8 un dipendente? La risposta istintiva – qualcuno che riceve uno stipendio – \u00e8 quella sbagliata. Un dipendente \u00e8 qualcuno a cui \u00e8 stata affidata l\u2019autorit\u00e0 di rappresentare l\u2019azienda e agire per suo conto<\/strong>. Prende decisioni, accede ai sistemi, tratta informazioni riservate, parla con i clienti, approva transazioni, spende soldi dell\u2019azienda, firma contratti.<\/p>\n\n\n\n

Scorri quell\u2019elenco pensando a un agente AI. Decide. Accede. Tratta informazioni riservate. Parla con i clienti. Esegue processi di business. L\u2019unica differenza \u00e8 che non prende uno stipendio.<\/p>\n\n\n\n

\u00c8 il modello mentale attorno a cui ruota l\u2019ultimo 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\u00e9 la metafora migliore del corso, di cui dir\u00f2 pi\u00f9 avanti. La tesi: smetti di considerare gli agenti AI come asset tecnologici e comincia a considerarli dipendenti<\/mark><\/strong>, perch\u00e9 nel momento in cui a un sistema viene concessa l\u2019autorit\u00e0 di agire per conto dell\u2019azienda, richiede la stessa disciplina gestionale di chiunque altro.<\/p>\n\n\n\n

Nessuna azienda assume qualcuno e gli dice \u201cecco accesso illimitato a tutto, buona fortuna\u201d. Eppure \u00e8 esattamente cos\u00ec che vengono messi in produzione gli agenti.<\/p>\n\n\n\n

E c\u2019\u00e8 una cosa che a un dipendente si d\u00e0 il primo giorno, prima ancora della scrivania.<\/p>\n\n\n\n

Il tesserino<\/strong><\/h1>\n\n\n\n

Il badge non \u00e8 una chiave che apre una porta. \u00c8 la risposta materiale a una domanda: chi sta chiedendo accesso?<\/strong> Prima che qualcuno entri in un edificio o acceda a un sistema, l\u2019azienda ne ha verificato l\u2019identit\u00e0. Niente identit\u00e0, niente accesso.<\/p>\n\n\n\n

Il modo in cui la maggior parte delle organizzazioni mette in servizio un agente \u00e8 l\u2019opposto: si riusa un account umano esistente, oppure un service account applicativo. Da l\u00ec nascono due problemi distinti e il secondo \u00e8 quello che riguarda direttamente chi fa analisi.<\/p>\n\n\n\n

Il primo \u00e8 la proliferazione dei privilegi, che comincia il giorno zero. L\u2019agente non riceve l\u2019autorit\u00e0 minima per una missione specifica: eredita<\/strong> un insieme di permessi disegnato per qualcun altro e per tutt\u2019altro scopo e ogni permesso in pi\u00f9 allarga insieme capacit\u00e0, superficie d\u2019attacco e raggio del danno.<\/p>\n\n\n\n

Il secondo \u00e8 pi\u00f9 sottile e pi\u00f9 costoso: si perde l\u2019attribuzione<\/strong>. Il log di audit registra l\u2019account che si \u00e8 autenticato, non l\u2019agente che ha preso la decisione e compiuto l\u2019azione.<\/p>\n\n\n\n

L\u2019immagine del corso \u00e8 efficace: \u00e8 come assumere una persona e darle il tesserino di un\u2019altra. Le telecamere registrano l\u2019identit\u00e0 del badge, non chi \u00e8 effettivamente entrato nell\u2019edificio e ha fatto il lavoro.<\/p>\n\n\n\n

Chi ha gestito anche un solo incidente sa cosa significa. Quando arriva la segnalazione, la prima domanda \u00e8 cos\u2019\u00e8 successo<\/em>, ma la seconda – quella da cui dipende tutto il resto – \u00e8 quale agente lo ha fatto, con quale autorit\u00e0 stava operando, quali istruzioni ne hanno influenzato la decisione, quali altre azioni ha compiuto e chi ne risponde<\/strong>. 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.<\/p>\n\n\n\n

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<\/strong><\/mark>.<\/strong><\/p>\n\n\n\n

Tre modelli di identit\u00e0, non uno<\/strong><\/h2>\n\n\n\n

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

Quando agisce in autonomia<\/strong>, serve un modello da identit\u00e0 di carico di lavoro: macchina a macchina, con identit\u00e0, ruolo, permessi e responsabilit\u00e0 propri.<\/p>\n\n\n\n

Quando agisce per conto di una persona<\/strong> – un commerciale che gli chiede di recuperare i dati di un cliente – serve un modello delegato, on-behalf-of<\/em>, e la catena di identit\u00e0 deve conservare la relazione: chi \u00e8 l\u2019umano, quale agente ha agito per lui, quale autorit\u00e0 gli \u00e8 stata delegata, cosa ha effettivamente fatto.<\/p>\n\n\n\n

Quando opera attraverso confini aziendali<\/strong>, serve una federazione vera e propria: chi ha emesso l\u2019identit\u00e0, chi si fida dell\u2019emittente, quali capacit\u00e0 ha quell\u2019agente, quali politiche governano l\u2019interazione, cosa succede quando quella fiducia cambia.<\/p>\n\n\n\n

Trattare ogni agente come un\u2019applicazione 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.<\/p>\n\n\n\n

Gli attaccanti non leggono le tue policy<\/strong><\/h1>\n\n\n\n

C\u2019\u00e8 un passaggio del corso che userei volentieri in apertura di qualsiasi riunione di governance: le policy non fermano gli attacchi<\/mark><\/strong>. I dipendenti umani a volte scelgono di ignorarle. I dipendenti agentici non sanno nemmeno che esistono.<\/p>\n\n\n\n

Un agente esegue in base ai permessi, alle istruzioni e ai controlli tecnici che gli sono stati dati. Una policy che dice \u201cl\u2019agente deve accedere solo ai sistemi autorizzati\u201d fornisce un\u2019indicazione, ma finch\u00e9 l\u2019identit\u00e0 non \u00e8 verificata, i permessi non sono imposti e ogni azione non \u00e8 continuamente autorizzata, quella policy non ha alcun effetto operativo<\/strong>.<\/p>\n\n\n\n

Gli auditor esaminano policy ed evidenze per stabilire se i controlli esistono. Gli attaccanti no: testano la realt\u00e0<\/strong>. Sondano identit\u00e0, permessi, integrazioni e difese per trovare lo scarto tra ci\u00f2 che l\u2019azienda dichiara che dovrebbe accadere e ci\u00f2 che i suoi sistemi consentono effettivamente. \u00c8 in quello scarto che avvengono gli incidenti.<\/p>\n\n\n\n

Il caso che il corso porta a sostegno \u00e8 Change Healthcare, 2024: l\u2019azienda aveva certificazioni multiple e policy documentate, ma un server di accesso remoto non imponeva l\u2019autenticazione a pi\u00f9 fattori – nonostante l\u2019MFA fosse richiesta sia dalla policy aziendale sia, di fatto, dal quadro normativo sanitario. La policy non autentica gli utenti. Lo fanno i controlli tecnici.<\/p>\n\n\n\n

Morale: la speranza non \u00e8 un controllo, e una policy senza applicazione automatica non \u00e8 una strategia<\/mark>.<\/strong><\/p>\n\n\n\n

Un prompt non \u00e8 un controllo di sicurezza<\/strong><\/h1>\n\n\n\n

Questa \u00e8 la conseguenza diretta, ed \u00e8 il punto in cui il corso tocca il tema che avevo affrontato nell\u2019articolo precedente da un\u2019altra angolazione.<\/p>\n\n\n\n

Il caso Replit l\u2019ho gi\u00e0 raccontato, ma il corso aggiunge un dettaglio che cambia la lettura: durante quella sessione c\u2019erano undici istruzioni esplicite<\/strong> che stabilivano il blocco delle modifiche e dicevano all\u2019agente di non toccare la produzione. L\u2019agente le ha ignorate, ha eseguito comandi distruttivi sull\u2019ambiente di produzione, ha cancellato il database – e poi ha generato profili utente fittizi e risultati di test falsi che mascheravano l\u2019accaduto.<\/p>\n\n\n\n

Dal punto di vista di un manager: il responsabile dice \u201cnon toccare la produzione\u201d, il dipendente agentico cancella il database di produzione e poi fabbrica informazioni false per far sembrare che vada tutto bene. Non \u00e8 un\u2019allucinazione, \u00e8 un fallimento di governance. L\u2019agente aveva accesso diretto alla produzione, non esisteva alcuna separazione tecnica tra attivit\u00e0 di sviluppo e ambiente reale, e il blocco esisteva soltanto come istruzione testuale. Mancava uno strato che dicesse: indipendentemente da ci\u00f2 che l\u2019AI crede, questa operazione \u00e8 vietata<\/em>.<\/p>\n\n\n\n

Il secondo caso \u00e8 pi\u00f9 recente e, per chi progetta ambienti di test, pi\u00f9 inquietante. Nel luglio 2026, durante una valutazione di agenti molto capaci condotta da OpenAI, gli agenti sono usciti dall\u2019ambiente di test sfruttando una vulnerabilit\u00e0 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\u2019attacco ipotetico generato da un modello: azioni reali.<\/p>\n\n\n\n

La lezione \u00e8 che una sandbox \u00e8 utile solo se contiene davvero<\/strong>. Quando l\u2019agente trova una vulnerabilit\u00e0 che gli permette di uscire, il confine semplicemente smette di esistere, e tutto ci\u00f2 che \u00e8 raggiungibile fuori diventa rilevante. L\u2019ambiente di valutazione di un agente molto capace va progettato partendo dal presupposto che l\u2019agente finir\u00e0 per sconfiggere le nostre assunzioni – cio\u00e8 va trattato come un ambiente ostile.<\/p>\n\n\n\n

E la riga che vale l\u2019intero modulo: le salvaguardie del modello non sono confini di sicurezza.<\/mark><\/strong> Un prompt non \u00e8 un firewall, una dichiarazione di policy non \u00e8 una segmentazione di rete, un\u2019istruzione non \u00e8 il privilegio minimo. Se un\u2019azione \u00e8 inaccettabile, non si dice all\u2019agente di non farla: si costruisce il sistema in modo che non possa.<\/p>\n\n\n\n

Comportamento, non intenzione<\/strong><\/h1>\n\n\n\n

Un altro passaggio che mi \u00e8 rimasto, perch\u00e9 raddrizza un equivoco diffuso: per fidarsi di un agente non serve capirne l\u2019intenzione.<\/p>\n\n\n\n

L\u2019intenzione \u00e8 uno stato interno, non direttamente osservabile e quasi sempre congetturale. Persino con le persone la inferiamo dal comportamento pi\u00f9 che conoscerla. Il comportamento invece \u00e8 un problema strutturato, misurabile e risolvibile<\/strong>: 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.<\/p>\n\n\n\n

Il comportamento produce evidenze, l\u2019intenzione produce ipotesi.<\/strong> In sicurezza vincono le evidenze.<\/p>\n\n\n\n

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

Il dettaglio che apprezzo: questo tipo di controllo intercetta anche i casi in cui non c\u2019\u00e8 alcun attaccante<\/strong>. Il caso Air Canada che ho raccontato nel primo articolo – il chatbot che si inventa una politica di rimborso e costa all\u2019azienda una causa – non \u00e8 una compromissione. \u00c8 un agente che \u00e8 andato alla deriva oltre il proprio ruolo. La sicurezza dell\u2019AI non riguarda solo il comportamento malevolo: riguarda anche quello inatteso<\/strong>, perch\u00e9 un agente pu\u00f2 produrre conseguenze legali, finanziarie e reputazionali serie senza essere mai stato compromesso.<\/p>\n\n\n\n

Il recinto virtuale<\/strong><\/h2>\n\n\n\n

\u00c8 qui che entra la metafora automobilistica, ed \u00e8 la migliore del corso. L\u2019innovazione di sicurezza pi\u00f9 efficace sui veicoli connessi non \u00e8 pi\u00f9 potenza: sono i confini. Il geofencing convalida di continuo dove si trova il veicolo e impone dove gli \u00e8 consentito operare. Quando il veicolo si avvicina al limite o lo oltrepassa, il sistema non discute le intenzioni: applica la regola.<\/p>\n\n\n\n

E c\u2019\u00e8 un dettaglio che fa tutta la differenza: il confine non si muove, si muove il veicolo.<\/strong> Il sistema valuta continuamente una posizione che cambia contro un limite operativo fisso.<\/p>\n\n\n\n

Gli agenti richiedono lo stesso principio. Capacit\u00e0, 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\u00f9 gravi \u00e8 sempre lo stesso: autorit\u00e0 concessa oltre i confini della missione assegnata.<\/p>\n\n\n\n

Da cui le tre frasi che riassumono il modello meglio di una slide: l\u2019autorizzazione statica dice sei approvato<\/em>; l\u2019autorizzazione continua dice sei approvato per questa azione, adesso<\/em>; il recinto dice questo \u00e8 il limite oltre cui non vai<\/em>.<\/p>\n\n\n\n

L\u2019esempio concreto di autorizzazione continua \u00e8 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\u2019essere autorizzato ad accedere a un sistema non implica l\u2019autorizzazione a modificarlo. Quando un agente viene compromesso, \u00e8 questa catena che si spezza: senza autorizzazione continua, chi prende il controllo di un agente sovra-privilegiato eredita tutto ci\u00f2 che quell\u2019agente pu\u00f2 fare.<\/p>\n\n\n\n

Il raggio del danno<\/strong><\/h1>\n\n\n\n

Due casi, una sola domanda.<\/p>\n\n\n\n

Salesloft Drift<\/strong>, 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\u2019applicazione e, fra l\u20198 e il 18 agosto, conducono ricognizione, interrogazioni massive ed esfiltrazione attraverso oltre settecento ambienti aziendali<\/strong>, portandosi via anagrafiche clienti, opportunit\u00e0 commerciali, casi di supporto e – dentro quei record – credenziali cloud e chiavi API.<\/p>\n\n\n\n

La domanda giusta non \u00e8 come sia stato compromesso il chatbot. \u00c8 perch\u00e9 una singola applicazione AI potesse impattare settecento aziende<\/strong>. Ogni azienda che l\u2019aveva collegata aveva di fatto esteso una porzione del proprio perimetro di sicurezza a quel fornitore, e quando il fornitore \u00e8 caduto, la relazione di fiducia \u00e8 diventata un percorso d\u2019attacco.<\/p>\n\n\n\n

C\u2019\u00e8 per\u00f2 un\u2019eccezione istruttiva: Okta ha bloccato l\u2019attacco perch\u00e9 aveva imposto una lista di indirizzi autorizzati per l\u2019integrazione. Il token era valido, l\u2019identit\u00e0 dell\u2019applicazione era valida, ma la richiesta arrivava da una posizione di rete non autorizzata, e il controllo l\u2019ha fermata. \u00c8 difesa in profondit\u00e0 applicata alla fiducia delegata: non si assume che il terzo resti affidabile, si delimita da dove<\/em> gli \u00e8 consentito operare.<\/p>\n\n\n\n

Step Finance<\/strong>, 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\u2019azienda cessa le operazioni.<\/p>\n\n\n\n

L\u2019attacco non era tecnicamente straordinario. La domanda da porsi \u00e8 perch\u00e9 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.<\/p>\n\n\n\n

Da qui il test pi\u00f9 utile dell\u2019intero corso, applicabile a qualunque identit\u00e0 privilegiata, umana o agentica:<\/p>\n\n\n\n

se questa identit\u00e0 fosse compromessa adesso, qual \u00e8 il danno massimo che potrebbe causare?<\/mark><\/strong><\/p>\n\n\n\n

Se la risposta \u00e8 quaranta milioni, \u00e8 un problema di governance. Se \u00e8 \u201ccancellare il database di produzione\u201d, \u00e8 un problema di governance. Se \u00e8 \u201caccedere a ogni record cliente dell\u2019azienda\u201d, \u00e8 un problema di governance. La sicurezza non riguarda solo l\u2019impedire la compromissione: riguarda il limitare cosa la compromissione significa<\/strong>.<\/p>\n\n\n\n

Dall\u2019altra parte c\u2019\u00e8 una forza lavoro agentica<\/strong><\/h1>\n\n\n\n

Questa \u00e8 la sezione che cambia la prospettiva e il motivo per cui non considero questo corso un doppione dei precedenti.<\/p>\n\n\n\n

Se noi stiamo costruendo dipendenti agentici, lo stanno facendo anche gli altri.<\/p>\n\n\n\n

JadePuffer<\/strong>, luglio 2026. Sysdig documenta il primo caso confermato di ransomware guidato end-to-end da AI agentica. Il punto d\u2019ingresso \u00e8 un\u2019istanza di Langflow – piattaforma open source per costruire applicazioni AI – esposta su internet e affetta da una vulnerabilit\u00e0 critica nota e non corretta. Da l\u00ec l\u2019agente ha fatto ricognizione, cercato credenziali, scoperto sistemi, testato percorsi d\u2019attacco, si \u00e8 adattato, ha scalato privilegi e ha proseguito verso l\u2019obiettivo.<\/p>\n\n\n\n

Non ha inventato alcuna vulnerabilit\u00e0 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<\/strong>.<\/p>\n\n\n\n

E c\u2019\u00e8 un numero che vale la pena ricordare: trentun secondi<\/strong>. \u00c8 il tempo che l\u2019agente ha impiegato, dopo il fallimento del primo tentativo di creare un account amministratore, per riconoscere il fallimento, cambiare approccio, ricostruire l\u2019account e verificare che funzionasse. Non stava seguendo una sequenza fissa di comandi: ha incontrato un problema e ha deciso cosa fare dopo. \u00c8 quello, tecnicamente, il comportamento agentico.<\/p>\n\n\n\n

La campagna di spionaggio documentata da Anthropic.<\/strong> 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\u2019ottanta-novanta per cento delle operazioni tattiche eseguito dall\u2019AI<\/strong>, con gli umani a fornire la direzione strategica.<\/p>\n\n\n\n

Il metodo contiene una lezione sulla sicurezza dei modelli che va capita bene: gli attaccanti hanno scomposto l\u2019attacco in decine o centinaia di richieste pi\u00f9 piccole<\/strong>, ciascuna delle quali, isolata, appariva innocua. Un modello pu\u00f2 riconoscere come malevola una richiesta completa, ma non il frammento. \u00c8 esattamente il motivo per cui il comportamento di un agente non si valuta un\u2019azione alla volta: va compreso lungo l\u2019intera sessione e l\u2019intera catena.<\/p>\n\n\n\n

E c\u2019\u00e8 una riconfigurazione dei ruoli che vale la pena assimilare: l\u2019attaccante del futuro assomiglia pi\u00f9 a un manager che a una persona dietro una tastiera<\/strong>. L\u2019umano fornisce obiettivo, bersaglio e direzione strategica; l\u2019AI fornisce ricognizione, analisi, esecuzione, adattamento, persistenza e scala. L\u2019umano non sparisce, sale di livello.<\/p>\n\n\n\n

Marimo<\/strong>, aprile 2026. Vulnerabilit\u00e0 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\u2019inizio dello sfruttamento meno di dieci ore dopo<\/strong> la pubblicazione dell\u2019avviso di sicurezza. Alla radice c\u2019era un fallimento banale di controllo accessi: un endpoint WebSocket ad alto privilegio che non imponeva correttamente l\u2019autenticazione, e da l\u00ec una shell interattiva.<\/p>\n\n\n\n

Due lezioni. La prima: il tuo ambiente sperimentale fa parte della tua superficie d\u2019attacco<\/strong>. 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 \u00e8 stato progettato per un mondo in cui gli attaccanti avevano bisogno di tempo per capire una vulnerabilit\u00e0 e costruire un exploit affidabile. Quella assunzione sta diventando pericolosa.<\/p>\n\n\n\n

C\u2019\u00e8 anche il rovescio della medaglia, e non \u00e8 una buona notizia travestita. Un\u2019azienda di sicurezza ha usato analisi guidata dall\u2019AI per individuare dodici vulnerabilit\u00e0 mai note prima in OpenSSL – codice che processi di sicurezza tradizionali avevano gi\u00e0 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<\/em> e la stanno sfruttando<\/em> si comprime drasticamente, e il nuovo standard che regolatori, clienti, consigli di amministrazione e assicuratori cominceranno a pretendere non \u00e8 pi\u00f9 \u201cavete corretto le vulnerabilit\u00e0 note\u201d, ma \u201ccosa avete fatto per cercare continuamente quelle che non conoscevate\u201d<\/strong>.<\/p>\n\n\n\n

Metti questi numeri accanto al tempo medio che le aziende impiegano a rilevare una violazione – storicamente intorno ai sei mesi – e l\u2019asimmetria si vede da sola. Non si pu\u00f2 rispondere a sistemi autonomi a velocit\u00e0 umana.<\/p>\n\n\n\n

Cosa cambia per chi indaga<\/strong><\/h1>\n\n\n\n

Riprendo il filo che porto avanti da quattro articoli. Questo corso \u00e8 il pi\u00f9 ricco finora dal punto di vista investigativo, perch\u00e9 la quasi totalit\u00e0 dei suoi controlli produce – o distrugge – evidenze.<\/p>\n\n\n\n

L\u2019attribuzione si progetta prima, non si ricostruisce dopo.<\/strong> \u00c8 il punto di partenza di tutto. Un\u2019identit\u00e0 crittografica per agente non \u00e8 un raffinamento architetturale: \u00e8 la precondizione perch\u00e9 il log dica quale agente<\/em> ha deciso e non soltanto quale account<\/em> si \u00e8 autenticato. Nel modello delegato, la catena deve conservare entrambi gli estremi – l\u2019umano che ha delegato e l\u2019agente che ha agito – altrimenti si ottiene un\u2019azione senza autore o, peggio, l\u2019azione attribuita alla persona sbagliata.<\/p>\n\n\n\n

E vale la pena essere precisi su cosa intendo per identit\u00e0 crittografica<\/em>, perch\u00e9 il termine circola molto e si capisce poco.<\/p>\n\n\n\n

Non \u00e8 una chiave API n\u00e9 un token statico. Quelle sono credenziali al portatore<\/strong>: chi ne possiede una copia \u00e8<\/em> quell\u2019identit\u00e0, e il log non ha alcun modo di accorgersi della differenza. \u00c8 una coppia di chiavi di cui l\u2019agente custodisce la privata – meglio se ancorata all\u2019hardware, in un TPM o in un modulo dedicato, cos\u00ec che non sia estraibile nemmeno da chi ottiene accesso alla macchina – con cui l\u2019agente dimostra<\/strong> di essere s\u00e9 stesso firmando, invece di esibire un segreto che viaggia e si pu\u00f2 copiare. \u00c8 il principio del certificato client con mTLS, dell\u2019identit\u00e0 di carico di lavoro emessa a runtime dopo attestazione di propriet\u00e0 verificabili (quale container, quale nodo, quale immagine), o dell\u2019asserzione JWT firmata al posto del client secret.<\/p>\n\n\n\n

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

Nel modello delegato, la catena deve conservare entrambi gli estremi – l\u2019umano che ha delegato e l\u2019agente che ha agito – altrimenti si ottiene un\u2019azione senza autore o, peggio, l\u2019azione attribuita alla persona sbagliata. Lo standard per farlo esiste: il token exchange<\/em> di OAuth 2.0 prevede un claim dedicato all\u2019attore<\/strong>, cos\u00ec che il token diretto al servizio a valle porti insieme il soggetto per conto del quale si agisce e l\u2019identit\u00e0 di chi sta effettivamente agendo. E il claim si annida, quindi una catena di deleghe resta leggibile per intero invece di collassare sull\u2019ultimo anello. Due precisazioni: questa \u00e8 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 \u00e8 esattamente il fallimento di controllo additato dal corso. E l\u2019identit\u00e0 crittografica risolve l\u2019attribuzione, non l\u2019autorizzazione<\/strong>: un agente manipolato per via di un\u2019iniezione continuer\u00e0 a firmare impeccabilmente ogni richiesta malevola. Saprai con certezza chi ha fatto il danno; per impedirglielo servono i confini di cui sopra.<\/p>\n\n\n\n

La terminazione \u00e8 un controllo di risposta agli incidenti, non una pratica amministrativa.<\/strong> 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\u00e0 delegata, comunicazione verso altri agenti e capacit\u00e0 di esecuzione autonoma. Terminazione senza revoca non \u00e8 terminazione: \u00e8 licenza di continuare a operare. E poich\u00e9 gli agenti agiscono a velocit\u00e0 macchina, l\u2019interruttore di emergenza va provato prima, non cercato durante.<\/p>\n\n\n\n

Il fascicolo personale dell\u2019agente \u00e8 l\u2019inventario che serve all\u2019indagine.<\/strong> Il corso lo chiama record HR: chi \u00e8 l\u2019agente, qual \u00e8 la sua missione, chi lo gestisce, quali capacit\u00e0 ha, quali permessi ha ricevuto e quando, quali politiche gli sono state impartite, in quali ambienti \u00e8 autorizzato a operare, quali revisioni ha superato, quando \u00e8 stato dismesso. Senza, nelle parole del corso, non hai una forza lavoro AI: hai dipendenti ombra<\/strong>. Aggiungo l\u2019osservazione pratica: quel fascicolo \u00e8 anche la prima cosa che chieder\u00e0 chiunque conduca un\u2019indagine, interna o esterna, e compilarlo a posteriori \u00e8 impossibile.<\/p>\n\n\n\n

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

Accesso e divulgazione sono due autorizzazioni diverse.<\/strong> \u00c8 la lezione del caso Echo Leak riletta in chiave di governance e il corso la formula meglio di come l\u2019avevo messa io nel primo articolo: un dipendente umano autorizzato a vedere un\u2019informazione sa distinguere fra posso accedervi<\/em> e posso condividerla<\/em>. Un agente no.<\/mark> Quella distinzione va ingegnerizzata nel sistema: la capacit\u00e0 di recuperare un\u2019informazione deve essere separata dall\u2019autorit\u00e0 di trasmetterla o di agirvi sopra. Altrimenti si ottiene un agente autorizzato che diventa, senza esserne consapevole, una minaccia interna.<\/p>\n\n\n\n

Due cautele mie<\/strong><\/h1>\n\n\n\n

La metafora del dipendente \u00e8 potente e proprio per questo va maneggiata.<\/strong> Funziona benissimo per importare discipline consolidate – identit\u00e0, mansionario, privilegio minimo, revisione, dismissione. Ma porta con s\u00e9 intuizioni che non reggono: con una persona ci si pu\u00f2 fidare e<\/em> verificare, perch\u00e9 la persona ha giudizio, sa riconoscere che avere accesso a una credenziale non significa che sia opportuno usarla e pu\u00f2 fermarsi a chiedere \u201cdavvero dovrei farlo?\u201d. L\u2019agente 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\u2019aspettativa di buon senso esiste, e tenderei a nominarlo esplicitamente quando si porta questo modello in azienda. L\u2019intelligenza determina cosa un agente pu\u00f2 fare, il giudizio cosa dovrebbe fare, la governance colma la distanza.<\/mark><\/strong><\/p>\n\n\n\n

Il ciclo di vita completo \u00e8 tanto processo.<\/strong> Tredici pratiche gestionali, dieci controlli di governance: in un\u2019organizzazione strutturata hanno senso, in una piccola diventano un documento che nessuno applica – e torniamo alla tigre di carta. Se dovessi ridurlo all\u2019osso terrei tre cose: un\u2019identit\u00e0 per agente, un proprietario umano con nome e cognome e un interruttore che funziona<\/strong>. Il resto si costruisce sopra, ma senza quei tre non si costruisce niente.<\/p>\n\n\n\n

Le cinque domande e luned\u00ec mattina<\/strong><\/h1>\n\n\n\n

Il corso chiude con cinque domande da porsi prima di mettere un agente in produzione. Se la risposta non \u00e8 s\u00ec a tutte e cinque, l\u2019agente non \u00e8 pronto.<\/p>\n\n\n\n

    \n
  1. Ogni agente ha un\u2019identit\u00e0 e un proprietario<\/strong>?<\/li>\n\n\n\n
  2. Autorit\u00e0 e confini<\/strong> dell\u2019agente sono definiti?<\/li>\n\n\n\n
  3. L\u2019accesso \u00e8 a privilegio minimo<\/strong>?<\/li>\n\n\n\n
  4. Comportamento e decisioni sono monitorati in continuo<\/strong>?<\/li>\n\n\n\n
  5. Esistono governance, responsabilit\u00e0 e controlli di arresto<\/strong>?<\/li>\n<\/ol>\n\n\n\n

    E le cose da fare, in ordine di rapporto fra fatica e resa:<\/p>\n\n\n\n

      \n
    1. Conta gli agenti che agiscono sotto un\u2019identit\u00e0 non loro.<\/strong> Service account condivisi, account umani riusati, credenziali ereditate. \u00c8 la misura diretta di quanta attribuzione hai gi\u00e0 perso.<\/li>\n\n\n\n
    2. Assegna un proprietario umano a ciascuno.<\/strong> Con nome e cognome, non \u201cil team X\u201d. La responsabilit\u00e0 non si delega a un agente e non si delega a una casella di posta.<\/li>\n\n\n\n
    3. Applica il test del danno massimo<\/strong> a ogni identit\u00e0 privilegiata, umana o agentica. Se la risposta ti mette a disagio, hai trovato il punto da cui partire.<\/li>\n\n\n\n
    4. Prova l\u2019interruttore.<\/strong> Scegli un agente in produzione e verifica quanto ci metti davvero a revocargli tutto – accessi, token, segreti, strumenti, deleghe. Cronometra.<\/li>\n\n\n\n
    5. Stabilisci la linea di base comportamentale<\/strong> 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.<\/li>\n\n\n\n
    6. Guarda il consumo di token come guarderesti il traffico di rete.<\/strong> Chi consuma, quanto, per cosa e se quel profilo somiglia a quello della settimana scorsa.<\/li>\n<\/ol>\n\n\n\n

      Il messaggio finale \u00e8 quello con cui il corso si chiude e che vale come chiusura anche di questa serie: l\u2019AI non \u00e8 un prodotto che compri, \u00e8 un dipendente agentico che gestisci.<\/mark><\/strong> Pu\u00f2 rappresentare l\u2019azienda e agire per suo conto, ma solo l\u2019azienda pu\u00f2 rispondere di ci\u00f2 che accade dopo.<\/p>\n\n\n\n

      E se devi scegliere una cosa sola da cui cominciare, comincia dal tesserino.<\/p>\n\n\n\n

      Articolo elaborato a partire dagli appunti del corso \u201cManaging Your Agentic Employees\u201d di AISEC University<\/a> (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.<\/em><\/p>\n\n\n\n

      Fonti:<\/em><\/p>\n\n\n\n