Gli AI agent segnano il passaggio da un software che risponde a un software che agisce: inviano email, eseguono query, invocano API e scrivono file in modo autonomo.
Questa capacità di azione modifica la superficie di attacco e mette in discussione le premesse su cui si basano la sicurezza perimetrale e lo stesso Zero Trust originario, concepiti per attori umani prevedibili.
Alla base di tutto, vi è un limite strutturale dei large language model (LLM) ovvero l’incapacità di distinguere le istruzioni dai dati, che espone gli agenti alla prompt injection indiretta e a una serie di rischi correlati: excessive agency, identità e credenziali condivise (non-human identity), attacchi agent-to-agent di tipo confused deputy e avvelenamento della supply chain dei tool e dei server MCP.
Ecco cosa sono queste minacce, analizzando il caso Salesloft-Drift di agosto 2025 e mostrando come i principi Zero Trust debbano essere reinterpretati, spostando l’applicazione delle regole di sicurezza dall’ambito della rete a quello dell’utente.
Indice degli argomenti
Zero Trust nell’era dell’AI agent: gli strumenti concreti per agire
In particolare, si parla di identità esplicita e unica, principio del minimo privilegio applicato all’azione, verifica continua per ogni operazione, assunzione di compromissione e tracciabilità completa.
Due approfondimenti tecnici, l’identità d’agente verificabile basata su DID e Verifiable Credential e l’MCP gateway come policy enforcement point, delineano gli strumenti concreti.
Infatti non è necessaria una nuova teoria, ma una reimplementazione di quella esistente nel punto in cui gli agenti operano realmente, trattandoli come una classe distinta di operatori non umani.
Il progetto di Claude for Chrome di Anthropic
Nell’estate del 2025, Anthropic ha avviato il progetto di Claude for Chrome, un agente in grado di leggere le pagine web, cliccare sui pulsanti e compilare i moduli al posto dell’utente.
Nei test di red teaming interni, che hanno riguardato 123 casi distribuiti su 29 scenari di attacco, è bastata un’email che chiedeva di cancellare i messaggi “per motivi di sicurezza” per svuotare la casella di posta senza richiedere alcuna conferma.
Senza mitigazioni, il 23,6% dei tentativi di prompt injection ha avuto successo.
Con l’intera batteria di difese attive, il dato è sceso all’11,2% [1]: anche con tutte le protezioni attive, circa un attacco su nove riusciva comunque a passare.
Un chatbot che produce testo errato genera un output da rivedere, mentre un agente che agisce inviando e-mail, eseguendo query, chiamando API o scrivendo file genera degli effetti.
È questa la discontinuità che gli agenti AI introducono nella superficie di attacco e che spiega perché i modelli di sicurezza progettati intorno al comportamento umano iniziano a mostrare segni di cedimento.
In questo articolo, analizzo il problema e provo ad applicare il paradigma zero trust come misura di contenimento per arginare i rischi.
Perché gli agenti ignorano le assunzioni
La sicurezza perimetrale, e in buona parte lo stesso Zero Trust, presuppone un utente standard: un utente che si autentica da un dispositivo noto, utilizza un numero limitato di applicazioni, lavora in orari ragionevoli e supera controlli di postura e multi-fattore.
Un agente non corrisponde a questo profilo. Opera alla velocità di un computer, può autenticarsi centinaia di volte al secondo, non possiede attributi “umani” da verificare e, per essere produttivo, richiede un accesso ampio e trasversale a sistemi e dati.
Inoltre, c’è un aspetto architetturale che pesa più degli altri: un agente non è un blocco monolitico, ma è costituito da un layer di conoscenza, unciclo di reasoning, integrazioni verso tool esterni, una memoria e un canale di output.
Ogni collegamento è una superficie di attacco e un controllo applicato solo al punto d’ingresso lascia scoperte le altre.
I limiti degli LLM
Alla base di tutto c’è un limite noto dei large language model: non sono in grado di distinguere le istruzioni dai dati.
Tutto ciò che l’agente legge, che si tratti di una pagina web, un’e-mail, l’output di uno strumento o un invito sul calendario, può contenere istruzioni che l’agente esegue.
Kai Greshake ha formalizzato questo concetto nel 2023 con il nome di “indirect prompt injection” [3], e il prompt injection occupa oggi il primo posto nella Top 10 for LLM Applications di OWASP, edizione 2025 [4].
Le minacce
Le principali minacce sono prompt injection, diretta e indiretta, Excessive agency, Identità e credenziali, Agent-to-agent e Supply chain e tooling.
Vediamo nei dettagli cosa sono.
Prompt injection, diretta e indiretta
La variante più pericolosa per gli agenti è quella indiretta, in quanto il payload non proviene dall’utente, ma dai contenuti che l’agente recupera in autonomia.
La tassonomia del NIST sull’adversarial machine learning, aggiornata nel 2025, tratta ormai l’injection diretta e indiretta e la «security of AI agents» come categorie di primo livello [6].
Esiste una regola pratica: un agente che dispone contemporaneamente di accesso a dati riservati, della capacità di ingerire contenuti non attendibili e di un canale per comunicare verso l’esterno è vulnerabile per definizione. Questi tre elementi sono sufficienti perché l’esfiltrazione diventi possibile.
Excessive agency
Si tratta del rischio LLM06 della lista OWASP: a un agente vengono concessi strumenti, permessi o autonomia superiori a quelli necessari per svolgere il compito assegnato.
Il blast radius di una singola injection aumenta con i privilegi dell’agente: se quest’ultimo può interrogare database, chiamare API o eseguire codice, l’esito di un hijack non sarà più una semplice frase errata, ma un’azione non autorizzata concreta a volte irreversibile.
Identità e credenziali
Molti deployment fanno girare gli agenti su API key condivise o su sessioni ereditate dall’utente. Il risultato è che, in caso di incidente, non è possibile stabilire quale agente abbia agito né revocare l’accesso in modo granulare. Ken Huang sostiene che i protocolli IAM convenzionali, come OAuth, OIDC e SAML, non siano strutturalmente adeguati ai sistemi multi-agente, in quanto prevedono controlli a grana grossa pensati per una singola entità e privi di consapevolezza del contesto [7].
Agent-to-agent
Quando più agenti collaborano e si delegano compiti tra loro, si creano delle catene di autorità. Un agente a basso privilegio che, con input opportuni, induce un agente a privilegio più alto a compiere un’azione è la versione moderna del “confused deputy”, un problema di controllo degli accessi vecchio di decenni che viene riproposto su scala AI.
La Top 10 for Agentic Applications di OWASP, pubblicata a dicembre 2025,
individua proprio l’agent goal hijack e l’abuso di identità e privilegi come ategorie a sé stanti [5].
Supply chain e tooling
La fiducia non riguarda solo il modello, ma anche i suoi plugin e i server MCP che mediano l’accesso agli strumenti. Il Model Context Protocol, introdotto da Anthropic alla fine del 2024 [9], ha standardizzato il modo in cui gli agenti invocano strumenti esterni, aprendo una nuova superficie semantica, come la tool description poisoning, in cui i metadati di uno strumento malevolo possono manipolare il comportamento dell’agente.
È il territorio coperto da LLM03, Supply Chain, nella lista OWASP.
Il caso Salesloft-Drift e la lezion e sulla Zero Trust nell’era degli AI agent
A titolo esemplificativo si riporta un caso reale. Drift è un agente di chat basato sull’intelligenza artificiale che, tramite OAuth, sincronizza conversazioni e lead nel CRM di Salesforce.
Tra l’8 e il 18 agosto 2025, il gruppo UNC6395 ha utilizzato i token OAuth e i token di refresh rubati a tale integrazione per autenticarsi sulle istanze Salesforce di oltre 700 organizzazioni, tra cui Cloudflare, Palo Alto Networks, Zscaler e Proofpoint, ed estrarre grandi quantità di dati mediante query SOQL mirate.
La piattaforma Salesforce non è stata violata: gli attaccanti hanno semplicemente personificato un’applicazione fidata grazie a credenziali macchina valide.
L’obiettivo era il credential harvesting ovvero setacciare i dati alla ricerca di chiavi AWS, token Snowflake e password da utilizzare negli attacchi successivi.
In seguito, Salesloft e Salesforce hanno revocato tutti i token Drift e rimosso l’app dall’AppExchange.
Questo è il rischio della non-human identity nella sua forma più pura: un token statico con expire lungo e ritenuto affidabile, concesso a un agente, diventa una chiave universale nel momento in cui viene rubato.
Reinterpretare il modello Zero Trust per l’AI agent
Lo standard di riferimento sullo Zero Trust, la SP 800-207 del NIST, risale al 2020 e non menziona mai gli AI agent, parla di utenti e dispositivi [2]. Eppure, il presupposto fondamentale dello standard, ovvero il fatto che non si deve concedere alcuna fiducia implicita a un asset solo in base alla sua posizione di rete, è esattamente ciò di cui un agente ha bisogno.
I sette principi dello standard si applicano anche in questo caso, ma il punto di deployment cambia, spostandosi dall’insieme di rete all’azione dell’agente. Nella pratica, i principi vengono spesso condensati in tre regole operative.
Identità esplicita e unica
Niente segreti condivisi: ogni agente è un’entità a sé stante, legata a un owner umano responsabile e dotato di credenziali a breve scadenza.
Questa è la direzione indicata dalla ricerca sull’identità degli agenti, dalle Verifiable Agent ID basate su Decentralized Identifier e Verifiable Credential proposte da Huang [7] fino alle architetture Zero-trust per l’«agent web» [11]. Anche senza adottare l’identità decentralizzata, è evidente che il minimo richiesto è: identità univoca, mappatura all’owner e assenza di segreti condivisi.
Least privilege, ma applicato all’azione
Per un utente, il principio del “least privilege” definisce a quali risorse può accedere.
Per un agente, l’identità è necessaria, ma non sufficiente: un agente correttamente autenticato e con credenziali valide può comunque arrecare danni durante il suo normale funzionamento se riesce a raggiungere risorse non pertinenti al suo compito.
La domanda, quindi, si sposta da “a cosa può accedere questa identità?” a “cosa è autorizzato a fare questo agente?”.
Per svolgere il compito in questione sono necessari strumenti specifici, token just-in-time e a vita breve, nonché permessi assegnati per task.
Qui si presenta un paradosso: per essere utili, gli agenti richiedono spesso un accesso ampio e cross-domain, mentre la Zero Trust richiede l’esatto opposto.
L’obiettivo è conciliare queste due esigenze.
Verify explicitly, ad ogni azione
Lo Zero Trust autentica gli utenti per sessione, mentre un agente si autentica centinaia di volte e opera in modo continuo. Pertanto, l’autorizzazione deve essere continua e per singola azione.
In concreto, le call dei tool devono transitare attraverso un policy enforcement point (il modello PEP/PDP della 800-207, che potremmo chiamare gateway MCP o tool broker), in grado di valutare ogni chiamata nel contesto specifico e di negarla o richiedere una conferma.
Inoltre, l’output dell’agente stesso deve essere considerato non attendibile finché non viene verificato.
Assume breach
Bisogna dare per scontato che qualche injection riuscirà e, pertanto, occorrerà progettare in modo tale che il suo successo resti contenuto: sandboxing, microsegmentazione delle capacità e intervento umano obbligatorio sulle azioni irreversibili o ad alto impatto.
Le mitigazioni di Anthropic sono un esempio di questa logica a strati: il blocco delle categorie di siti più rischiosi, i classificatori per i pattern di istruzione sospetti e la conferma forzata delle azioni sensibili.
Ciò ha permesso loro di ridurre il tasso di successo dal 23,6% all’11,2%. L’11,2% residuo rappresenta il punto critico: una parte degli attacchi riesce comunque a passare e l’architettura deve fare in modo che ciò non provochi danni.
Monitoring e tracciabilità
Il settimo principio dell’800-207 chiede di raccogliere quante più informazioni possibili per migliorare la postura. In termini di agenti, significa avere informazioni complete: se non si riesce a ricondurre un’azione alla policy, al contesto, allo strumento e all’autorità che l’hanno permessa, non si ha alcun controllo.
L’osservabilità rende possibile la risposta agli incidenti, altrimenti sarebbe impossibile a causa del traffico tra agenti.
Identità d’agente verificabile (DID e Verifiable Credential)
Oggi la maggior parte degli agenti si autentica con bearer token statici che, solitamente, hanno un time expire lungo, come le API key o i token OAuth.
Un bearer token non dimostra l’identità di chi lo presenta: chiunque lo possieda è l’agente.
Huang sostiene che l’IAM convenzionale (OAuth, OIDC, SAML), nato per gestire l’accesso a singole entità e le sessioni, non sia in grado di gestire flotte di agenti che si delegano compiti a vicenda [7].
L’alternativa prende in prestito i concetti dell’identità decentralizzata. A ogni agente viene assegnato un Decentralized Identifier (DID), un’identità controllata crittograficamente e non rilasciata da un singolo fornitore.
Inoltre, gli agenti devono presentare delle Verifiable Credentials (VC) ovvero delle attestazioni firmate che indicano l’identità dell’agente, il proprietario e le autorizzazioni, e che possono essere verificate senza dover contattare l’emittente.
L’autenticazione diventa una prova crittografica e non più il possesso di un segreto condiviso: una credenziale rubata ha quindi un valore molto più basso, in quanto può essere associata alla chiave dell’agente e ha uno scopo limitato nel tempo.
Un Agent Naming Service (ANS), proposto sempre in questa ricerca, permette agli agenti di scoprire e verificare reciprocamente le proprie identità, come fa il DNS per gli host, ma con la fiducia incorporata [7].
Il sistema di attribuzione e revoca
Il vantaggio è avere un sistema di attribuzione e revoca che funzioni davvero: ogni azione può essere ricondotta a un agente specifico e al suo proprietario e una singola credenziale può essere revocata senza compromettere l’intera integrazione.
Si tratta di un approccio ancora in fase di maturazione, con problemi aperti relativi all’interoperabilità e alla gestione delle chiavi, ma la direzione è chiara: gli agenti hanno bisogno di identità progettate per le macchine che delegano, non di login umani adattati.
Anche senza arrivare alla piena decentralizzazione, il minimo è la lezione del caso visto sopra: credenziali uniche, verificabili e a scadenza breve, anziché token condivisi e statici.
L’MCP Gateway funge da punto di enforcement
Il Model Context Protocol ha uniformato il modo in cui gli agenti chiamano gli strumenti e le fonti dei dati, ma una chiamata diretta tra agente e tool non consente di effettuare controlli.
L’MCP Gateway, o tool broker, inserisce un intermediario in quel percorso: è la reincarnazione del Policy Enforcement Point della 800-207 applicata alle call dei tool anziché al traffico di rete.
Un gateway ben progettato concentra più funzioni in un solo punto. Autentica l’agente e lega ogni chiamata a un’identità e a un proprietario, sostituendo i token statici con credenziali just-in-time a vita breve.
Applica un elenco di strumenti e di scope per agente, in modo che un compito di sola lettura non possa invocare operazioni distruttive. Ispeziona gli input e gli output per intercettare i payload di prompt injection e di tool description poisoning prima che raggiungano il modello.
Imporre un limite di velocità e controlli di anomalia sull’egress: una sequenza di query che esporta volumi fuori norma, come nel caso esposto, viene rallentata o bloccata, anche se le credenziali presentate sono valide.
Richiede una conferma umana per le azioni irreversibili o ad alto impatto. Inoltre, registra ogni invocazione con la provenienza completa, consentendo l’attribuzione a posteriori.
Il valore risiede nel far convergere identità, autorizzazione, ispezione e audit in un unico punto di controllo gestibile, cosa che non avviene quando l’agente dialoga direttamente con i propri strumenti.
Sette suggerimenti
Ecco una serie di azioni da intraprendere se ci si trova di fronte a questi sistemi in produzione:
- È necessario inventariare gli agenti come non-human identity e associare ciascuno a un owner umano responsabile: non si può governare ciò che non si vede.
- Eliminare le credenziali condivise e utilizzare identità uniche per ciascun agente, token a vita breve e revoca granulare.
- Ridurre la superficie assegnando a ogni agente soltanto gli strumenti e i permessi necessari per il compito.
- È necessario mediare le azioni facendo passare le call attraverso un policy enforcement point che valuti il contesto e imponga una conferma umana per le operazioni irreversibili o ad alto impatto.
- Trattare input e output come non attendibili: i contenuti esterni e l’output dell’agente devono essere verificati, non eseguiti automaticamente.
- È necessario effettuare il login affinché ogni azione possa essere ricondotta alla policy e all’autorità che l’hanno consentita.
- È fondamentale attuare il red teaming in modo da dare priorità a un intervento tempestivo prima della messa in produzione piuttosto che alla risoluzione dei problemi a seguito di un incidente.
Intanto, il progetto COSAiS del NIST sta sviluppando dei controlli sovrapposti basati sulla SP 800-53 dedicati ai sistemi AI a singolo agente e multi-agente, costruiti anche sulla taxonomy AI 100-2e2025 [8]. Il linguaggio formale dei controlli per gli agenti è attualmente in fase di definizione.
I 7 principi della Zero Trust da applicare agli AI agent
Zero Trust non è nato per gli AI agent.
Tuttavia, i suoi principi fondamentali, ovvero l’assenza di fiducia implicita, la verifica continua e il contenimento in caso di compromissione, descrivono con precisione ciò di cui un software autonomo ha bisogno.
Il lavoro che resta da fare non è inventare una nuova dottrina, ma reimplementare quella esistente nel punto in cui gli agenti operano: l’action e le call ai tool e non il perimetro di rete.
Gli agenti non devono essere considerati come utenti più veloci, ma come una nuova classe di dipendenti non umani dotati di identità, privilegi e tracciabilità progettati su misura.
Riferimenti
- Anthropic, “Piloting Claude for Chrome”, agosto 2025. https://www.anthropic.com/news/claude-for-chrome
- [2] S. Rose, O. Borchert, S. Mitchell, S. Connelly, “Zero Trust Architecture”, NIST Special Publication 800-207, agosto 2020. https://doi.org/10.6028/NIST.SP.800-207
- [3] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, M. Fritz, “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection”, 16th ACM Workshop on Artificial Intelligence and Security (AISec ’23), 2023, pp. 79–90 (arXiv:2302.12173). https://doi.org/10.1145/3605764.3623985
- [4] OWASP Foundation, “OWASP Top 10 for LLM Applications 2025”. https://genai.owasp.org/llm-top-10/
- [5] OWASP Foundation, “OWASP Top 10 for Agentic Applications 2026”, dicembre 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- [6] National Institute of Standards and Technology, “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations”, NIST AI 100-2e2025, marzo 2025. https://doi.org/10.6028/NIST.AI.100-2e2025
- K. Huang, V. S. Narajala, J. Yeoh, R. Raskar et al., “A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control”, arXiv:2505.19301, https://arxiv.org/abs/2505.19301
- National Institute of Standards and Technology, “Control Overlays for Securing AI Systems (COSAiS)”, progetto in corso, 2025–2026. https://csrc.nist.gov/Projects/cosais
- Anthropic, “Introducing the Model Context Protocol”, novembre 2024.
https://www.anthropic.com/news/model-context-protocol - Google Threat Intelligence Group e Mandiant, “Widespread Data Theft Targets Salesforce Instances via Salesloft Drift”, agosto 2025. https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift
- K. Huang et al., “Fortifying the Agentic Web: A Unified Zero-Trust Architecture Against Logic-layer Threats”, arXiv:2508.12259, 2025. https://arxiv.org/abs/2508.12259.
Partecipa alla community