Prompt injection come full system compromise: ASI01 spiegato con exploit reali del 2026

Su un chatbot, una prompt injection ben riuscita ti fa dire una sciocchezza. Su un agente che esegue azioni reali, la stessa tecnica diventa un compromesso di sistema. La differenza la rende plastica EchoLeak, la vulnerabilità zero-click scoperta su Microsoft 365 Copilot e registrata come CVE-2025-32711: un'email con istruzioni nascoste finiva nel contesto di recupero dell'assistente e, alla prima domanda legittima dell'utente, l'agente eseguiva le istruzioni dell'attaccante ed esfiltrava dati interni, senza un solo clic della vittima. Microsoft l'ha classificata CVSS 9.3 critica (vettore AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N), il NIST 7.5 sullo stesso CVE: già il fatto che due valutatori diano numeri diversi dice quanto sia nuovo il terreno. Il punto che mi interessa, da chi fa analisi offensiva su sistemi di questo tipo, non è il singolo bug: è che descrive una classe. Quando un modello non solo parla ma agisce attraverso dei tool, il confine tra "input testuale" e "comando privilegiato" smette di esistere, ed è esattamente questo che la classifica OWASP del 2026 ha deciso di formalizzare con la voce ASI01.

Cosa formalizza ASI01, e perché non è la solita prompt injection

A dicembre 2025 il progetto OWASP GenAI Security ha pubblicato la Top 10 for Agentic Applications 2026, una classifica dedicata ai sistemi autonomi e distinta dalla più nota OWASP LLM Top 10. La prima voce, ASI01 Agent Goal Hijack, descrive la manipolazione degli obiettivi, delle istruzioni o del percorso decisionale di un agente verso esiti non voluti. La distinzione con la prompt injection "classica" (LLM01 nella lista sul layer modello) è sostanziale e va capita: LLM01 riguarda un output errato o manipolato del modello; ASI01 riguarda ciò che un sistema autonomo fa attraverso confini di fiducia quando il suo obiettivo viene dirottato. La prompt injection è il vettore; il goal hijack è la conseguenza quando dietro il modello ci sono dei tool con permessi.

La frase che riassume lo spostamento del 2026 la mette bene McKinsey: nell'era agentica non basta più preoccuparsi che i sistemi non dicano la cosa sbagliata, bisogna preoccuparsi che non facciano la cosa sbagliata. È la differenza tra un errore e un incidente.

Per chi progetta o difende questi sistemi, ASI01 è il punto di partenza di qualunque threat model serio. Non a caso l'ho messa in cima quando ho ragionato sulla checklist di audit della OWASP Top 10 for Agentic Applications: è la categoria che trasforma una curiosità accademica in un rischio operativo.

Il pattern comune: l'agente non distingue le istruzioni dai dati

La ragione strutturale per cui ASI01 è così difficile da chiudere sta in un fatto tecnico semplice. In una SQL injection esiste un confine netto tra codice e dati: una query parametrizzata separa la struttura del comando dai valori, e quel confine è applicabile dalla macchina. In un LLM questo confine non esiste. Le istruzioni di sistema, la richiesta dell'utente e il contenuto non fidato che l'agente legge (un'email, un documento, l'output di una ricerca web) passano tutti nello stesso flusso di token, indistinguibili a livello di modello. Non c'è una "query LLM parametrizzata". È per questo che la stessa OWASP, con un'onestà rara, scrive che data la natura stocastica di questi modelli "non è chiaro se esistano metodi infallibili di prevenzione" per la prompt injection.

Questa è la differenza che cerco sempre di far passare a un cliente che arriva convinto che basti "un filtro". Un filtro alza il costo dell'attacco, non lo elimina, perché le istruzioni ostili possono essere nascoste in modi che il filtro non vede: testo bianco su bianco, commenti HTML, contenuto in un'immagine. Il problema non è la cattiveria di un input, è l'assenza di un confine, e i confini, quando il modello non li ha, vanno costruiti attorno a lui.

Se gestisci applicazioni con agenti che leggono contenuto esterno e vuoi capire come imposto il threat modeling e l'hardening con una mentalità offensiva, nel mio hub dedicato all'AI per la sicurezza aziendale raccolgo gli articoli con la metodologia che applico in difesa.

Gli incidenti del 2026 che lo dimostrano

Il salto dal teorico al documentato è ciò che rende questo tema serio. Vale però una distinzione che tengo rigida, perché è dove il contenuto generato male confonde tutto: una vulnerabilità scoperta e patchata da un ricercatore (ricerca) non è un attacco avvenuto (incidente), e nessuno dei due è un fenomeno misurato su larga scala (misurazione).

Sul fronte ricerca, oltre a EchoLeak, il 2026 ha portato due casi che parlano da soli. ForcedLeak, su Salesforce Agentforce, ha mostrato come un'iniezione indiretta nel campo descrizione di un form pubblico facesse esfiltrare le email dei lead verso un dominio scaduto, ri-registrato dall'attaccante per cinque dollari e ancora presente nella whitelist CSP; non ha un CVE (è un servizio hosted) e il punteggio CVSS 9.4 v4.0 è auto-assegnato dal ricercatore di Noma Security, cosa che va dichiarata quando lo si cita. ShareLeak, su Microsoft Copilot Studio (CVE-2026-21520, CVSS 7.5 v3.1), è il più istruttivo: i ricercatori di Capsule Security hanno dimostrato che anche dopo la patch l'esfiltrazione passava da azioni legittime dell'agente, come l'invio di una mail via Outlook, aggirando la DLP.

Sul fronte incidente reale, il caso più nitido non è una prompt injection contro un agente, ma un agente usato come arma: la campagna GTG-1002 documentata da Anthropic, in cui un attore statale ha usato un agente di coding come orchestratore di operazioni offensive contro decine di organizzazioni, con l'80-90% delle azioni tattiche eseguite dall'AI. Va citata con il suo caveat: Anthropic non ha pubblicato indicatori di compromissione, quindi resta "primo caso riportato", non fatto indipendentemente corroborato.

Sul fronte misurazione, infine, tre team indipendenti (Google, Forcepoint, Unit 42) hanno quantificato a fine aprile 2026 la prompt injection nascosta nelle pagine web reali in attesa di agenti che le leggano; l'analisi Google su miliardi di pagine ha rilevato una crescita del 32% dei payload di iniezione indiretta tra novembre 2025 e febbraio 2026. La fase teorica è finita.

Anche lo sviluppatore che usa l'agente è un bersaglio

C'è una faccia di ASI01 che si tende a ignorare perché meno spettacolare: il bersaglio non è solo l'agente in produzione del cliente, è anche lo strumento con cui lo sviluppatore lavora. Due CVE su Claude Code lo rendono concreto. La prima, CVE-2025-59536 (CVSS 8.7 v4.0, 8.8 v3.1), sfruttava un difetto nel trust dialog di avvio: aprendo l'agente in una directory non fidata, il codice del progetto veniva eseguito prima che l'utente accettasse il prompt di fiducia, e bastava un repository malevolo clonato per ottenere esecuzione di codice locale. La seconda, CVE-2026-21852 (CVSS 5.3 v4.0, 7.5 v3.1), permetteva l'esfiltrazione della API key reindirizzando il traffico tramite l'override di ANTHROPIC_BASE_URL nelle impostazioni del repository, applicate prima della conferma di fiducia.

Entrambe sono patchate, ma la lezione resta: "git clone più apri l'agente" è il nuovo "apri l'allegato". Il file di configurazione di un repository è codice, e come tale va trattato. Quando consiglio un team su come introdurre agenti di coding, questa è una delle prime cose che metto a perimetro, perché un developer compromesso è una porta sull'intera pipeline: dalle sue credenziali si arriva ai segreti del progetto, ai sistemi di deploy e, a cascata, alla produzione. La superficie d'attacco di un agente non finisce dove finisce il suo prompt.

Quando la patch non basta: il problema è architetturale

ShareLeak insegna la lezione più scomoda: si può patchare il bug e lasciare in piedi la vulnerabilità. Se l'esfiltrazione viaggia su un'azione che l'agente è autorizzato a compiere, nessuna patch al parser la ferma, perché non c'è niente di malformato da bloccare. È qui che entra il modello mentale più utile del 2026, il lethal trifecta coniato da Simon Willison: un agente diventa esfiltrabile quando combina tre gambe insieme, l'accesso a dati privati, l'esposizione a contenuto non fidato e la capacità di comunicare verso l'esterno. Quando tutte e tre sono presenti, un'iniezione in un documento può far uscire dati sensibili attraverso un tool legittimo verso un controller esterno.

La conseguenza progettuale è netta: poiché non puoi garantire che l'iniezione non arrivi, devi rompere una delle tre gambe. Togli l'accesso ai dati sensibili a quell'agente, oppure togli la capacità di comunicare verso domini non approvati, oppure isola il contenuto non fidato in un agente che non ha permessi privilegiati. È lo stesso pattern di "quarantena" che applico quando un agente deve leggere input esterno ma non deve poter agire su sistemi critici, e che ho descritto parlando di difesa dei sistemi ad agenti dalla prompt injection.

Le difese che reggono davvero

Non esiste la bacchetta magica, esiste la difesa in profondità. Le contromisure che vedo reggere, in ordine di efficacia reale, partono dal perimetro dei permessi. Il least privilege sui tool è la più potente: un agente che non ha il tool per inviare email all'esterno non può esfiltrare via email, punto. Segue l'output fencing, cioè validare e sanitizzare ciò che l'agente produce prima che inneschi un'azione, soprattutto su azioni irreversibili. Poi gli human-in-the-loop gate sulle operazioni che non si possono annullare: pagamenti, scritture su database, comunicazioni esterne, deploy. Infine l'audit logging a prova di manomissione, che non previene l'attacco ma ti permette di ricostruirlo, e l'input validation con suspicion scoring a monte, che alza il costo senza illudersi di azzerarlo.

Un esempio concreto chiarisce come si applicano insieme. Immagina un agente che fa il triage delle email di assistenza di una PMI: legge la posta in arrivo (contenuto non fidato), ha accesso allo storico dei ticket e dei clienti (dati privati) e può rispondere via email (canale verso l'esterno). Sono le tre gambe del lethal trifecta tutte presenti: un'email costruita ad arte potrebbe istruire l'agente a inoltrare lo storico di un cliente a un indirizzo esterno. La difesa non è un filtro anti-iniezione sull'email, che si può aggirare; è spezzare una gamba. Si dà all'agente solo la capacità di proporre una bozza di risposta che un umano approva (si rompe il canale di uscita autonomo), oppure lo si isola dallo storico completo dandogli accesso al solo ticket corrente (si riduce il dato esfiltrabile). In entrambi i casi l'iniezione può ancora arrivare, ma non si traduce più in un danno. È questo il modo di ragionare che separa un sistema progettato da uno semplicemente assemblato.

Il filo che lega queste difese è che nessuna agisce sul modello, tutte agiscono attorno al modello. È il rovesciamento mentale che chiedo a ogni cliente: smettere di trattare l'agente come un tool fidato e cominciare a trattarlo come un'identità da governare, con i permessi di un dipendente con credenziali, non con quelli di una libreria.

Si può eliminare del tutto la prompt injection?

No, e chi lo promette sta vendendo fumo. La posizione onesta, sostenuta dalla stessa OWASP, è che non esiste oggi un metodo di prevenzione infallibile per la prompt injection, perché deriva dalla natura stessa dei modelli generativi. Quello che si può fare, e che fa la differenza tra un sistema esposto e uno resiliente, è progettare perché l'iniezione, quando arriva, non si traduca in un compromesso: rompere il lethal trifecta, ridurre i permessi, mettere un umano sui punti irreversibili, e poter leggere i log per capire cosa è successo. È ingegneria difensiva ordinaria applicata a una superficie nuova, non magia.

Messo tutto insieme, il messaggio che porto a un decisore è sobrio e per questo credibile. ASI01 non descrive un attacco esotico, descrive ciò che succede quando colleghi un modello a dei tool e dimentichi che non ha un confine interno tra istruzioni e dati. Gli incidenti del 2026 (la ricerca su EchoLeak, ForcedLeak e ShareLeak, la campagna GTG-1002, la crescita misurata dei payload nel web) raccontano tutti la stessa storia da angoli diversi: il vettore è reale, cresce, e la difesa non è un filtro ma un'architettura. Chi costruisce agenti pensando prima alla superficie d'attacco, e non dopo il primo incidente, costruisce sistemi che reggono; chi aggiunge i guardrail alla fine scopre, di solito nel momento peggiore, che erano la parte più importante. Se hai un sistema con agenti che leggono contenuto esterno o agiscono su dati di valore e vuoi una valutazione della sua superficie di esposizione fatta con mentalità offensiva, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.