L'avvertimento Zero Trust di Vishal Sharma: gli agenti AI necessitano di prove di controllo

Vishal Sharma mette in discussione una promessa di sicurezza ormai familiare: dire agli agenti AI di seguire delle regole non dimostra che tali regole siano state effettivamente rispettate. L'avvertimento zero trust di Vishal Sharma riguarda gli agenti AI, sistemi che utilizzano modelli e strumenti software per agire verso un obiettivo. Il ricercatore della Queen’s University Belfast chiede quali prove rimangano quando un agente sostiene di aver eliminato informazioni, rispettato una restrizione o completato un'attività autorizzata.

L'argomentazione spinge acquirenti aziendali e sviluppatori a distinguere tra cooperazione e controllo applicabile. Un agente che segnala il successo ha fornito una risposta. Un sistema che registra autonomamente l'operazione pertinente ha fornito qualcosa che gli acquirenti possono esaminare. Questi risultati meritano livelli di fiducia diversi.

Il riferimento storico è l'architettura zero trust del NIST, un approccio alla sicurezza che rifiuta la fiducia automatica basata sulla posizione nella rete o sulla proprietà. La sfida di Sharma riguarda il modo in cui tale principio resiste quando gli agenti interpretano informazioni, delegano il lavoro e trasferiscono il contesto tra attività. Il compromesso centrale è concreto: un'autonomia utile richiede accesso, mentre un'autonomia responsabile richiede confini che restino efficaci quando il modello commette un errore.

L'avvertimento Zero Trust di Vishal Sharma parte dall'assenza di prove

La sua analisi sulla sicurezza degli agenti, sponsorizzata dall'università e pubblicata da IEEE Spectrum, mette in discussione il modo in cui le organizzazioni verificano il comportamento degli agenti. La sponsorizzazione è rilevante: i lettori dovrebbero considerarla un contributo istituzionale al dibattito, piuttosto che una convalida indipendente di un sistema di sicurezza commerciale.

L'articolo descrive agenti che operano sotto un orchestratore, software che coordina le loro attività. Solleva la possibilità che prompt successivi recuperino informazioni che a un agente era stato precedentemente ordinato di dimenticare. Riferisce inoltre di un esperimento interno della Queen’s University Belfast in cui attacchi di de-autenticazione orchestrati da agenti hanno richiesto da due a tre secondi. Gli attacchi di de-autenticazione interrompono la connessione wireless autenticata di un dispositivo.

Il contributo più importante dell'articolo è la richiesta di prove, mentre le sue affermazioni sperimentali richiedono maggiori dettagli prima di poter sostenere conclusioni generali.

Il resoconto pubblicato non fornisce una metodologia sufficiente per stabilire un benchmark generale sulla velocità degli attacchi. Anche la discussione sul recupero del contesto non dimostra che siano state ricostruite informazioni fisicamente cancellate. Informazioni che restano accessibili da qualche parte in un flusso di lavoro pongono un problema diverso rispetto al recupero di dati che non esistono più.

Questa distinzione dovrebbe orientare la risposta. Un'affermazione sul dimenticare richiede un oggetto definito: un messaggio, un record archiviato, un documento accessibile o il comportamento appreso da un modello. Senza tale definizione, le organizzazioni non possono concordare su come dovrebbe apparire un'eliminazione riuscita.

Consideriamo un ipotetico assistente per la profilazione dei clienti. Un utente ritira il consenso all'utilizzo di una precedente intervista. L'assistente conferma che ignorerà l'intervista, poi produce una raccomandazione simile alla sua valutazione precedente. Questa somiglianza da sola non può stabilire se l'assistente abbia recuperato l'intervista, conservato un riepilogo o raggiunto indipendentemente la stessa conclusione.

Un'indagine dovrebbe esaminare ciò che il sistema ha effettivamente conservato e consultato. La spiegazione generata potrebbe offrire un indizio, ma la spiegazione stessa non risolverebbe la questione. Il comportamento contestato riguarda i meccanismi che circondano la risposta, compresi i record rimasti disponibili.

Per gli acquirenti, questo cambia le prove che vale la pena richiedere. Una dimostrazione curata può mostrare che un assistente risponde correttamente durante una sessione preparata. Un test di fallimento controllato può rivelare se una restrizione resiste a una richiesta inattesa. Queste dimostrazioni rispondono a domande di approvvigionamento diverse.

Il valore informativo risiede in questo cambiamento di enfasi. Sharma dirige l'attenzione verso il punto in cui una promessa verbale diventa un'affermazione operativa. Quando un agente gestisce informazioni sensibili o azioni rilevanti, quel punto merita un esame esplicito.

Ciò crea anche uno standard più equo per i fornitori. Un fornitore non dovrebbe dover promettere che il suo modello non produrrà mai una risposta indesiderabile. Dovrebbe poter spiegare i limiti della sua implementazione e fornire prove appropriate a tali limiti.

Lo Zero Trust si applica ancora, ma l'identità non può stabilire l'intento

L'architettura zero trust del NIST, pubblicata nell'agosto 2020, concentra la protezione sulle risorse invece di presumere l'esistenza di una rete interna affidabile. Il suo impianto distingue l'autenticazione, che stabilisce l'identità, dall'autorizzazione, che determina l'accesso consentito.

Questo framework non diventa obsoleto perché il software può interpretare il linguaggio naturale. Offre un utile punto di partenza: la collocazione di un agente all'interno di un'organizzazione non giustifica automaticamente l'accesso alle sue risorse.

Il problema analitico è quanta autorità un agente autenticato dovrebbe ricevere per l'attività attualmente in corso.

Immaginiamo un assistente autorizzato a preparare un confronto tra fornitori. Leggere proposte approvate rientra in tale incarico. Inviare a un fornitore un documento riservato di negoziazione solleva una questione distinta, anche se lo stesso assistente possiede la capacità tecnica di inviare email.

Un'autenticazione riuscita stabilirebbe quale account ha tentato l'invio. Non stabilirebbe, di per sé, che l'utente intendesse quella particolare divulgazione. La discussione sulla sicurezza deve quindi esaminare l'azione richiesta e l'autorità che la supporta.

È qui che le implementazioni degli agenti complicano le familiari decisioni aziendali. Un'istruzione umana può descrivere un risultato senza elencare ogni operazione intermedia. “Prepara il confronto” lascia spazio all'interpretazione. L'organizzazione deve comunque decidere quali operazioni tale interpretazione possa autorizzare.

Ne segue una ragionevole domanda di approvvigionamento: cosa accade quando l'assistente sceglie un passaggio non necessario? La risposta dovrebbe identificare il componente responsabile dell'autorizzazione o del rifiuto dell'operazione. Una promessa che l'assistente scelga solitamente passaggi sensati riguarda il comportamento, mentre l'acquirente sta chiedendo dell'autorità.

Lo stesso ragionamento si applica alla delega. Supponiamo che un assistente coordinatore chieda a un altro agente di ricercare la storia di un fornitore. Questa richiesta comporta il permesso di esaminare contratti riservati? Consente un'ulteriore delega? Quale restrizione originaria resta visibile al servizio ricevente?

Sono domande ipotetiche di progettazione, non risultati che dimostrano che ogni piattaforma di agenti gestisca la delega in modo errato. Il loro scopo è rendere esplicite le assunzioni prima che gli acquirenti concedano un accesso ampio. Un'implementazione può apparire ordinata pur lasciando il proprio modello di autorità definito in modo insufficiente.

I team di sicurezza si trovano quindi davanti a un problema di perimetro. Valutare un agente come una singola applicazione potrebbe ignorare differenze significative tra leggere, modificare, inviare ed eliminare. Valutare manualmente ogni operazione innocua creerebbe un onere diverso. La valutazione utile si colloca tra questi estremi.

I team di prodotto dovrebbero quindi aspettarsi domande sul rapporto tra l'intento dell'attività e l'autorizzazione eseguibile. Un cliente che richiede tale rapporto sta chiedendo una proprietà del sistema, non semplicemente un'altra istruzione per il modello.

L'avvertimento zero trust di Vishal Sharma è più utile se letto attraverso questa lente. Sfida le organizzazioni a rendere verificabili le proprie assunzioni senza sostenere che tutti i principi esistenti di controllo degli accessi abbiano fallito.

La memoria rende il compromesso più difficile da ignorare

Le linee guida di OWASP sulla sicurezza degli agenti AI trattano l'isolamento della memoria, la scadenza, la gestione dei dati sensibili e l'autorizzazione al di fuori del contesto di un agente. Per contesto si intendono le informazioni fornite al modello mentre genera una risposta.

Le linee guida identificano inoltre l'avvelenamento della memoria, ovvero la persistenza di informazioni dannose che influenzano comportamenti successivi. Questa preoccupazione collega le informazioni conservate alle azioni future, invece di trattare ogni risposta come un evento isolato.

Per gli acquirenti aziendali, il compromesso irrisolto riguarda quanta cronologia utile un assistente dovrebbe conservare e sotto quale autorità continuativa.

Consideriamo un ipotetico flusso di lavoro di ricerca che trasforma interviste in un brief di progetto. Le note storiche aiutano l'assistente a evitare di ripetere domande e a preservare le decisioni. Questi benefici costituiscono una ragione legittima per conservare informazioni. Rendono però anche più complesso valutare le richieste di ritiro.

Supponiamo che un partecipante a un'intervista richieda la rimozione di una dichiarazione sensibile. L'acquirente deve sapere quale promessa offre il prodotto. Rimuovere la trascrizione originale, escluderla dalle ricerche future e rivedere un brief derivato sono risultati distinguibili.

Un contratto significativo specificherebbe il risultato applicabile. Una dimostrazione metterebbe quindi direttamente alla prova quel risultato. Chiedere all'assistente se ricorda la dichiarazione fornirebbe prove più deboli, perché la domanda fa affidamento sulla stessa interfaccia il cui comportamento è contestato.

Questa distinzione è importante anche per il normale lavoro basato sulla conoscenza. Chi sceglie una base di conoscenza personale deve comprendere il rapporto tra raccolta, recupero e rimozione. La comodità non risponde a queste domande, e una categoria di prodotto non costituisce una garanzia di sicurezza.

Esiste inoltre una tensione tra indagine e minimizzazione. Un'organizzazione potrebbe volere una cronologia sufficiente per spiegare una raccomandazione rilevante. Al contempo, potrebbe voler evitare di conservare informazioni personali non necessarie. Nessuno dei due obiettivi scompare perché il lavoro viene svolto da un assistente.

Un'indagine ipotetica illustra la difficoltà. Un cliente contesta una raccomandazione dopo che l'intervista sottostante è stata rimossa. Gli investigatori hanno bisogno di un resoconto delle prove autorizzate che hanno informato la decisione. Conservare per sempre ogni record grezzo comprometterebbe la promessa di rimozione; non conservare nulla frustrerebbe l'indagine.

L'implicazione editoriale è che “memoria” merita un linguaggio di prodotto più preciso. Gli acquirenti dovrebbero aspettarsi descrizioni dei record coinvolti e delle garanzie associate a ciascuno. Un singolo interruttore etichettato “dimentica” lascia troppo spazio a aspettative incompatibili.

La pressione commerciale ricade sui fornitori che vendono continuità tra progetti. Più tale continuità diventa utile, più i suoi confini diventano importanti per un cliente che valuta un lavoro sensibile. Il valore di una funzionalità di memoria e i suoi requisiti di governance crescono insieme.

La domanda di Sharma va quindi oltre uno scenario di attacco insolito. Espone una questione fondamentale di acquisto: se un'organizzazione possa verificare la gestione delle informazioni dopo che la conversazione è andata avanti.

La ricerca sui browser mostra perché l'architettura cambia la posta in gioco

I ricercatori dell'Università di Washington Franziska Roesner e David Kohlbrenner hanno esaminato i confini di origine dei browser in sette browser agentici. Il loro lavoro riguarda la same-origin policy, una regola del browser che separa siti web reciprocamente non affidabili.

Il loro resoconto dell’aprile 2026 descrive esperimenti condotti tra la fine di gennaio e l’inizio di febbraio. Riferisce una dimostrazione di attacco cross-origin che coinvolge ChatGPT Atlas in Agent Mode. Per diversi altri prodotti, identifica le precondizioni dell’attacco anziché attacchi completati equivalenti.

Lo scenario dipende da condizioni specifiche, tra cui il successo di una prompt injection, un tentativo di indurre un agente a trattare contenuti non attendibili come istruzioni. Le versioni e le configurazioni testate sono rilevanti. Questi risultati non dovrebbero trasformarsi in un’affermazione non supportata su ogni versione attuale dei browser.

La questione architetturale più ampia è se l’accesso di un assistente crei un percorso che il normale codice di un sito web non avrebbe.

Per gli acquirenti, questa domanda offre un confronto più utile di una classifica generica dell’intelligenza dei modelli. Un assistente capace potrebbe operare entro confini di accesso ristretti. Un’altra implementazione potrebbe esporre informazioni più ampie facendo maggiore affidamento sul giudizio dell’assistente.

Queste configurazioni comportano decisioni d’acquisto diverse anche quando le loro dimostrazioni appaiono simili. Entrambe potrebbero riassumere correttamente una pagina. Solo un esame più approfondito rivelerebbe quali informazioni aggiuntive ciascun assistente può raggiungere durante tale attività.

Si consideri un dipendente ipotetico che chiede un riassunto di una pagina pubblica di un fornitore. L’output previsto riguarda quella pagina. Se il flusso di lavoro consente anche l’accesso a materiale aziendale privato, i valutatori devono capire perché tale accesso esista e cosa ne limiti l’uso.

La richiesta del dipendente fornisce un utile punto di riferimento. Definisce lo scopo aziendale rispetto al quale può essere valutato l’accesso aggiuntivo. Un riassunto riuscito non risponde alla domanda se il sistema abbia esposto più informazioni di quanto richiedesse l’incarico.

Ecco perché anche i confronti richiedono un linguaggio accurato. I ricercatori che identificano una possibile via al danno hanno stabilito qualcosa che merita indagine. Non hanno necessariamente dimostrato un attacco riuscito contro ogni prodotto che condivida una caratteristica progettuale.

Un acquirente dovrebbe applicare la stessa disciplina alle risposte dei fornitori. Un esempio corretto con una patch può chiudere un percorso dimostrato senza stabilire che ogni percorso correlato sia scomparso. Al contrario, un risultato di ricerca più datato non dovrebbe essere automaticamente presentato come una vulnerabilità irrisolta oggi.

La lezione per il dibattito attuale è metodologica. Le affermazioni sulla sicurezza diventano più informative quando identificano il confine testato, le condizioni coinvolte e l’esito osservato. I soli nomi dei prodotti non possono sostenere questa spiegazione.

Ciò sostiene la richiesta di prove di Sharma, aggiungendo però un limite importante. Le evidenze dovrebbero restare legate al sistema e alle circostanze che le hanno prodotte. Estenderle oltre richiede ulteriori test, non una retorica più incisiva.

Un Migliore Comportamento del Modello Non Risolve la Questione del Contenimento

Il resoconto di Anthropic del novembre 2025 sulle difese contro la prompt injection descrive addestramento, sistemi di rilevamento e test avversariali per l’uso del browser. L’azienda riconosce esplicitamente che gli agenti del browser restano vulnerabili.

La sua discussione del maggio 2026 sul contenimento degli agenti distingue le difese del modello dalle restrizioni sull’ambiente in cui opera un agente. Il contenimento significa limitare ciò che un sistema può raggiungere o fare. Anthropic descrive l’uso di confini ambientali insieme a misure volte a migliorare il comportamento del modello.

Questi sono resoconti del fornitore sul proprio approccio. Stabiliscono la logica di sicurezza dichiarata dall’azienda, anziché una prova indipendente che ogni implementazione raggiunga la protezione prevista.

Il confronto importante è tra ridurre la probabilità di un errore e limitarne le conseguenze quando si verifica.

Un assistente ipotetico per i documenti rende concreta questa distinzione. Un giudizio migliore potrebbe aiutarlo a respingere un’istruzione ingannevole contenuta in una proposta. Una restrizione di accesso potrebbe impedirgli di ottenere un documento riservato non correlato, indipendentemente da come interpreti tale istruzione.

Questi esiti rispondono a domande separate. Il cliente desidera un comportamento sensato durante il lavoro legittimo. Vuole inoltre una risposta difendibile su ciò che accade in caso di errore. Una valutazione approfondita dovrebbe esaminare entrambi gli aspetti.

Ciò crea una sfida pratica per le presentazioni destinate agli acquisti. Le dimostrazioni dei modelli sono facili da comprendere perché mostrano comportamenti visibili. Le restrizioni ambientali possono apparire meno impressionanti finché un valutatore non chiede al sistema di oltrepassare un confine vietato.

Una dimostrazione convincente renderebbe visibile il tentativo di oltrepassamento. I valutatori potrebbero quindi esaminare cosa lo abbia bloccato, quali evidenze siano rimaste e se l’incarico legittimo abbia potuto continuare. Il rifiuto in sé sarebbe solo una parte del risultato.

La valutazione dovrebbe considerare anche il costo delle restrizioni. Un assistente fortemente limitato potrebbe richiedere ulteriori input dell’utente o non completare un’attività altrimenti ragionevole. Questo non rende sbagliata la restrizione. Rende il suo effetto operativo parte della decisione d’acquisto.

Allo stesso modo, interruzioni frequenti non sono automaticamente prova di una sicurezza superiore. Un’interruzione merita attenzione quando aiuta una persona a comprendere e autorizzare una conseguenza significativa. Una richiesta di approvazione vaga può lasciare la decisione sottostante altrettanto poco chiara.

La domanda utile per l’acquirente è dunque specifica: quale azione proposta attende l’autorità di chi, e che cosa cambia esattamente dopo l’approvazione? La risposta dovrebbe restare comprensibile a chi è responsabile del risultato aziendale.

Questa impostazione evita una competizione artificiale tra modelli più intelligenti e confini più solidi. I clienti traggono vantaggio da entrambi, ma dovrebbero chiedere ai fornitori di spiegare il contributo di ciascuno. Il miglioramento in un’area non dimostra il miglioramento in ogni altra area.

Inoltre, rende più stringente la pressione competitiva. I fornitori che vendono maggiore autonomia necessitano di evidenze proporzionate all’autorità che i loro prodotti richiedono. L’onere cresce con le conseguenze di un’azione errata.

L’avvertimento zero-trust di Vishal Sharma si inserisce in questo dibattito senza risolverlo. La questione è se l’implementazione fornisca una spiegazione credibile del controllo quando il comportamento collaborativo non è più sufficiente.

Le Prossime Evidenze Dovrebbero Provenire da Test di Fallimento

Nei prossimi tre mesi, i segnali più utili riguarderanno riproducibilità, applicazione delle restrizioni e comportamento in condizioni realistiche di fallimento. Si tratta di punti di osservazione editoriali, non di impegni di rilascio annunciati.

Le evidenze più solide spiegheranno cosa è fallito, cosa è rimasto protetto e se il lavoro legittimo è stato comunque completato.

In primo luogo, occorre osservare un resoconto riproducibile dell’esperimento della Queen’s University Belfast. Una pubblicazione più completa dovrebbe idealmente identificare l’attrezzatura, la configurazione, il metodo di misurazione temporale e il riferimento di base usato per valutare la velocità di attacco riportata.

Queste evidenze rafforzerebbero l’affermazione sperimentale se team indipendenti ottenessero risultati comparabili nelle condizioni dichiarate. Anche un risultato più circoscritto resterebbe informativo. Aiuterebbe i lettori a distinguere una particolare osservazione di laboratorio da un’affermazione generale sugli attacchi assistiti da agenti.

Lo stesso standard si applica al recupero del contesto. Un test utile definirebbe quali informazioni siano state rimosse, dove fossero esistite e quali percorsi di recupero restassero disponibili. Senza questi dettagli, un’apparente rievocazione lascia aperte troppe spiegazioni.

In secondo luogo, occorre osservare rilasci di prodotti che rendano più facili da ispezionare i confini dell’autorità. Il segnale rilevante è una modifica documentata collegata a una restrizione verificabile. Una nuova etichetta di sicurezza, da sola, non fornisce questa evidenza.

Per esempio, un rilascio ipotetico potrebbe dimostrare che un assistente può preparare un messaggio esterno mentre un componente separato ne controlla la trasmissione. I valutatori dovrebbero comunque esaminare il destinatario, il contenuto e le condizioni di autorizzazione coperte da tale restrizione.

Tali evidenze rafforzerebbero l’idea che i fornitori stiano traducendo principi generali di sicurezza in controlli implementabili. Un rilascio che aggiungesse semplicemente un’altra istruzione offrirebbe un sostegno minore alle affermazioni sui limiti applicati in modo indipendente.

In terzo luogo, occorre osservare valutazioni indipendenti che testino il recupero insieme alla resistenza agli attacchi. Bloccare un’operazione indesiderata è prezioso. Gli acquirenti devono anche sapere se il sistema può recuperare senza ripetere il tentativo, perdere lavoro autorizzato o richiedere un intervento eccessivo.

Una valutazione ipotetica potrebbe confrontare lo stesso incarico prima e dopo una restrizione di accesso. Il risultato dovrebbe descrivere sia le azioni vietate sia il completamento legittimo. Altrimenti, un sistema che realizza ben poco potrebbe apparire sicuro per una ragione poco utile.

Risultati che mostrino danni circoscritti e lavoro autorizzato completato rafforzerebbero la tesi dell’autonomia pratica. Risultati che mostrino come il completamento utile richieda un accesso ampio e scarsamente spiegato metterebbero in luce un compromesso persistente.

Questi segnali sono importanti perché, altrimenti, l’argomento attuale può diventare circolare. I ricercatori chiedono verifiche. I fornitori descrivono salvaguardie. Gli acquirenti ricevono rassicurazioni senza una spiegazione comune di ciò che tali rassicurazioni coprono.

Evidenze più precise consentirebbero un disaccordo più circoscritto e produttivo. Un’implementazione potrebbe essere adatta alla redazione e alla ricerca, mentre un’altra potrebbe supportare operazioni con conseguenze rilevanti. La giustificazione dovrebbe identificare ciò che ogni sistema può dimostrare sul proprio comportamento.

Per gli sviluppatori, l’implicazione immediata è rendere verificabili le affermazioni sulla sicurezza prima di ampliare le responsabilità di un agente. Per gli acquirenti aziendali, è collegare l’evidenza richiesta a una specifica conseguenza aziendale. Per i knowledge worker, è comprendere l’autorità associata a un assistente prima di affidargli lavoro sensibile.

Prima del prossimo progetto pilota con un agente, scegliete un’azione contestata e definite l’evidenza che la risolverebbe. Considerate un destinatario non autorizzato, un documento ritirato o una richiesta che ecceda l’incarico originario. Chiedete al fornitore di mostrare cosa accade, dove operi la restrizione e quale traccia rimanga successivamente. Quindi valutate se l’attività autorizzata venga comunque completata. Considerate la dimostrazione come evidenza relativa a quell’implementazione e configurazione, con limiti dichiarati chiaramente. L’avvertimento zero-trust di Vishal Sharma offre una domanda iniziale utile per quella conversazione: quando un assistente afferma di aver seguito le regole, che cosa può effettivamente verificare qualcun altro?