L'AI agentica costringe Zero Trust ad affrontare una crisi d'identità

L'AI agentica è arrivata su Google News con un'affermazione netta: i sistemi autonomi stanno capovolgendo la cybersicurezza Zero Trust. Il titolo di Breaking Defense individua un conflitto reale, anche se i dettagli sottostanti restano difficili da verificare in modo indipendente. I team di sicurezza hanno costruito i controlli di accesso attorno a persone, dispositivi e applicazioni prevedibili. Gli agenti AI ora confondono tutte e tre le categorie, pur agendo con autorità delegata.

Questo non rende Zero Trust obsoleto. Cambia ciò che le organizzazioni devono verificare, la frequenza con cui devono farlo e quale identità ha eseguito ogni azione. Un agente può interpretare un obiettivo, selezionare strumenti, leggere contenuti esterni, chiamare API e modificare dati. Il suo comportamento non è pienamente rappresentato dalle autorizzazioni assegnate al suo proprietario umano.

Il risultato è un'inversione scomoda. Zero Trust presume che ogni richiesta debba essere valutata, mentre i flussi di lavoro agentici generano lunghe catene di richieste alla velocità delle macchine. La sfida principale non è quindi l'AI agentica contro Zero Trust. È il controllo statico degli accessi contro il controllo continuo del comportamento autonomo.

L'affermazione di Google News indica un reale cambiamento nella sicurezza

Il cambiamento importante non è che l'AI possa accedere ai sistemi aziendali, ma che possa decidere cosa fare dopo aver ottenuto l'accesso.

Il software tradizionale segue percorsi definiti in anticipo dagli sviluppatori. Può contenere bug, accettare input dannosi o esporre interfacce vulnerabili. Tuttavia, i difensori possono di solito mappare le sue funzioni previste su account, processi e connessioni di rete consolidati.

L'AI agentica aggiunge un livello decisionale tra l'istruzione di un utente e l'azione risultante. Un agente può suddividere un obiettivo ampio in attività più piccole, scegliere tra gli strumenti disponibili e adattarsi quando un percorso fallisce. NIST descrive gli agenti moderni come modelli generalisti combinati con software che consente loro di manipolare strumenti oltre la generazione di testo.

Questi strumenti possono includere browser, database, calendari, interpreti di codice, file locali e interfacce amministrative. La tassonomia dell'uso degli strumenti di NIST distingue l'accesso in sola lettura dall'accesso in scrittura vincolato o senza restrizioni. Distingue inoltre gli ambienti fidati da quelli non fidati.

Questa distinzione è importante perché un singolo agente spesso attraversa diverse categorie durante un incarico. Potrebbe leggere un'email, estrarre un numero cliente, interrogare un database interno e aggiornare una pratica di assistenza. Ogni passaggio può sembrare autorizzato se esaminato separatamente.

Il flusso di lavoro combinato può comunque produrre un risultato non sicuro. Un attaccante potrebbe inserire istruzioni nascoste nell'email. L'agente potrebbe interpretare tali istruzioni come parte del proprio compito, quindi utilizzare autorizzazioni legittime per divulgare dati.

Questo attacco è chiamato indirect prompt injection, ossia istruzioni dannose raggiungono un agente attraverso i contenuti che elabora. L'attaccante non ha bisogno della password del dipendente. Prende di mira l'interpretazione dell'agente sulle informazioni fidate e non fidate.

Il titolo di Google News coglie questo cambiamento con l'espressione “capovolgendo tutto”. In precedenza, i team di sicurezza temevano che le persone usassero impropriamente il software o cedessero le proprie credenziali. Ora devono considerare anche software che interpreta l'autorità di una persona e agisce autonomamente al suo interno.

Non si tratta semplicemente di un altro endpoint che entra nella rete. Un endpoint ha normalmente una funzione, una postura e un modello di proprietà relativamente stabili. Un agente può modificare il proprio piano immediato mantenendo la stessa identità, le stesse credenziali e la stessa connessione.

Questo crea un problema di visibilità. Un registro può mostrare che un account di servizio valido ha acceduto a un database. Potrebbe non rivelare quale utente ha avviato l'attività, quale agente ha formulato il piano o quale input esterno ha influenzato la decisione.

Il titolo dovrebbe comunque essere trattato come una tesi, non come prova di una specifica violazione. Nessun dettaglio verificato su un incidente accompagna l'elemento di Google News fornito. Il problema di sicurezza più ampio, tuttavia, è supportato dalla ricerca pubblica e dal lavoro sugli standard in corso.

I team di sicurezza non proteggono più soltanto gli accessi da persona ad applicazione e da applicazione ad applicazione. Devono proteggere una catena che collega una persona, un agente, un modello, vari strumenti e molteplici fonti di dati. La fiducia può disperdersi a ogni passaggio di consegne.

Zero Trust è stato costruito per le richieste, non per obiettivi aperti

Zero Trust resta rilevante, ma la sua unità convenzionale di controllo è troppo ristretta per il lavoro autonomo.

NIST ha pubblicato la sua fondamentale architettura Zero Trust nel 2020. Il modello rifiuta la fiducia implicita basata sulla posizione in rete o sulla proprietà di un asset. L'autenticazione e l'autorizzazione avvengono prima che una sessione raggiunga una risorsa aziendale.

L'architettura si concentra sulle risorse anziché sui tradizionali segmenti di rete. Presuppone che una rete possa essere già compromessa. L'accesso dovrebbe quindi rimanere limitato al più piccolo insieme di autorizzazioni richiesto per una missione specifica.

Questo approccio contrasta il vecchio modello perimetrale. Nella sicurezza perimetrale, gli utenti autenticati ricevevano spesso un ampio accesso dopo essere entrati in una rete fidata. Gli attaccanti potevano quindi spostarsi lateralmente tra i sistemi dopo aver compromesso un account o un dispositivo.

L'AI agentica non invalida questi principi. Anzi, il privilegio minimo e la valutazione continua diventano più importanti quando le macchine possono eseguire molte azioni rapidamente. La difficoltà consiste nel tradurre un obiettivo utente ampio in autorizzazioni applicabili e di breve durata.

Si consideri un agente incaricato di preparare un rapporto trimestrale sul rischio clienti. Il compito sembra informativo, ma per completarlo potrebbero servire diverse capacità. L'agente deve individuare i record, combinare i dati, calcolare le tendenze e produrre un documento.

L'agente dovrebbe ricevere accesso a tutti i record dei clienti per l'intera durata dell'incarico? Dovrebbe conservare tali autorizzazioni in seguito? Può inviare il rapporto via email oppure la distribuzione dovrebbe richiedere un'approvazione separata?

Un sistema di accesso convenzionale può rispondere a queste domande attraverso il ruolo esistente dell'utente. Se il dipendente può leggere il database e inviare email, l'agente eredita entrambi i poteri. Questa eredità è semplice, ma crea un'autorità eccessiva.

L'agente può eseguire combinazioni di azioni che il dipendente non aveva mai previsto. Può anche ripeterle a una scala che i flussi di lavoro manuali raramente raggiungono. Un piccolo errore interpretativo può trasformarsi in centinaia di query al database o messaggi.

Gli obiettivi aperti rendono più difficile la progettazione delle policy. “Trova le prove rilevanti” non specifica quali repository debbano essere cercati. “Risolvi il problema” non definisce se l'agente possa emettere un rimborso, modificare un account o eseguire codice.

Zero Trust valuta tradizionalmente le richieste di accesso utilizzando identità, stato di salute del dispositivo, sensibilità della risorsa e contesto ambientale. I sistemi agentici aggiungono un'altra domanda: questa azione rimane coerente con il compito che ha giustificato l'accesso?

Questa domanda richiede controlli consapevoli dell'intento. Tali controlli confrontano un'azione con lo scopo assegnato all'agente, il piano corrente e la policy approvata. Non possono dipendere esclusivamente dal fatto che un account disponga tecnicamente dell'autorizzazione.

Il confine di sicurezza si sposta anche durante il lavoro multi-agente. Un agente può delegare la ricerca a un altro agente. Quest'ultimo può chiamare un servizio di terze parti, che restituisce contenuti contenenti nuove istruzioni.

Ogni passaggio di consegne può alterare il contesto mantenendo un'autorizzazione apparente. Una policy statica vede identità approvate che trasferiscono dati. Una policy comportamentale deve determinare se l'intera catena continua a servire l'obiettivo originario.

Ecco perché la sicurezza dell'AI agentica non può fermarsi alla segmentazione di rete. Il piano di controllo deve comprendere identità, attività, strumenti, provenienza dei dati e cronologia delle azioni. Deve inoltre preservare queste relazioni per le indagini successive.

La promessa originale di Zero Trust resta valida: non concedere mai fiducia soltanto perché qualcosa è già all'interno. I flussi di lavoro agentici rivelano semplicemente che “all'interno” può descrivere una finestra di contesto, un'attività delegata o una catena di strumenti. Non si riferisce più soltanto a una rete.

Gli agenti AI necessitano di identità separate dai loro proprietari

Un'organizzazione non può governare un agente autonomo se ogni azione appare sotto un account umano o di servizio condiviso.

L'identità è il primo punto di pressione per i team di sicurezza aziendale. Le persone hanno registri di assunzione, responsabili, ruoli lavorativi e procedure di uscita. Le applicazioni hanno proprietari, processi di rilascio e account di servizio.

Gli agenti combinano caratteristiche di entrambi i gruppi. Possono ricevere obiettivi dalle persone, ma eseguono tramite software. Possono operare brevemente per un'attività o continuare a funzionare come lavoratori digitali persistenti.

Trattare un agente come una funzionalità nascosta all'interno di un'applicazione oscura la responsabilità. Trattarlo come un normale dipendente crea anch'esso una falsa fiducia. L'agente necessita di un'identità macchina di prima classe collegata al suo proprietario, al suo scopo e alla sua distribuzione.

Tale identità non dovrebbe sostituire quella dell'utente che avvia l'azione. Entrambe dovrebbero persistere lungo l'intero flusso di lavoro. Gli investigatori devono sapere chi ha richiesto un'azione e quale agente l'ha eseguita.

Un utile record di audit dovrebbe inoltre acquisire il modello, lo strumento, la policy e la fonte dati coinvolti. Senza questo contesto, un registro del database mostra soltanto l'accesso finale. Non può spiegare perché l'agente riteneva appropriato tale accesso.

I team di sicurezza dovrebbero evitare credenziali condivise per le distribuzioni degli agenti. Gli account condivisi impediscono un'attribuzione affidabile e complicano la revoca. Consentono inoltre agli agenti abbandonati di rimanere attivi dopo la conclusione dei loro progetti originari.

Un'identità di agente necessita di un ciclo di vita. La creazione dovrebbe identificare un proprietario responsabile e un utilizzo approvato. Le revisioni periodiche dovrebbero confermare che l'agente resta necessario e che le sue autorizzazioni corrispondono ancora al suo scopo.

La scadenza è altrettanto importante. Gli agenti temporanei dovrebbero perdere l'accesso quando termina un'attività o un progetto. Gli agenti persistenti dovrebbero affrontare una ricertificazione regolare, proprio come gli account umani privilegiati.

Anche le autorizzazioni dovrebbero essere specifiche per attività e di breve durata. Un agente che prepara un rapporto può ricevere accesso temporaneo in lettura a record selezionati. L'invio di tale rapporto all'esterno dell'organizzazione dovrebbe richiedere un'autorizzazione separata o una conferma umana.

Questo design riduce il privilege creep, che si verifica quando le identità accumulano accessi che non corrispondono più alle loro responsabilità. Il privilege creep è già difficile da gestire con i dipendenti. Gli agenti autonomi possono moltiplicare il problema perché i team possono crearli rapidamente.

La scoperta degli agenti diventa quindi un requisito operativo. I team di sicurezza necessitano di un inventario che copra servizi SaaS, piattaforme di sviluppo, sistemi di automazione interni e integrazioni di terze parti. I soli registri di approvvigionamento non identificheranno gli agenti creati all'interno di prodotti esistenti.

La scoperta deve distinguere una funzionalità AI da un'identità agente. Una funzionalità di sintesi che legge soltanto un documento comporta rischi diversi da un agente che può cercare nelle unità e inviare messaggi. Entrambi possono usare lo stesso modello.

Anche il proprietario dovrebbe essere visibile nelle policy e nei registri. Quando un agente agisce al di fuori delle aspettative, chi risponde all'incidente ha bisogno di una persona o di un team in grado di sospenderlo. L'automazione anonima crea ritardi durante gli incidenti.

Le organizzazioni utilizzano già identità non umane per servizi, carichi di lavoro e macchine. Le identità degli agenti estendono questa disciplina anziché sostituirla. La differenza è che la policy deve tenere conto di comportamenti variabili all'interno dello stesso ruolo assegnato.

I principali fornitori di sicurezza si stanno muovendo in questa direzione. Cisco ha annunciato la scoperta degli agenti, controlli di identità agentica e l’applicazione del Model Context Protocol nel suo aggiornamento sulla sicurezza degli agenti. Il Model Context Protocol, o MCP, collega i modelli a strumenti e dati esterni.

Gli annunci dei fornitori non costituiscono prove indipendenti del fatto che i controlli funzionino in ogni implementazione. Mostrano però in quale direzione sta andando la concorrenza. Piattaforme di identità, broker di accesso e gateway di sicurezza vogliono tutti diventare il punto di controllo per il traffico degli agenti.

Gli acquirenti aziendali dovrebbero evitare di considerare un singolo gateway come una soluzione completa. NIST osserva da tempo che nessun singolo fornitore offre un’intera architettura Zero Trust. La sicurezza agentica aggiunge più componenti e più opportunità di applicazione incoerente dei controlli.

La pressione immediata ricade sui team di identity and access management. Devono supportare attori macchina creati rapidamente senza ripetere il problema degli account di servizio non gestiti. Le assegnazioni statiche dei ruoli non saranno sufficienti.

Il dirottamento degli agenti espone i limiti delle verifiche statiche dei permessi

Un agente correttamente autenticato può comunque compiere l’azione sbagliata, perché l’autenticazione non convalida il suo ragionamento.

L’argomento più forte a favore di una revisione dello Zero Trust deriva dalla ricerca sul dirottamento degli agenti. Nel marzo 2026, NIST ha riportato i risultati di una grande competizione pubblica di red teaming che ha coinvolto 13 modelli frontier. Oltre 400 partecipanti hanno effettuato più di 250.000 tentativi di attacco.

È stato individuato almeno un attacco di dirottamento riuscito contro ogni modello testato. I modelli differivano nella loro resistenza, ma le capacità non predicevano in modo coerente la sicurezza. Alcune famiglie di attacchi si sono inoltre trasferite tra modelli e scenari diversi.

Questi risultati non significano che ogni agente implementato sia facilmente compromettibile. Una competizione incentiva attaccanti focalizzati e potrebbe non riprodurre tutti i controlli di produzione. Stabilisce però che la sola resistenza a livello di modello non può fungere da confine di sicurezza.

NIST definisce il dirottamento degli agenti come un attacco che inserisce istruzioni dannose nei dati elaborati da un agente. L’obiettivo è reindirizzare l’agente verso comportamenti dannosi. I possibili esiti includono l’esfiltrazione di dati o l’esecuzione di codice malevolo.

Il dettaglio cruciale è che l’agente utilizza spesso strumenti e credenziali validi. Un firewall può rilevare una connessione approvata. Un sistema di identità può rilevare un account autenticato. Il passaggio pericoloso avviene nell’interpretazione dei contenuti da parte dell’agente.

Questo rende incomplete le allowlist statiche. Consentire a un agente di leggere le email e aggiornare un database può essere necessario per il suo lavoro. La policy deve comunque impedire che un’email ridefinisca ciò che lo strumento del database dovrebbe fare.

Le pertinenti conclusioni del red team supportano una difesa in profondità. I modelli devono essere valutati, ma le implementazioni necessitano anche di strumenti vincolati, confini dei dati, monitoraggio e punti di approvazione.

I permessi degli strumenti dovrebbero riflettere le conseguenze, non la comodità. Leggere una pagina web pubblica presenta rischi diversi dall’eseguire codice scaricato. Interrogare il record di un cliente è diverso dall’eliminarlo o esportarlo.

Gli strumenti ad alto impatto dovrebbero esporre operazioni limitate. Un agente che deve pianificare una riunione non dovrebbe ricevere il controllo illimitato della casella di posta. Un agente finanziario che prepara un pagamento non dovrebbe anche approvarlo e trasmetterlo.

Questo principio è chiamato separazione dei compiti. Impedisce a una singola identità di controllare ogni fase di un processo sensibile. I sistemi agentici necessitano della stessa divisione, anche quando l’automazione rende allettante il consolidamento.

L’approvazione umana resta utile ai confini irreversibili. Trasferimenti, eliminazioni, pubblicazione esterna, distribuzione in produzione e modifiche alle credenziali meritano verifiche esplicite. L’approvazione dovrebbe mostrare l’azione prevista e il contesto pertinente.

Un generico pulsante “consenti” offre poca protezione. Il revisore deve sapere quale agente ha richiesto l’azione, quali dati ha utilizzato e quale effetto produrrà l’approvazione. Altrimenti, l’automazione sposta semplicemente il social engineering nella schermata di approvazione.

Il monitoraggio dovrebbe concentrarsi sui cambiamenti di comportamento. Un agente che accede improvvisamente a repository non familiari può indicare un dirottamento o una pianificazione difettosa. Ripetute chiamate agli strumenti non riuscite possono segnalare che un agente sta sondando oltre il proprio ruolo.

Anche i limiti di frequenza riducono i danni causati dagli errori. L’esecuzione alla velocità delle macchine può trasformare una singola decisione errata in un incidente diffuso. Limitare il volume delle azioni offre ai sistemi di monitoraggio e agli addetti alla risposta il tempo per intervenire.

Il sandboxing rimane prezioso, ma non dovrebbe creare un’assunzione di sicurezza. Un agente può causare danni senza evadere dal proprio runtime. Inviare dati autorizzati alla destinazione sbagliata potrebbe non richiedere alcun exploit software.

L’incertezza centrale è se i sistemi consapevoli dell’intento possano prendere decisioni affidabili senza bloccare il lavoro utile. I piani degli agenti cambiano, le attività aziendali contengono ambiguità e le policy non possono anticipare ogni eccezione legittima.

Controlli eccessivamente rigidi produrranno richieste di approvazione costanti. I team potrebbero quindi concedere permessi più ampi per ripristinare la produttività. Questa risposta ricrea l’esatta fiducia implicita che Zero Trust era pensato per rimuovere.

Controlli eccessivamente permissivi producono il fallimento opposto. Gli agenti operano senza problemi finché un input malevolo o un errore di pianificazione non sfrutta la loro autorità. I team di sicurezza devono misurare sia il lavoro bloccato sia le azioni non sicure.

Questo compromesso impedisce facili affermazioni secondo cui un prodotto di “Zero Trust agentico” abbia risolto il problema. Le dimostrazioni di prodotto mostrano di solito flussi di lavoro selezionati. Le implementazioni reali includono sistemi legacy, identità condivise e log incoerenti.

L’approccio più credibile nel breve termine è stratificato. Assegnare un’identità a ciascun agente, limitare ogni strumento, preservare l’utente iniziale, convalidare le azioni conseguenti e monitorare il comportamento. Occorre presumere che le salvaguardie del modello talvolta falliscano.

La battaglia competitiva si sta spostando nel control plane

I fornitori di sicurezza competono per mediare il comportamento degli agenti, mentre le aziende non dispongono ancora di un modello comune per dimostrare che questa mediazione funziona.

L’AI agentica crea opportunità per fornitori di identità, fornitori di sicurezza di rete, piattaforme cloud e aziende specializzate nella sicurezza dell’AI. Ogni gruppo controlla una parte diversa del flusso di lavoro. Nessuno vede automaticamente l’intera catena.

I fornitori di identità sanno a chi è stato concesso l’accesso. Le piattaforme di rete osservano le connessioni tra sistemi. I provider cloud possono monitorare carichi di lavoro e chiamate API. Gli strumenti di sicurezza dell’AI ispezionano prompt, output dei modelli e richieste agli strumenti.

La posizione più preziosa è il punto di decisione delle policy. In un’architettura Zero Trust, quel componente valuta l’accesso e decide se l’applicazione dei controlli debba consentirlo. I sistemi agentici rendono questa decisione più ricca e più contesa.

Un fornitore di rete può sostenere che la comunicazione degli agenti debba passare attraverso un broker di sicurezza. Un fornitore di identità può incentrare la policy sulle identità macchina e sull’autorizzazione delegata. Un fornitore di sicurezza dell’AI può dare priorità all’ispezione dei prompt e alla valutazione comportamentale.

Tutte e tre le prospettive contengono una parte della risposta. Il contesto di rete non può rivelare ogni istruzione malevola. L’ispezione dei prompt non può da sola applicare il blocco di una query al database. La verifica dell’identità non può garantire che un agente autenticato rispetti il proprio scopo.

MCP è diventato un punto focale perché standardizza le connessioni tra modelli e strumenti. Un gateway può inventariare i server, limitare le operazioni e registrare le chiamate. Tuttavia, non tutti gli agenti usano MCP e un gateway non può governare gli strumenti che lo aggirano.

La comunicazione da agente ad agente presenta un’altra sfida. La delega può attraversare modelli, fornitori o confini organizzativi. L’agente ricevente necessita di prove sull’identità del mittente, sulla sua autorità e sull’ambito richiesto.

Un messaggio firmato può autenticare il mittente. Non dimostra che il piano del mittente sia sicuro. La policy deve separare la provenienza, che identifica da dove proviene una richiesta, dall’autorizzazione, che determina se essa debba procedere.

Il lavoro di standardizzazione sta iniziando ad affrontare queste lacune. NIST ha lanciato la sua iniziativa sugli standard per gli agenti nel febbraio 2026. La sua agenda include interoperabilità, protocolli aperti, sicurezza, identità e adozione affidabile.

Questa iniziativa è importante perché le organizzazioni necessitano di rappresentazioni comparabili dell’identità e dell’autorità degli agenti. Senza formati comuni, ogni piattaforma crea identità proprietarie e segnali di policy. I team di sicurezza faticano quindi ad applicare i controlli nei diversi ambienti.

Gli standard da soli non possono definire la tolleranza al rischio. Un ospedale, una banca, un contraente della difesa e un’agenzia di marketing attribuiranno conseguenze diverse alla stessa azione di uno strumento. L’interoperabilità fornisce infrastrutture condivise, non una policy universale.

L’inquadramento di Breaking Defense è particolarmente rilevante per gli ambienti ad alta affidabilità. I sistemi di difesa spesso combinano dati classificati, vincoli di missione, apparecchiature legacy e una rigorosa responsabilità. Un’azione autonoma può avere conseguenze che vanno oltre la normale automazione d’ufficio.

Questi ambienti creano anche pressione verso l’automazione. Gli analisti affrontano grandi volumi di avvisi, documenti e dati dei sensori. Gli agenti possono aiutare a correlare le informazioni ed eseguire passaggi ripetitivi, ma una maggiore autonomia aumenta la necessità di un controllo tracciabile.

La concorrenza dovrebbe quindi essere valutata attraverso le prove, non il vocabolario di prodotto. Gli acquirenti devono verificare se un controllo identifica gli agenti in modo affidabile, associa le azioni ai responsabili, limita gli strumenti e produce registri di audit utilizzabili.

Dovrebbero inoltre testare i casi di errore. Cosa accade quando il provider di identità non è disponibile? Un agente può ricorrere a permessi memorizzati nella cache? Un broker fallisce in modo chiuso, oppure il traffico aggira l’ispezione?

La copertura multipiattaforma conta quanto le singole funzionalità. Un’organizzazione potrebbe usare un modello cloud, l’agente di coding di un altro fornitore e diversi assistenti SaaS. Un controllo che vede un solo ambiente lascia significativi punti ciechi.

Il mercato probabilmente si consoliderà attorno a piattaforme integrate, ma l’integrazione può creare un proprio rischio di concentrazione. Un singolo control plane compromesso potrebbe colpire molti agenti. Logging ed enforcement indipendenti restano salvaguardie importanti.

Google News può amplificare i titoli sull’AI agentica che sostituisce i modelli di sicurezza familiari. La conclusione più accurata è più circoscritta. I fornitori esistenti devono estendere Zero Trust dalle decisioni di connessione alla governance di identità, intento e azione.

Cosa dovrebbero osservare i team di sicurezza

La prossima fase sarà decisa da prove misurabili di implementazione, non da affermazioni più ampie sulla sicurezza autonoma.

Il primo segnale è se i gruppi di standardizzazione produrranno specifiche utilizzabili per l’identità degli agenti e l’autorizzazione delegata. NIST ha affermato che la sua iniziativa svilupperà ricerca, linee guida e altri risultati. Le aziende dovrebbero osservare formati che funzionino tra fornitori diversi.

Una specifica di identità utile deve collegare un agente a un proprietario, uno scopo, un modello e strumenti approvati. Dovrebbe inoltre preservare l’utente iniziale durante la delega. Se le piattaforme adottano rappresentazioni incompatibili, la governance rimarrà frammentata.

Il secondo segnale è il testing di sicurezza indipendente. La competizione di NIST ha rilevato attacchi riusciti contro ogni modello frontier testato, ma le organizzazioni necessitano di valutazioni a livello di implementazione. I test dovrebbero includere modelli, strumenti, permessi, memoria e dati esterni.

I test comparativi dovrebbero misurare più del successo delle prompt injection. Dovrebbero esaminare se gli agenti superano l’ambito dell’attività, utilizzano impropriamente strumenti legittimi o nascondono azioni conseguenti all’interno di flussi di lavoro lunghi. Dovrebbero inoltre testare il ripristino e la qualità dell’audit.

Se il successo degli attacchi diminuisce mentre gli agenti mantengono capacità utili, aumenterà la fiducia nei controlli consapevoli dell’intento. Se modelli migliorati rimarranno vulnerabili nei deployment ricchi di strumenti, i controlli infrastrutturali diventeranno ancora più importanti.

Il terzo segnale è il comportamento delle imprese dopo i progetti pilota. I team di sicurezza dovrebbero monitorare quanti agenti ricevono identità univoche, credenziali limitate e responsabili definiti. Dovrebbero inoltre misurare gli agenti abbandonati e le autorizzazioni non riesaminate.

I soli numeri di adozione rivelano poco. Un’azienda può distribuire migliaia di agenti mantenendoli in sola lettura e isolati. Un singolo agente con ampio accesso alla produzione può comportare un rischio maggiore dell’intera popolazione.

I report sugli incidenti forniranno un ulteriore riscontro con la realtà. I casi pubblici dovrebbero spiegare se i fallimenti sono derivati da prompt injection, privilegi eccessivi, confusione d’identità o confini di approvazione mancanti. Senza questi dettagli, il settore non può confrontare le difese.

I responsabili della sicurezza dovrebbero porre domande dirette prima di ampliare un progetto pilota:

• Ogni agente dispone di un’identità univoca e di un responsabile accountable?

• Le autorizzazioni possono scadere automaticamente al termine dell’attività?

• I log conservano sia la persona richiedente sia l’agente che agisce?

• Quali strumenti possono creare modifiche irreversibili?

• I contenuti esterni possono influenzare tali chiamate agli strumenti?

• Quale volume di azioni attiva una revisione o una sospensione?

• I responsabili degli incidenti possono disabilitare un singolo agente senza fermare l’intera piattaforma?

• Gli agenti delegati sono vincolati dall’attività originale?

• Il sistema si blocca in modo sicuro quando i servizi di policy non sono disponibili?

• Gli auditor possono ricostruire perché si è verificata un’azione sensibile?

Queste domande trasformano l’affermazione secondo cui tutto viene “ribaltato” in un test di implementazione. Se una piattaforma non sa rispondere, il suo linguaggio Zero Trust rimane incompleto. Se invece sa farlo, l’architettura potrebbe già adattarsi.

La conclusione più importante è che le organizzazioni non dovrebbero abbandonare Zero Trust. Dovrebbero applicarlo a unità di autorità più piccole e dinamiche. Ogni agente, chiamata a uno strumento, delega e azione con conseguenze merita il proprio contesto di policy.

Questo approccio introdurrà attrito. Alcune attività automatizzate richiederanno strumenti più circoscritti o una conferma umana. Alcuni progetti pilota rallenteranno mentre i team costruiscono inventari e controlli del ciclo di vita.

L’alternativa è un’autorità nascosta. Gli agenti erediteranno ampie autorizzazioni umane, elaboreranno contenuti non affidabili e lasceranno registrazioni incomplete. I team di sicurezza scopriranno quindi i flussi di lavoro autonomi solo dopo un incidente.

L’AI agentica non ha sconfitto Zero Trust. Ha evidenziato dove molti programmi Zero Trust si sono fermati: autenticazione, accesso alla rete o postura del dispositivo. La prossima versione dovrà governare ciò che le macchine autenticate decidono di fare.

La domanda sollevata tramite Google News merita quindi di essere mantenuta, anche se il titolo esagera il ribaltamento. La vostra organizzazione può tracciare l’identità, lo scopo, le evidenze e l’autorità di un agente prima che venga eseguita la sua prossima azione?

Partite da un flusso di lavoro di produzione e ricostruite quella catena dall’inizio alla fine. Se qualsiasi passaggio di consegne diventa invisibile, consideratelo una lacuna di controllo. Questo esercizio offre più valore dell’adozione di un’altra etichetta di sicurezza, perché verifica se Zero Trust segue l’agente nel lavoro reale.