Man-in-the-Prompt: il nuovo attacco che manipola i prompt dell’intelligenza artificiale

Negli ultimi due anni la prompt injection è diventata il problema centrale della sicurezza applicata agli LLM. L’OWASP GenAI Project la colloca al primo posto tra i rischi per le applicazioni basate su modelli generativi e il National Cyber Security Centre britannico, in un intervento pubblicato l’8 dicembre 2025, ha avvertito che non deve ssere trattata alla stregua di una semplice variante della SQL injection. Questo perché nei modelli linguistici non esiste una separazione tra istruzioni e dati.

1. Cos’è il Man-in-the-Prompt
2. Come funziona il Man-in-the-Prompt
3. Perché il Man-in-the-Prompt è più pericoloso della prompt injection
4. Come difendersi dal Man-in-the-Prompt

Il 29 luglio 2025 i ricercatori di LayerX, in un report firmato da Aviad Gispan, hanno mostrato che il problema può iniziare ancora prima che il prompt raggiunga il modello. Il nome del nuovo attacco? Man-in-the-Prompt ed è descritto come un attacco browser-based in cui un’estensione può leggere, alterare e sfruttare il testo inviato a strumenti come ChatGPT, Gemini, Copilot, Claude e DeepSeek.

Ma come sempre andiamo con ordine e affrontiamo per gradi l’argomento.

Cos’è il Man-in-the-Prompt

Con il termine Man-in-the-Prompt si indica una classe di attacchi resa pubblica il 29 luglio 2025 in cui il vettore non è il contenuto esterno letto dal modello, ma il campo di input del prompt esposto nella pagina web. Secondo i ricercatori di Layer X, l’exploit è stato testato sui principali assistenti generativi accessibili via browser, con proof of concept (PoC) dedicate in particolare a ChatGPT e Google Gemini.

La base tecnica è nota e documentata dai produttori dei browser. Nel caso di Google Chrome i content script delle estensioni vengono eseguiti nel contesto delle pagine web e, tramite il Document Object Model (DOM), possono leggere il contenuto della pagina, modificarlo e inviare informazioni alla propria estensione. Ma questi script possono comunicare con i componenti in background dell’estensione ed estendere la portata dell’operazione.

Rispetto alla prompt injection classica, in cui il comportamento del modello è alterato tramite input malevoli mescolati alle istruzioni, in questo caso la manipolazione avviene prima dell’invio. Non a caso, non si tratta di una vulnerabilità software da CVE, ma di una debolezza nel rapporto tra browser, estensioni e strumenti AI-Driven.

Come funziona un attacco Man-in-the-Prompt

Per comprendere a fondo come funziona un attacco di tipo Man-in.the-Prompt, procederemo a illustrartlo attraverso una simulazione di attacco suddivisa in più fasi.

Fase 1. Accesso iniziale

Generalmente, un primo entry point può essere rappresentato da un’estensione che permette di convertire documenti PDF in editabili Word. Si tratta di un’estensione con variante AI-Driven, che legge il contenuto direttamente dal frontend dell’utente. Un cybercriminale che conosce quel meccanismo, interviene e si posiziona nel mezzo. Crea una pagina malevola che imita perfettamente quella vera dell’estensione e avvia un profilo browser isolato con questi comandi:

mkdir -p mitp-lab/site && python3 -m http.server 8080 -d ./mitp-lab/site

google-chrome –user-data-dir=/tmp/mitp-lab –load-extension=$PWD/lab-ext http://127.0.0.1:8080

In questo modo un’estensione compromessa può interagire con gli assistenti AI anche senza permessi speciali.

Fase 2. Ricognizione del campo prompt

Una volta aperto il copilota interno, l’obiettivo è individuare il nodo del prompt nella pagina. Al criminale basta identificare la presenza del campo:

document.querySelector(‘textarea, [contenteditable=”true”]’)

Questo è fattibilissimo dalla shell del browser stesso, in quanto i content script possono leggere e modificare il DOM della pagina visitata.

Fase 3. Alterazione del prompt

Con l’estensione ormai installata, l’utente esegue un primo prompt, in cui chiede di riepilogare i punti salienti del documento che sta per convertire in Word. Prima dell’invio, questa aggiunge una seconda istruzione non richiesta a seconda di ciò che il cybercriminale ha richiesto. Ad esempio, può richiedere gli elenchi dei file, persone o contenuti visibili al copilota nella sessione corrente. Dal punto di vista del modello, quel testo aggiuntivo non è distinto dal prompt originale, poiché parte integrante dello stesso input e trattato come istruzione legittima. È qui che il Man-in-the-Prompt si sovrappone alla prompt injection, ma lo fa a monte: nel browser dell’utente.

Fase 4. Raccolta della risposta

Quando il modello risponde, il contenuto passa di nuovo attraverso la pagina. A questo punto i content script possono scambiare messaggi con i componenti in background dell’estensione. Si viene a creare un’interrogazione diretta del chatbot in una scheda non visibile all’utente, che poi raccoglie il risultato e lo invia al cybercriminale posto nel mezzo

Fase 5. Copertura delle tracce

L’operazione lascia davvero poche tracce visibili. Con ChatGPT preso di mira, l’estensione apre una scheda in background, ottiene la risposta e poi rimuove la conversazione dalla cronologia in maniera del tutto automatica. In altre aprole, l’utente continua a usare normalmente il servizio, senza accorgersi che il prompt inviato non coincide con quello digitato.

Perché il Man-in-the-Prompt è più pericoloso della prompt injection

Il problema principale del Man-in-the-Prompt è che sfrutta la stessa sessione autenticata dell’utente. L’attaccante non deve forzare l’accesso al sistema né aggirare controlli di autenticazione, ma utilizza direttamente i privilegi già concessi al copilota o allo strumento AI. Se quel sistema può interrogare documenti interni, repository o knowledge base aziendali, l’istruzione nascosta può indurlo a recuperare informazioni che l’utente non aveva richiesto.

Questo rende l’attacco particolarmente insidioso nei contesti aziendali. Molti copiloti sono progettati per accedere a archivi documentali, ticket, codice sorgente o sistemi di posta per assistere l’utente nelle attività quotidiane. Se il prompt viene manipolato, il modello può essere indotto a consultare e riassumere dati sensibili, trasformando di fatto l’assistente AI in uno strumento di raccolta di informazioni.

Dal punto di vista del server, la richiesta arriva come un normale prompt inviato dall’utente. Non esiste una distinzione tecnica tra ciò che è stato digitato e ciò che è stato inserito da un’estensione o da uno script lato client. Questo rende più difficile individuare l’abuso e ricostruire cosa sia realmente accaduto durante la sessione.

Come difendersi dal Man-in-the-Prompt

Di seguito ci sono le misure che hanno più senso, sia per chi usa copiloti web in azienda sia per chi li sviluppa internamente.

• Ridurre al minimo le estensioni installabili.
  In un ambiente dove i prompt contengono dati sensibili, lasciare installazione libera significa accettare un rischio evitabile.
• Bloccare l’accesso delle estensioni ai domini più sensibili.
  I copiloti interni, i portali HR, finanziari e legali vanno trattati come domini ad accesso speciale.
• Non fidarsi del prompt costruito nel browser.
  Il backend deve registrare separatamente il testo digitato dall’utente, il prompt canonico inviato al modello e gli eventuali tool chiamati dopo la risposta.
• Ridurre i privilegi del copilota e dei tool collegati.
  Se il modello sta elaborando dati provenienti da una parte non fidata, i privilegi dovrebbero abbassarsi a quelli di quella parte, non restare a livello amministrativo.
• Introdurre approvazione umana per operazioni sensibili.
  Quando il copilota può inviare mail, estrarre documenti, interrogare archivi o avviare workflow, l’ultima decisione non può restare al modello. I controlli Human-in-the-Loop sono la difesa primaria per le operazioni ad alto rischio.
• Monitorare interazioni, tool use e anomalie sul lato applicativo.
  Si devono monitorare le interazioni con il DOM dei tool generativi, cercando listener e webhook che toccano i campi prompt, e di bloccare le estensioni in base al comportamento reale, non solo ai permessi dichiarati.

In conclusione

In base a quanto affrontato, possiamo dedurre che il Man-in-the-Prompt sposta il punto di compromissione nel luogo in cui nasce l’interazione con l’intelligenza artificiale: il browser dell’utente. In molte architetture l’attenzione è concentrata sul modello, sui filtri o sui dati che il sistema può consultare. Se però il prompt può essere modificato prima ancora di arrivare al backend, quella catena di controlli parte già da un’informazione alterata.

Il problema non riguarda soltanto chi sviluppa modelli linguistici, ma tutte le organizzazioni che integrano copiloti web nei propri sistemi e consentono loro di accedere a documenti, ticket, repository o archivi interni. In questi contesti il modello agisce con i privilegi dell’utente e può interrogare risorse aziendali legittimamente accessibili. Per cui, la difesa non può basarsi solo su filtri o regole applicate al modello. Serve controllo anche sull’ambiente in cui il prompt viene generato. Senza questi accorgimenti, il punto più debole resta proprio quello da cui parte l’interazione: il nostro stesso PC.