La maggior parte dei programmi di sicurezza per l'IA si ferma alla prima fase. Un team lancia una batteria di prompt avversariali, il modello aggira il guardrail una volta su cinquanta tentativi, il rilievo diventa un ticket di severità media e il discorso si chiude. Il report dice "il modello è vulnerabile a prompt injection". Non dice cosa ne farebbe un avversario.
È questa la lacuna che la Promptware Kill Chain esiste per colmare. Abbiamo adattato il framework dalla ricerca di Schneier et al. (2025) e lo abbiamo trasformato in una metodologia offensiva a sette fasi — dall'accesso iniziale alla compromissione totale. La premessa è semplice: la prompt injection non è l'attacco. È la porta d'ingresso.
Perché la kill chain tradizionale non basta
I framework classici presuppongono un confine netto tra codice e dati. Un binario esegue istruzioni; un file di configurazione fornisce parametri. Lo sfruttamento avviene quando l'attaccante riesce a spostare i dati dal lato del codice.
In un LLM quel confine non esiste. Il system prompt, l'input dell'utente, il documento recuperato dal vector store e l'output di uno strumento arrivano al modello sullo stesso canale — testo. Il modello non ha alcun meccanismo strutturale per distinguere l'istruzione legittima dell'operatore da quella piantata dentro un PDF che la pipeline RAG ha appena indicizzato.
Il risultato pratico: ogni dato che entra nel contesto è potenzialmente eseguibile. Un framework di attacco per sistemi di IA deve partire da questa realtà, non adattarla.
Le sette fasi
1. Accesso iniziale
L'avversario ottiene un ingresso nel sistema di IA. I vettori che testiamo più spesso:
- Prompt injection diretta — l'utente è l'attaccante e interagisce direttamente con l'interfaccia.
- Prompt injection indiretta — l'istruzione arriva tramite contenuto che il sistema consuma: un'email, una pagina web, un ticket di supporto, un documento nel vector store.
- Avvelenamento dei dati — manipolazione del corpus di fine-tuning o degli embeddings.
- Plugin ed endpoint compromessi — l'integrazione di terze parti come punto d'ingresso.
Il vettore indiretto è il più sottovalutato e il più sfruttato negli incidenti reali. Non richiede che l'attaccante abbia accesso al sistema — richiede solo che riesca a mettere del testo dove il sistema andrà a leggere.
2. Escalation di privilegi
Dentro il contesto del modello, l'attaccante amplia ciò che può fare: aggira i guardrail, estrae il system prompt, oppure sblocca chiamate a strumenti che dovrebbero restare riservate all'operatore.
Estrarre il system prompt viene di solito trattato come rilievo di bassa severità. Non lo è. Il system prompt descrive gli strumenti collegati, i limiti di autorizzazione e spesso la struttura dei dati accessibili. È la mappa della rete — solo che in linguaggio naturale.
3. Ricognizione
L'avversario enumera le capacità: quali strumenti l'agente può invocare, quali fonti dati raggiunge, quali altri agenti esistono nella pipeline, quali credenziali rientrano nell'ambito della sessione.
Qui l'asimmetria è evidente. Un agente con accesso a email, calendario e a un database vettoriale aziendale risponde alle domande sulla propria configurazione con la stessa disponibilità con cui risponde a quelle sul business.
4. Persistenza
La fase che separa un test da scrivania da un esercizio realistico. L'attaccante scrive istruzioni in un punto che sopravvive alla fine della sessione:
- memoria a lungo termine dell'agente;
- documenti nel vector store che verranno recuperati in conversazioni future;
- file di configurazione o regole di progetto che l'assistente legge a ogni avvio.
Negli incidenti che abbiamo catalogato tra il 2025 e il 2026, il 57% dei casi ha mantenuto persistenza attiva dopo la rilevazione iniziale. L'organizzazione ha rimediato al sintomo — ha bloccato il prompt, ha ritoccato il filtro — e ha lasciato il payload al suo posto.
5. Comando e controllo
Vengono stabiliti canali di uscita. Un agente con accesso al web ha un canale C2 integrato: basta codificare i dati nel path di una richiesta. Un agente con accesso alle email ne ha un altro. La memoria conversazionale di un assistente condiviso può fungere da dead drop tra le operazioni — è esattamente lo schema osservato nel caso ZombAI.
6. Movimento laterale
L'agente compromesso raggiunge altri sistemi. Nelle architetture multi-agente, un agente si fida dell'output di un altro per lo stesso motivo per cui si fida dell'input dell'utente: è tutto testo. Un'istruzione piantata nell'agente A viene eseguita dall'agente B come se fosse legittima.
L'incidente GeminiJack ha dimostrato movimento laterale attraverso un intero ambiente Workspace, zero-click, senza che l'utente interagisse con nulla.
7. Azioni sull'obiettivo
Esfiltrazione di dati, manipolazione di sistemi, frode, oppure uso dell'accesso come ponte verso l'ambiente tradizionale. CVE-2025-53773 (GitHub Copilot) e CurXecute (Cursor IDE) chiudono il ciclo in modo inequivocabile: suggerimento di codice malevolo che porta all'esecuzione arbitraria di comandi sulla macchina dello sviluppatore. L'attacco comincia in linguaggio naturale e finisce in shell.
Cosa dicono i dati
Abbiamo catalogato 21 incidenti di promptware tra il 2025 e il 2026. Due numeri contano più degli altri:
- 15 dei 21 hanno presentato quattro o più fasi della kill chain. Gli attacchi ai sistemi di IA non sono one-shot. Sono campagne.
- Il 57% ha mantenuto persistenza dopo la rilevazione iniziale. Il tempo di permanenza è lungo perché la superficie di rilevazione — memoria, embeddings, contesto — non è monitorata dai controlli esistenti.
Se il tuo test di sicurezza dell'IA produce un elenco di prompt che hanno rotto il guardrail, hai misurato la fase 1 e hai estrapolato il resto.
Come questo cambia il test
Applicare la kill chain riorganizza l'esercizio attorno a tre domande:
- Portata. Compromesso il modello, cosa raggiunge davvero? Non quello che dice la documentazione — quello che le credenziali della sessione permettono.
- Persistenza. Esiste un punto scrivibile che il modello rilegge? Se sì, è un meccanismo di persistenza, indipendentemente dal fatto che sia stato progettato come tale.
- Rilevazione. Le fasi da 4 a 6 generano qualche segnale osservabile? Nella maggior parte degli ambienti che abbiamo valutato la risposta è no — i log registrano l'interazione, non l'intenzione.
L'output smette di essere un elenco di jailbreak e diventa un percorso d'attacco con evidenza riproducibile a ogni fase, classificazione di severità per impatto sul business e un ordine di correzione motivato.
Da dove iniziare
Se gestisci sistemi di IA in produzione, tre controlli hanno il ritorno immediato migliore:
- Riduci l'agency. La maggior parte della severità viene dalla fase 7, e la fase 7 è limitata da ciò che l'agente può fare. Permessi di lettura al posto di quelli di scrittura eliminano intere classi di impatto.
- Tratta la memoria come superficie d'attacco. Se l'agente scrive in un archivio che poi rilegge, quell'archivio ha bisogno di revisione, scadenza e log.
- Strumenta la fase 5. Le chiamate in uscita avviate dagli agenti — HTTP, email, invocazione di strumenti — devono essere loggate e correlabili all'input che le ha originate.
Nessuno di questi controlli dipende dalla capacità del modello di "resistere" alla prompt injection. È voluto: la kill chain dà per scontato che la fase 1 funzionerà e progetta la difesa per le sei fasi successive.
La Promptware Kill Chain è il framework dietro i nostri esercizi di Red Team per l'IA e il pentest di LLM. Per discutere l'applicazione nel tuo ambiente, parla con il team.