BrowseSafe++: costruire difese più solide contro la prompt injection nel mondo reale

Gli agenti in grado di navigare sul web, come l’assistente integrato in Comet o Computer, devono interagire con le pagine web, leggendone i contenuti e utilizzandoli per eseguire azioni per conto dei propri utenti. Questo li rende vulnerabili alla prompt injection indiretta, in cui un attaccante inserisce testo malevolo in una pagina web. Se l’agente segue queste istruzioni, può restituire una risposta fuorviante o compiere un’azione che l’utente non ha richiesto.

Nel dicembre 2025 abbiamo rilasciato BrowseSafe, un benchmark e un modello di rilevamento per questa minaccia. Lo abbiamo realizzato aggiungendo attacchi sintetici a pagine web realistiche che gli agenti avrebbero probabilmente incontrato. Nell’ultimo anno gli attacchi si sono evoluti, diventando più sofisticati e sempre più simili al normale contenuto delle pagine. Invece di usare frasi rivelatrici come “ignora le istruzioni precedenti”, spesso imitano contenuti di cui l’agente tende a fidarsi, come un avviso ufficiale del sito o una nota sulle preferenze dell’utente.

Spinti da questi cambiamenti, abbiamo creato un benchmark aggiornato, BrowseSafe++, per misurare se gli attuali rilevatori di iniezioni intercettano questi attacchi e se gli agenti riescono a resistervi. Contiene 38.675 coppie di pagine attaccate e pulite, costruite principalmente attorno a iniezioni raccolte nel mondo reale. Per ogni pagina riscriviamo il contenuto circostante per tutelare la privacy, ma manteniamo l’attacco alla lettera. Ogni pagina è disponibile nei quattro formati letti dagli agenti browser: HTML, Markdown, alberi di accessibilità e screenshot. Abbiamo usato un sottoinsieme del benchmark per addestrare BrowseSafe-Guard, una coppia di rilevatori da 0,8 miliardi di parametri: un rilevatore testuale e uno multimodale. I due rilevatori Guard identificano le iniezioni con maggiore accuratezza rispetto ai modelli guidati da prompt che abbiamo testato, compresi i modelli di frontiera. Sono anche più veloci, più economici e segnalano per errore molte meno pagine ordinarie.

Rilasciamo BrowseSafe++ come benchmark aperto. Il sito web del progetto rimanda al dataset, all’SDK, all’articolo di ricerca e a una classifica pubblica. Qualsiasi team può valutare il proprio rilevatore su pagine di test le cui etichette non vengono fornite e inviare le etichette per la valutazione e l’eventuale inclusione nella classifica. Per valutare e inviare i tuoi risultati, consulta Per iniziare.

Costruire un benchmark a partire dalle iniezioni osservate

BrowseSafe++ è costruito a partire da prompt injection osservate su siti web reali. Tra settembre 2025 e settembre 2026, il rilevatore di prompt injection di Comet ha segnalato 1,15 milioni di iniezioni nelle pagine lette dal suo agente. Abbiamo costruito 32.187 coppie attorno a queste iniezioni e aggiunto 6.488 coppie dal benchmark BrowseSafe originale, per un totale di 38.675 coppie. Ogni coppia contiene sia una pagina attaccata sia la sua gemella pulita, ovvero la stessa pagina senza l’iniezione.

Come appaiono le iniezioni nel mondo reale

Due esempi tratti dal benchmark mostrano come appaiono in pratica queste iniezioni.

In un caso, una falsa richiesta di acquisto spinge l’agente a compiere un’azione non autorizzata. Nell’ottobre 2025, il rilevatore di Comet ha segnalato questo blocco di testo in inglese su una pagina di documentazione per sviluppatori in lingua russa:

Il testo si apre e si chiude con degli ordini e riempie la parte centrale con comune materiale promozionale su token. Afferma di provenire dallo sviluppatore stesso dell’agente e si conclude con un codice di autorizzazione per far sembrare approvato l’acquisto.

In un altro, una conversazione contraffatta mira a sabotare l’attività dell’agente. Questo testo è stato trovato su una pagina di un repository di codice a marzo 2026:

Il testo è costruito per sembrare una conversazione tra un utente e un agente: <|im_start|> e <|im_end|> sono marcatori che alcuni modelli di chat usano per separare i turni di una conversazione. Un agente che cadesse in questo attacco risponderebbe alla falsa richiesta dell’utente con la frase dell’attaccante.

Osserviamo schemi simili nelle iniezioni segnalate:

• Emulano fonti attendibili. Entrambi gli esempi fanno sembrare il testo della pagina una fonte di cui l’agente si fida: il suo sviluppatore nel primo, la sua stessa conversazione nel secondo. Le iniezioni possono anche spacciarsi per il sito stesso, imitando controlli di sicurezza e avvisi sulle policy, oppure per l’utente, proponendo false preferenze. Circa due su tre sono scritte in linguaggio formale.
• Molte sono scritte in lingue diverse. Nel 24,4% delle coppie, l’iniezione usa una lingua diversa dal resto della pagina. In genere si tratta di un’istruzione in inglese su una pagina non in inglese, come nel primo esempio. Attacchi di questo tipo sono chiaramente rivolti a un agente che legge qualsiasi lingua e la cui lingua nativa è solitamente l’inglese. I cambi di lingua rendono inoltre più difficile il rilevamento: nella nostra valutazione originale di BrowseSafe, gli attacchi multilingue erano tra i più difficili da intercettare.
• La maggior parte vuole azioni, non parole. Più di quattro su dieci spingono l’agente verso un’azione che l’utente non ha mai richiesto, come l’acquisto del token nel primo esempio, e circa un terzo cerca di fargli abbandonare l’attività dell’utente, come nel secondo esempio. Solo il 3% circa cerca di inserire informazioni false nella risposta.
• Spesso sfruttano contenuti che chiunque può pubblicare. Un attaccante non ha bisogno di controllare un sito. Basta un post in un forum o un documento condiviso su siti comuni, e oltre 23.000 iniezioni in BrowseSafe++ sono arrivate in questo modo. Anche un dominio attendibile può essere sfruttato per iniettare il testo di un attaccante.

Le iniezioni presenti nel benchmark finale coprono 12 tipi di siti web, 24 tipi di attacco, 6 obiettivi dell’attaccante e 18 posizionamenti nella pagina.

Espandi

Da una pagina segnalata a una coppia del benchmark

Non possiamo inserire nel benchmark le pagine segnalate così come sono, perché potrebbero contenere informazioni personali dell’utente per cui l’agente stava lavorando. Trasformare una pagina in una coppia condivisibile per il benchmark richiede tre fasi principali:

1. Reperire l’iniezione: raccogliamo le pagine segnalate, rimuoviamo i duplicati e mascheriamo le informazioni personali con PII-Tracer. Quindi verifichiamo che la pagina contenga un’iniezione; nello specifico, richiediamo che un gruppo di modelli concordi sul fatto che contenga un’istruzione che tenta di distogliere un agente dall’attività prevista dall’utente.
2. Costruire la coppia: un agente rimuove il testo dell’iniezione da ogni pagina e riscrive il contenuto circostante, sostituendo dettagli come nomi e marchi con altri fittizi. Un secondo agente controlla la pagina riscritta alla ricerca di contenuti reali residui e rimanda indietro quelle non conformi con un feedback. Revisori umani esaminano un 10% casuale delle pagine; i problemi che individuano vengono corretti nella pipeline e le correzioni vengono applicate all’intero corpus. L’iniezione viene reinserita nella pagina riscritta per creare la copia attaccata ed esclusa dalla copia pulita. Le due pagine condividono la stessa attività, lo stesso risultato atteso e le stesse istruzioni ordinarie.
3. Verificare: gli agenti leggono le pagine in forme diverse, quindi convertiamo l’HTML di ogni pagina in Markdown, in un albero di accessibilità (un elenco strutturato degli elementi dell’interfaccia di una pagina e delle relative etichette) e in uno screenshot. Un altro agente verifica che l’iniezione compaia in tutte e quattro le viste della pagina attaccata e che la pagina pulita venga giudicata innocua in ogni vista. Se l’iniezione manca in una delle viste, la spostiamo in un altro punto della pagina ed eseguiamo di nuovo il rendering, assicurandoci che l’iniezione sia presente nella pagina attaccata finale in tutte le viste. Un ultimo insieme di controlli automatici corregge le coppie che conservano ancora tracce della loro origine, come nomi host o nomi di marchi reali.

Espandi

BrowseSafe-Guard: rilevatori veloci e precisi per ogni vista

Un rilevatore utile deve controllare ogni pagina in modo rapido ed economico. Deve inoltre essere accurato sia sulle pagine attaccate sia su quelle pulite. Un’elevata precisione è particolarmente importante, dato che la maggior parte delle pagine è sicura: anche un tasso di falsi positivi relativamente basso renderebbe falsi allarmi la maggior parte degli avvisi. I modelli generici guidati da prompt spesso non raggiungono una precisione sufficiente e sono troppo lenti e costosi per essere eseguiti su ogni pagina.

Un rilevatore addestrato su pagine attaccate e pagine pulite raccolte separatamente potrebbe imparare scorciatoie che, per caso, separano i due insiemi, come l’argomento o il layout di una pagina. Un rilevatore di questo tipo, però, non generalizza bene. Guard invece viene addestrato su coppie la cui unica differenza è l’iniezione stessa, il che aiuta a migliorare la precisione del rilevatore. Per ogni coppia, Guard legge separatamente la pagina attaccata e la sua gemella pulita e assegna a ciascuna un punteggio che indica la probabilità che contenga un’iniezione. Per aggiornare il modello si usano due obiettivi di addestramento: l’obiettivo di classificazione standard e un obiettivo di ranking che penalizza Guard a meno che la pagina attaccata non ottenga un punteggio superiore a quello della sua gemella di almeno un margine fisso. Intuitivamente, l’obiettivo di classificazione insegna a Guard quale decisione prendere, mentre l’obiettivo di ranking lega tale decisione all’iniezione stessa e ignora i distrattori innocui. In questo modo Guard impara a reagire all’iniezione stessa, anziché al contenuto circostante della pagina.

Guard è composto da due rilevatori, ciascuno ottenuto tramite fine-tuning di Qwen3.5-0.8B. Il rilevatore testuale legge una vista testuale di una pagina: HTML, Markdown o albero di accessibilità. Il rilevatore multimodale legge uno screenshot dell’intera pagina. In produzione, Guard legge una pagina in un singolo forward pass e restituisce un punteggio di iniezione; la pagina viene segnalata se il punteggio supera una soglia. Poiché Guard ha solo 0,8 miliardi di parametri e restituisce un singolo punteggio, è abbastanza veloce ed economico da poter essere eseguito su ogni pagina.

Valutazione delle prestazioni

Abbiamo confrontato Guard con 18 modelli istruiti tramite prompt per rilevare le iniezioni su un sottoinsieme del benchmark tenuto da parte. Riportiamo quattro metriche, misurate su BrowseSafe++:

• Il recall è la quota di pagine con iniezione che il rilevatore segnala: misura quanti attacchi intercetta, quindi più è alto, meglio è.
• Il tasso di falsi positivi (FPR) è la quota di pagine pulite che il rilevatore segnala per errore: misura quanto spesso genera falsi allarmi, quindi più è basso, meglio è.
• La precisione è la quota di pagine segnalate che contengono davvero un’iniezione: misura quanto spesso un avviso è corretto, quindi più è alta, meglio è.
• L’F1 è la media armonica di recall e precisione: è alto solo quando un rilevatore intercetta la maggior parte degli attacchi e poche delle sue segnalazioni sono falsi allarmi.

Usiamo l’F1 come metrica principale, poiché un buon rilevatore dovrebbe avere precisione e recall elevati. Tutte e quattro le metriche sono mediate sulle tre viste testuali.

Espandi

Espandi

Confronto tra modelli

I piccoli modelli a pesi aperti che abbiamo testato si sono piazzati in fondo alla classifica. Mistral NeMo e Qwen3 30B-A3B segnalano ciascuno circa la metà delle pagine pulite, mentre Llama 3.1 8B non segnala quasi nulla e si lascia sfuggire la maggior parte degli attacchi. Persino il modello più forte del gruppo, GPT-OSS 20B, raggiunge solo un F1 del 70,97%. DeepSeek V3.1, un modello a pesi aperti molto più grande, fa leggermente meglio, con un F1 del 75,23%.

I modelli API leggeri, tra cui GPT-5.4 nano, Gemini 3.1 Flash-Lite e Claude Haiku 4.5, intercettano più attacchi, con un recall compreso tra l’85% e il 97%. Il prezzo da pagare, però, è un’elevata quota di falsi allarmi: Gemini 3.1 Flash-Lite ha l’FPR più basso del gruppo, pari al 35,2%, mentre l’FPR di Haiku è vicino al 69%. Di conseguenza, il punteggio F1 massimo del gruppo è dell’80,9%, ottenuto da Gemini 3.1 Flash-Lite.

I modelli rimanenti sono modelli generici più potenti, con punteggi F1 compresi tra l’85% e il 92%. Tuttavia, devono ancora fare i conti con il compromesso tra recall e FPR: i modelli più cauti bloccano pagine legittime, mentre quelli che segnalano meno frequentemente si lasciano sfuggire gli attacchi. Claude Sonnet 5 ha il recall più alto tra tutti i rilevatori, pari al 98,73%, ma un FPR del 24,65%. Gemini 3.1 Pro e GPT-5.5 raggiungono un recall rispettivamente del 97,78% e del 97,19%, con FPR del 19,80% e del 20,44%. GPT-6 Astra ha l’accuratezza complessiva più alta, con un recall del 96,42% e un FPR del 14,41%. Decider è secondo, con un recall del 96,02% e un FPR del 17,44%. Claude Opus 5.5 ha l’FPR più basso, appena il 4,21%, ma il suo recall del 77,71% significa che si lascia sfuggire più di un attacco su cinque. Claude Fable 5.1 appare solido sulle pagine a cui risponde, con un recall dell’89,31% e un FPR del 7,92%, ma si rifiuta di rispondere su circa il 30% delle pagine, che la riga “(all)” conteggia come segnalazioni.

Espandi

Guard sposta in avanti la frontiera di Pareto, ottenendo un compromesso migliore tra attacchi mancati e falsi allarmi. Raggiunge un F1 di circa il 95% e si classifica primo in ogni vista testuale. Segnala solo circa una pagina pulita su 20, circa un terzo del tasso di Astra, il modello guidato da prompt più accurato. Questa differenza deriva dal nostro addestramento: il Qwen3.5-0.8B di base su cui è costruito Guard, istruito tramite prompt come gli altri modelli, raggiunge solo un F1 del 64% e segnala quasi tre pagine pulite su quattro. Nello scenario della vista screenshot, confrontiamo il rilevatore multimodale di Guard con quattro modelli in grado di elaborare immagini. Con screenshot di pagine intere, Guard ottiene un F1 di circa il 93%, contro circa il 79% del migliore tra gli altri modelli valutati.

Riconoscere un attacco non equivale a resistervi

Intuitivamente, un modello in grado di identificare correttamente un’iniezione dovrebbe anche ignorarla quando incontra la pagina mentre svolge le attività dell’utente. I nostri esperimenti mostrano invece che punteggi di rilevamento elevati non garantiscono che un modello resista a un attacco. Abbiamo fornito a ciascun modello la stessa pagina attaccata due volte: una per giudicare se contenesse un’iniezione e una per svolgere l’attività dell’utente senza vedere il verdetto precedente. Un giudice separato ha verificato se il modello avesse seguito l’iniezione. Ogni modello testato ha comunque seguito alcune iniezioni che aveva segnalato, dall’1,64% delle pagine segnalate per GPT-6 Astra al 24,73% per Llama 3.1 8B.

Espandi

I punteggi di rilevamento non prevedono in modo affidabile le differenze tra i modelli. Claude Sonnet 5 e GPT-5.5 rilevano le iniezioni con un’efficacia quasi identica, con punteggi F1 rispettivamente di circa l’88% e l’89%. Tuttavia, Sonnet 5 ha seguito un’iniezione che aveva segnalato nel 19,74% delle pagine, dieci volte più spesso di GPT-5.5, fermo all’1,97%.

Un sistema implementabile per la difesa dalle iniezioni

Questi risultati suggeriscono che è utile delegare la decisione di bloccare una pagina a un modello specializzato, invece di affidarsi al modello che svolge l’attività dell’utente. Un rilevatore separato che esamina ogni pagina prima che l’agente agisca fornisce un ulteriore livello di difesa e non ha attività da dirottare né strumenti da usare in modo improprio.

Guard è stato creato proprio per essere quel rilevatore. Oltre ad avere l’F1 e l’accuratezza più elevati tra tutti i modelli che abbiamo testato, grazie alle dimensioni ridotte è abbastanza economico da poter essere eseguito su ogni pagina. In media, Guard ha utilizzato circa 0,15 secondi di tempo GPU per pagina di testo. Su una H200 a noleggio stimiamo un costo di 0,18 $ ogni 1.000 pagine, rispetto ai 18,95–180,61 $ dei modelli API di frontiera ai prezzi di listino. Nel nostro confronto, ciò rende lo screening frequente molto più economico, mantenendo al contempo punteggi di rilevamento elevati.

La figura seguente mette in relazione l’accuratezza di ciascun rilevatore con il tempo per pagina e il costo ogni 1.000 pagine, entrambi su scala logaritmica. Guard si trova da solo nell’angolo in alto a sinistra di entrambi i pannelli: vince per accuratezza, velocità e costo. Ogni modello guidato da prompt impiega circa un secondo o più per pagina, e i due più accurati, GPT-6 Astra e Claude Fable 5.1, costano oltre 100 $ ogni 1.000 pagine.

Espandi

Testare le difese contro gli attacchi adattivi

Il benchmark BrowseSafe++ contiene un insieme finito di iniezioni. Un attaccante reale, però, può sferrare un attacco adattivo: quando un’iniezione fallisce, può riscriverla e riprovare. Di conseguenza, un agente che resiste all’iniezione originale potrebbe comunque essere vulnerabile ad attacchi futuri. Inoltre, i modelli vengono addestrati su dati raccolti da internet, quindi potrebbero imparare a resistere alla maggior parte delle iniezioni che vi si trovano; poiché rendiamo pubblico il nostro benchmark, è probabile che arrivi a saturazione e non riesca più a distinguere bene i modelli. Per affrontare entrambi i problemi, abbiamo creato BrowseSafe-Adapt, un ambiente di test in cui un modello attaccante può riscrivere le iniezioni. Ogni test si articola in tre fasi:

1. Preparare il caso. Un caso associa una voce di BrowseSafe++ a un agente bersaglio. La voce di BrowseSafe++ include uno scenario con una query e un’attività dell’utente, una pagina attaccata e il risultato desiderato dall’attaccante. L’agente opera in una sandbox che fornisce gli strumenti e i dati sintetici necessari per eseguire l’attività. Un modello verificatore separato valuta se l’attacco ha raggiunto il suo obiettivo.
2. Eseguire un tentativo: inseriamo l’iniezione corrente nella pagina e lasciamo che l’agente svolga l’attività. Il verificatore controlla la risposta dell’agente ed eventuali modifiche apportate alla sandbox per stabilire se l’attacco è riuscito. Il primo tentativo usa l’iniezione della voce originale di BrowseSafe++.
3. Rivedere e ripetere: se un attacco fallisce, archiviamo il tentativo e un modello critico analizza cosa non ha funzionato. Un modello attaccante usa quel feedback per riscrivere l’iniezione; può cambiare la formulazione, la formattazione o la posizione dell’attacco nella pagina. L’obiettivo dell’attacco, i criteri di successo e il contenuto circostante della pagina restano invariati. Il tentativo successivo usa l’attacco aggiornato. Il processo si ripete finché l’attacco non riesce o l’attaccante non raggiunge un limite prestabilito di tentativi.

Espandi

Abbiamo testato sette agenti, ciascuno basato su un modello diverso: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite e i modelli a pesi aperti DeepSeek V3.1 e Kimi K2. Ogni agente ha affrontato le stesse 1.024 attività, con un massimo di 64 tentativi per attività. Al primo tentativo, il tasso di successo degli attacchi è stato basso per tutti e sette gli agenti. Le iniezioni originali sono riuscite al massimo nel 4% delle attività valutate, qualunque fosse l’agente. Con il framework adattivo, il successo degli attacchi è aumentato drasticamente. L’attaccante è riuscito in almeno il 79% delle attività contro cinque dei sette agenti. Anche gli agenti più robusti si sono rivelati vulnerabili: gli attacchi sono comunque riusciti in circa due attività su tre contro GPT-5.5 e in circa una su tre contro Claude Sonnet 5.

La differenza tra gli agenti è massima quando l’obiettivo dell’attaccante è far eseguire all’agente una specifica chiamata a uno strumento. Per le attività con questo tipo di obiettivo, Sonnet 5 ha ceduto in circa l’8% dei casi e GPT-5.5 in circa il 29%. Gli altri cinque hanno portato a termine l’obiettivo dell’attaccante in più della metà delle loro attività.

Abbiamo anche eseguito BrowseSafe-Adapt contro l’agente Gemini 3.5 Flash-Lite, con Guard che esaminava prima ogni pagina. Guard ha bloccato il 94,5% delle iniezioni originali e ha quasi raddoppiato il numero medio di tentativi necessari agli attaccanti, da 9,7 a 17,0. Con tutti i 64 tentativi a disposizione, tuttavia, l’attaccante è comunque riuscito nell’84,2% delle attività (93,6% senza Guard), quasi sempre con un’iniezione che Guard non aveva segnalato. Ciò conferma la posizione che avevamo espresso al lancio di BrowseSafe: nessun modello di rilevamento è una soluzione miracolosa, quindi un rilevatore deve inserirsi in una difesa a più livelli.

Espandi

Conclusione

Gli agenti browser sono spesso vulnerabili alla prompt injection indiretta, in cui attacchi nascosti in pagine comuni cercano di interferire con la capacità degli agenti di svolgere le attività degli utenti. I pericoli non fanno che crescere nel tempo, sia perché gli agenti ottengono accesso a più dati e strumenti, aumentando la posta in gioco degli attacchi, sia perché gli attaccanti possono rivedere le proprie iniezioni per renderle più efficaci.

La nostra suite BrowseSafe affronta queste minacce. Il benchmark BrowseSafe++ contiene 38.675 coppie di pagine web costruite principalmente a partire da iniezioni reali, consentendo un addestramento e una valutazione più affidabili dei rilevatori. I rilevatori BrowseSafe-Guard, addestrati su queste coppie, offrono un rilevamento estremamente accurato, rapido ed economico, rendendo possibile analizzare le pagine prima che un agente agisca su di esse. Il framework BrowseSafe-Adapt consente di testare i modelli contro iniezioni riviste, mettendo in luce vulnerabilità che potrebbero non emergere da singoli tentativi con iniezioni fisse.

Nel loro insieme, speriamo che questi strumenti rendano più facile per ricercatori e ingegneri individuare i punti deboli e migliorare le difese contro gli attacchi di prompt injection basati sul web. Stiamo inoltre valutando e migliorando costantemente le difese integrate di Comet e Computer per proteggere i nostri utenti.

Per iniziare

1. Installa l’SDK e ottieni l’accesso ai dati. L’SDK si installa da GitHub:

Il dataset è ad accesso controllato. Richiedi l’accesso una sola volta dalla sua pagina su Hugging Face, quindi accedi con hf auth login.

2. Invia i risultati alla classifica. Valuta il tuo rilevatore sulla suddivisione di test di BrowseSafe++:

In questo modo viene scritta una decisione per pagina per ogni vista elencata; elenca tutte e tre le viste testuali per ottenere una media nella classifica testuale. Accedi allo Space della classifica con il tuo account Hugging Face e carica predictions.jsonl. Lo Space restituisce F1, accuratezza, tasso di falsi positivi e le altre metriche per ogni vista e, se lo desideri, pubblica il risultato nella classifica. Ogni account (creato da almeno 60 giorni) ha diritto a un invio valutato per settimana UTC. Le pagine di test servono solo per la valutazione: non usarle per l’addestramento e non ridistribuirle. La guida all’invio descrive il formato del file e le regole di pubblicazione.

Citazione

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}