Riepilogo Tecnico: IPI-proxy

Enunciato del Problema

La proliferazione di agenti AI per la navigazione web negli ambienti aziendali ha introdotto una vulnerabilità di sicurezza critica: l'Iniezione Indiretta di Prompt (IPI). A differenza dell'iniezione diretta di prompt, in cui un avversario interagisce direttamente con il modello, l'IPI si verifica quando un agente recupera contenuti di terze parti (ad esempio, pagine web, documenti) contenenti istruzioni nascoste che il modello esegue come comandi utente legittimi.

Le attuali metodologie di red-teaming e i benchmark non riescono ad affrontare adeguatamente l'IPI in scenari aziendali realistici a causa di tre lacune principali:

1. Disallineamento delle Whitelist: I benchmark esistenti (ad esempio, BIPIA, InjecAgent) si basano su pagine avversarie ospitate su domini controllati dagli attaccanti. Gli agenti limitati a whitelist aziendali rigorose (ad esempio, *.clientcorp.com) non possono accedere a queste pagine senza violare le policy, rendendo i test invalidi per scenari simili alla produzione.
2. Contenuto Statico: I benchmark servono tipicamente pagine avversarie congelate e pre-costruite. Questo non riesce a simulare la natura "live" degli attacchi reali, dove gli avversari iniettano contenuti in domini affidati tramite commenti, wiki o widget di terze parti.
3. Ambito Limitato al Modello: Gli strumenti generici di red-teaming (ad esempio, PyRIT, garak) e i sistemi di rilevamento (ad esempio, Rebuff) sondano direttamente l'API LLM. Non testano la superficie di recupero—il percorso attraverso il quale contenuti non attendibili raggiungono un agente che utilizza strumenti—dove l'IPI si manifesta più frequentemente.

Metodologia

Gli autori propongono IPI-proxy, un toolkit open-source progettato per colmare il divario tra benchmark statici e distribuzione live. L'innovazione centrale è un'inversione architetturale: invece di costringere l'agente a visitare URL controllati dagli attaccanti, IPI-proxy intercetta e modifica le risposte HTTP dai domini che l'agente è già autorizzato a visitare.

Architettura del Sistema

IPI-proxy opera come un proxy Man-in-the-Middle (MITM) a livello di rete basato su mitmproxy. È composto da cinque componenti chiave:

1. Add-on Proxy: Registra un gestore di risposta che ispeziona le risposte HTTP in uscita. Valida l'URL di destinazione rispetto a un pattern target, garantisce che il contenuto sia HTML e verifica il budget di iniezione prima di procedere.
2. Libreria Unificata di Payload: Un file JSONL deduplicato contenente 820 stringhe di attacco estratte da sei benchmark esistenti (BIPIA, InjecAgent, AgentDojo, Tensor Trust, WASP e LLMail-Inject). Questi sono normalizzati sotto uno schema unificato.
3. Template di Incorporamento: Per eludere l'ispezione umana rimanendo visibili agli LLM, i payload sono avvolti utilizzando tre tecniche:
   • Commenti HTML: Inseriti all'interno di blocchi <!-- -->.
   • CSS Invisibile: Avvolti in elementi <div> stilizzati con display: none e posizionamento fuori schermo.
   • Prosa Semantica: Integrati in testo editoriale plausibile, opzionalmente generato da un LLM (ad esempio, Claude) per un'evasione superiore.
4. Iniettore HTML: Inserisce il payload avvolto in una delle sei posizioni specifiche all'interno del documento HTML (ad esempio, head_meta, body_top, sidebar, script_comment). Se un'ancora specifica è assente, il sistema ricade su un'ancora più generica per garantire il successo dell'iniezione.
5. Tracciatore di Esfiltrazione: Un servizio FastAPI leggero che registra i callback. Se un agente segue un'istruzione iniettata per inviare dati a questo tracciatore, il test è contrassegnato come un'esfiltrazione riuscita.

Flusso di Lavoro

1. L'agente richiede un URL da un dominio in whitelist.
2. Il proxy inoltra la richiesta al server upstream.
3. Ricevuta la risposta HTML originale, il proxy seleziona un payload basato su filtri configurati via YAML (tipo di attacco, benchmark di origine, gravità).
4. Il payload viene avvolto e iniettato nell'HTML in un punto di inserimento configurato.
5. L'HTML modificato viene restituito all'agente.
6. Se l'agente esegue l'istruzione iniettata e contatta il tracciatore di esfiltrazione, l'evento viene registrato.

Contributi Chiave

• Red-Teaming Rispettoso delle Whitelist: IPI-proxy è il primo strumento a consentire il test IPI contro agenti limitati a whitelist specifiche modificando le risposte live da quei domini affidabili invece di servire pagine mock.
• Fonte Unificata di Payload: Aggrega e deduplica 820 vettori di attacco da sei benchmark di ricerca disparati, consentendo una valutazione trasversale ai benchmark e la rotazione all'interno di una singola sessione di test.
• Valutazione a Scansione dei Parametri: Disaccoppiando il payload, la tecnica di incorporamento e il punto di inserimento HTML, lo strumento consente una valutazione sistematica della suscettibilità di un agente attraverso una superficie di attacco multidimensionale.
• Design Agnostico rispetto all'Agente: A differenza degli strumenti basati su estensioni del browser, IPI-proxy opera a livello di rete, rendendolo compatibile con fetcher headless, client HTTP personalizzati e strumenti del Protocollo di Contesto del Modello (MCP).

Risultati e Valutazione

Il documento presenta IPI-proxy come un substrato di test piuttosto che come un meccanismo di difesa. Non riporta tassi di successo specifici contro un modello particolare (ad esempio, "Il Modello X ha fallito l'80% delle volte") ma dimostra la fattibilità e la riproducibilità della metodologia di test.

• Lo strumento intercetta e riscrive con successo le risposte HTTP da domini in whitelist senza modificare il server upstream.
• Supporta un regime di valutazione a "scansione dei parametri" che copre combinazioni di payload, incorporamenti e punti di inserimento non supportati simultaneamente dai benchmark esistenti.
• Il tracciatore di esfiltrazione fornisce un segnale di verità fondamentale per attacchi riusciti senza richiedere l'instrumentazione dello stesso agente, preservando l'integrità dell'ambiente di test.

Significato

Gli autori posizionano IPI-proxy come un'evoluzione necessaria nel testing di sicurezza AI. Spostandosi dai benchmark statici di pagine mock all'intercettazione dinamica di risposte live, lo strumento consente ai team di sicurezza di:

1. Misurare la vulnerabilità degli agenti per la navigazione web sotto le stesse restrizioni di egress e fonti di contenuto che affrontano in produzione.
2. Rafforzare gli agenti fornendo un ambiente riproducibile per testare strategie difensive (come la trasformazione degli input o l'isolamento architetturale) contro vettori IPI realistici.
3. Colmare il divario tra benchmark accademici e distribuzione aziendale, assicurando che gli sforzi di red-teaming riflettano la superficie di minaccia reale dove si verifica l'IPI.

Il documento conclude che, sebbene IPI-proxy non risolva il problema dell'IPI in sé, fornisce l'infrastruttura critica necessaria per valutare e mitigare accuratamente il rischio prima che gli agenti vengano distribuiti in ambienti aziendali sensibili.