BrowseSafe++: Starkare försvar mot verkliga promptinjektioner

Agenter som kan surfa på webben, till exempel assistenten som är inbyggd i Comet eller Computer, behöver interagera med webbsidor, läsa innehåll och använda det för att utföra åtgärder åt sina användare. Det gör dem sårbara för indirekt promptinjektion, där en angripare placerar skadlig text på en webbsida. Om agenten följer dessa instruktioner kan den ge ett vilseledande svar eller utföra en åtgärd som användaren inte har bett om.

I december 2025 släppte vi BrowseSafe, ett benchmark och en detektionsmodell för detta hot. Vi byggde det genom att lägga till syntetiska attacker i realistiska webbsidor som agenter sannolikt skulle stöta på. Under det senaste året har attackerna blivit mer sofistikerade och liknar allt mer vanligt sidinnehåll. I stället för att använda avslöjande fraser som ”ignorera tidigare instruktioner” imiterar de ofta innehåll som agenten sannolikt litar på, till exempel ett officiellt meddelande från webbplatsen eller en anteckning om användarens preferenser.

Mot bakgrund av dessa förändringar byggde vi en uppdaterad benchmark, BrowseSafe++, för att mäta om dagens injektionsdetektorer fångar dessa attacker och om agenter kan stå emot dem. Den innehåller 38 675 par av attackerade och rena sidor, främst byggda kring injektioner som samlats in i verkligheten. För varje sida skriver vi om det omgivande innehållet för att skydda integriteten men behåller attacken ordagrant. Varje sida finns i de fyra format som webbläsaragenter läser: HTML, Markdown, tillgänglighetsträd och skärmbilder. Vi använde en delmängd av benchmarken för att träna BrowseSafe-Guard, ett par detektorer med 0,8 miljarder parametrar: en textdetektor och en multimodal detektor. De två Guard-detektorerna identifierar injektioner mer exakt än de promptade modeller vi testade, inklusive frontiermodeller. De är också snabbare, billigare och flaggar betydligt färre vanliga sidor av misstag.

Vi släpper BrowseSafe++ som en öppen benchmark. Projektets webbplats länkar till datasetet, SDK:n, forskningsartikeln och en offentlig topplista. Alla team kan poängsätta sin detektor mot testsidor vars etiketter inte tillhandahålls och skicka in etiketterna för bedömning och eventuell inkludering på topplistan. Se Kom igång för att utvärdera och skicka in dina resultat.

Att bygga en benchmark av observerade injektioner

BrowseSafe++ bygger på promptinjektioner som observerats på verkliga webbplatser. Mellan september 2025 och september 2026 flaggade promptinjektionsdetektorn i Comet 1,15 miljoner injektioner på sidor som dess agent läste. Vi byggde 32 187 par kring dessa injektioner och lade till 6 488 par från den ursprungliga BrowseSafe-benchmarken, totalt 38 675 par. Varje par innehåller både en attackerad sida och dess rena tvilling, alltså samma sida utan injektionen.

Hur injektioner ser ut i verkligheten

Två exempel från benchmarken visar hur dessa injektioner ser ut i praktiken.

I det ena uppmanar en falsk köpbegäran agenten att utföra en obehörig åtgärd. Detektorn i Comet flaggade detta stycke engelsk text på en ryskspråkig sida med utvecklardokumentation i oktober 2025:

Texten inleds och avslutas med kommandon och fyller mitten med vanlig tokenmarknadsföring. Den påstår sig komma från agentens egen utvecklare och avslutas med en auktoriseringskod för att få köpet att se godkänt ut.

I ett annat exempel syftar en förfalskad konversation till att störa agentens uppgift. Den här texten hittades på en sida i ett kodrepo i mars 2026:

Texten är utformad för att se ut som en konversation mellan en användare och en agent: <|im_start|> och <|im_end|> är markörer som vissa chattmodeller använder för att skilja turerna i en konversation åt. En agent som gick på den här attacken skulle reagera på den förfalskade användarförfrågan och svara med angriparens fras.

Vi ser liknande mönster bland de flaggade injektionerna:

• De efterliknar betrodda källor. Båda exemplen får sidtexten att låta som en källa som agenten litar på: dess utvecklare i det första, dess egen konversation i det andra. Injektioner kan också utge sig för att vara själva webbplatsen genom att imitera säkerhetskontroller och policymeddelanden, eller för att vara användaren genom att framföra falska preferenser. Ungefär två av tre är skrivna på formellt språk.
• Många är skrivna på andra språk. I 24,4 % av paren använder injektionen ett annat språk än resten av sidan. Det handlar oftast om en engelsk instruktion på en icke-engelsk sida, som i det första exemplet. Sådana attacker riktar sig tydligt till en agent som läser alla språk och vanligtvis har engelska som modersmål. Språkbyten gör också detekteringen svårare: i vår ursprungliga utvärdering av BrowseSafe var flerspråkiga attacker bland de svåraste att fånga.
• De flesta vill ha handling, inte ord. Mer än fyra av tio driver agenten mot en åtgärd som användaren aldrig bad om, som tokenköpet i det första exemplet, och ungefär en tredjedel försöker få den att överge användarens uppgift, som i det andra exemplet. Bara cirka 3 % försöker plantera falsk information i svaret.
• De åker ofta snålskjuts på innehåll som vem som helst kan publicera. En angripare behöver inte kontrollera en webbplats. Ett foruminlägg eller ett delat dokument på vanliga webbplatser räcker, och mer än 23 000 injektioner i BrowseSafe++ kom den vägen. En betrodd domän kan ändå utnyttjas för att injicera en angripares text.

Injektionerna i den slutliga benchmarken omfattar 12 typer av webbplatser, 24 attacktyper, 6 angriparmål och 18 placeringar på sidan.

Förstora

Från en flaggad sida till ett benchmarkpar

Vi kan inte använda flaggade sidor som de är i benchmarken, eftersom de kan innehålla personuppgifter om användaren som agenten arbetade åt. Att göra om en sida till ett delbart benchmarkpar kräver tre huvudsteg:

1. Hämta injektionen: Vi samlar in de flaggade sidorna, tar bort dubbletter och maskerar personuppgifter med PII-Tracer. Sedan bekräftar vi att sidan innehåller en injektion; mer specifikt kräver vi att en panel av modeller är överens om att den innehåller en instruktion som försöker leda bort en agent från användarens avsedda uppgift.
2. Bygg paret: En agent tar bort injektionstexten från varje sida och skriver om det omgivande sidinnehållet, där detaljer som namn och varumärken ersätts med fiktiva. En andra agent kontrollerar den omskrivna sidan efter kvarvarande verkligt innehåll och skickar tillbaka underkända sidor med återkoppling. Mänskliga granskare inspekterar slumpmässigt utvalda 10 % av sidorna; problem de hittar åtgärdas i pipelinen, och korrigeringarna tillämpas på hela korpusen. Injektionen infogas på nytt i den omskrivna sidan för att skapa den attackerade kopian och utelämnas från den rena kopian. De två sidorna har samma uppgift, förväntade resultat och vanliga instruktioner.
3. Verifiera: Agenter läser sidor i olika former, så vi renderar varje sidas HTML som Markdown, ett tillgänglighetsträd (en strukturerad lista över en sidas gränssnittselement och deras etiketter) och en skärmbild. En annan agent kontrollerar att injektionen förekommer i alla fyra vyer av den attackerade sidan och att den rena sidan bedöms som ofarlig i varje vy. Om injektionen saknas i någon av vyerna flyttar vi den till en annan plats på sidan och renderar igen, så att injektionen finns med på den slutliga attackerade sidan i alla vyer. En sista uppsättning automatiska kontroller korrigerar alla par som fortfarande bär spår av sin källa, till exempel verkliga värdnamn eller varumärkesnamn.

Förstora

BrowseSafe-Guard: snabba och precisa detektorer för alla vyer

En användbar detektor måste kontrollera varje sida snabbt och billigt. Den måste också vara noggrann på både attackerade och rena sidor. Hög precision är särskilt viktigt, eftersom de flesta sidor är säkra; även en relativt låg andel falska positiva skulle göra de flesta varningar till falsklarm. Promptade allmänna modeller brister ofta i precision och är för långsamma och dyra för att köras på varje sida.

En detektor som tränats på attackerade och rena sidor som samlats in separat kan lära sig genvägar som råkar skilja de två mängderna åt, till exempel en sidas ämne eller layout. En sådan detektor generaliserar dock inte särskilt bra. Guard tränar i stället på par där den enda skillnaden är själva injektionen, vilket bidrar till att förbättra detektorns precision. För varje par läser Guard den attackerade sidan och dess rena tvilling separat och ger var och en ett värde för hur sannolikt det är att den innehåller en injektion. Två träningsmål används för att uppdatera modellen: det vanliga klassificeringsmålet och ett rankningsmål som bestraffar Guard om inte den attackerade sidan får ett högre värde än sin tvilling med minst en fast marginal. Intuitivt lär klassificeringsmålet Guard vilket beslut som ska fattas, medan rankningsmålet knyter beslutet till själva injektionen och bortser från ofarliga distraktorer. Detta tränar Guard att reagera på själva injektionen snarare än på det omgivande sidinnehållet.

Guard består av två detektorer, var och en finjusterad från Qwen3.5-0.8B. Textdetektorn läser en textvy av en sida: antingen HTML, Markdown eller tillgänglighetsträd. Den multimodala detektorn läser en skärmbild av hela sidan. I drift läser Guard en sida i ett enda framåtpass och returnerar ett injektionsvärde, och sidan flaggas om värdet överskrider ett tröskelvärde. Eftersom Guard bara har 0,8 miljarder parametrar och returnerar ett enda värde är den tillräckligt snabb och billig för att köras på varje sida.

Prestandamätning

Vi jämförde Guard med 18 modeller som promptades att upptäcka injektioner på en undanhållen delmängd av benchmarken. Vi rapporterar fyra mått, uppmätta på BrowseSafe++:

• Recall är andelen sidor med injektioner som detektorn flaggar. Den mäter hur många attacker den fångar, så högre är bättre.
• Andelen falska positiva (FPR) är andelen rena sidor som detektorn flaggar av misstag. Den mäter hur ofta den ger falsklarm, så lägre är bättre.
• Precision är andelen flaggade sidor som verkligen innehåller en injektion. Den mäter hur ofta en varning är korrekt, så högre är bättre.
• F1 är det harmoniska medelvärdet av recall och precision; det är bara högt när en detektor fångar de flesta attacker och få av dess flaggningar är falsklarm.

Vi använder F1 som primärt mått, eftersom en bra detektor bör ha både hög precision och hög recall. Alla fyra måtten är medelvärden över de tre textvyerna.

Förstora

Förstora

Modelljämförelser

De små modellerna med öppna vikter som vi testade hamnade längst ned. Mistral NeMo och Qwen3 30B-A3B flaggar vardera ungefär hälften av de rena sidorna, medan Llama 3.1 8B sällan flaggar något och missar de flesta attacker. Även den starkaste modellen i gruppen, GPT-OSS 20B, når bara ett F1-värde på 70,97 %. DeepSeek V3.1, en betydligt större modell med öppna vikter, klarar sig något bättre, med ett F1-värde på 75,23 %.

Lätta API-modeller som GPT-5.4 nano, Gemini 3.1 Flash-Lite och Claude Haiku 4.5 fångar fler attacker, med en recall på mellan 85 % och 97 %. Priset är dock en hög andel falsklarm; Gemini 3.1 Flash-Lite har gruppens lägsta FPR på 35,2 %, och Haikus FPR är nästan 69 %. Därför är gruppens högsta F1-värde 80,9 %, vilket uppnås av Gemini 3.1 Flash-Lite.

De återstående modellerna är starkare allmänna modeller och når F1-värden mellan 85 % och 92 %. De står dock fortfarande inför avvägningar mellan recall och FPR: modeller som lutar åt försiktighet blockerar legitima sidor, och modeller som flaggar mer sällan missar attacker. Claude Sonnet 5 har högst recall av alla detektorer, 98,73 %, men en FPR på 24,65 %. Gemini 3.1 Pro och GPT-5.5 når en recall på 97,78 % respektive 97,19 %, med en FPR på 19,80 % respektive 20,44 %. GPT-6 Astra har högst total noggrannhet, med en recall på 96,42 % och en FPR på 14,41 %. Decider kommer tvåa, med en recall på 96,02 % och en FPR på 17,44 %. Claude Opus 5.5 har lägst FPR, endast 4,21 %, men dess recall på 77,71 % innebär att den missar mer än en av fem attacker. Claude Fable 5.1 ser stark ut på de sidor den svarar på, med en recall på 89,31 % och en FPR på 7,92 %, men den vägrar svara på cirka 30 % av sidorna, vilket raden ”(all)” räknar som flaggningar.

Förstora

Guard flyttar fram Paretofronten och uppnår en bättre avvägning mellan missade attacker och falsklarm. Den når ett F1-värde på cirka 95 % och rankas först i varje textvy. Den flaggar bara ungefär en av 20 rena sidor, ungefär en tredjedel av andelen för Astra, den mest noggranna promptade modellen. Skillnaden kommer från vår träning: den oförändrade Qwen3.5-0.8B som Guard bygger på, promptad på samma sätt som de andra modellerna, når bara ett F1-värde på 64 % och flaggar nästan tre av fyra rena sidor. I skärmbildsvyn jämför vi Guards multimodala detektor med fyra modeller som kan hantera bilder. Med helsidesskärmbilder når Guard cirka 93 % i F1, mot cirka 79 % för den bästa av de andra modellerna vi utvärderade.

Att känna igen en attack är inte detsamma som att stå emot den

Intuitivt borde en modell som korrekt kan identifiera en injektion också ignorera den injektionen när den stöter på sidan under arbetet med användarens uppgifter. Våra experiment visar dock att höga detekteringsresultat inte garanterar att en modell står emot en attack. Vi gav varje modell samma attackerade sida två gånger, en gång för att bedöma om den innehöll en injektion och en gång för att utföra användarens uppgift utan att se den tidigare bedömningen. En separat bedömare kontrollerade om modellen följde injektionen. Varje testad modell följde fortfarande vissa injektioner som den hade flaggat, från 1,64 % av de flaggade sidorna för GPT-6 Astra till 24,73 % för Llama 3.1 8B.

Förstora

Detekteringsresultat förutsäger inte på ett tillförlitligt sätt skillnader mellan modeller. Claude Sonnet 5 och GPT-5.5 upptäcker injektioner ungefär lika bra, med F1-värden på cirka 88 % respektive 89 %. Ändå följde Sonnet 5 en injektion som den hade flaggat på 19,74 % av sidorna, tio gånger så ofta som GPT-5.5 med 1,97 %.

Ett driftsättningsbart system för försvar mot injektioner

Resultaten tyder på att det finns ett värde i att delegera beslutet att blockera en sida till en specialiserad modell, i stället för att förlita sig på modellen som utför användarens uppgift. En separat detektor som granskar varje sida innan agenten agerar ger ett extra försvarslager och har varken någon uppgift att kapa eller några verktyg att missbruka.

Guard är byggd för att vara den detektorn. Utöver att Guard har högst F1 och noggrannhet av alla modeller vi testade gör dess ringa storlek den tillräckligt billig för att köras på varje sida. I genomsnitt använde Guard cirka 0,15 sekunder GPU-tid per textsida. På en hyrd H200 uppskattar vi kostnaden till 0,18 USD per 1 000 sidor, jämfört med 18,95–180,61 USD för de ledande API-modellerna till listpris. Det gör frekvent screening mycket billigare i vår jämförelse samtidigt som höga detektionsvärden bibehålls.

Figuren nedan visar varje detektors noggrannhet mot dess tid per sida och dess kostnad per 1 000 sidor, båda på logaritmiska skalor. Guard ligger ensam i det övre vänstra hörnet i båda panelerna: den vinner på noggrannhet, hastighet och kostnad. Varje promptad modell tar ungefär en sekund eller mer per sida, och de två mest noggranna, GPT-6 Astra och Claude Fable 5.1, kostar över 100 dollar per 1 000 sidor.

Förstora

Testa försvar mot adaptiva attacker

BrowseSafe++-benchmarken har en begränsad uppsättning injektioner. En verklig angripare kan dock genomföra en adaptiv attack: när en injektion misslyckas kan angriparen skriva om den och försöka igen. En agent som står emot den ursprungliga injektionen kan därför ändå vara sårbar för framtida attacker. Dessutom tränas modeller på data som samlats in från internet, så de kan lära sig att stå emot de flesta av benchmarkens injektioner; eftersom vi publicerar vår benchmark offentligt kommer den sannolikt att mättas och sluta skilja väl mellan modeller. För att lösa båda problemen byggde vi BrowseSafe-Adapt, en testmiljö där en angriparmodell kan skriva om injektioner. Varje test har tre steg:

1. Konfigurera fallet. Ett fall kopplar ihop en post i BrowseSafe++ med en målagent. Posten i BrowseSafe++ innehåller ett scenario med en användarfråga och en uppgift, en attackerad sida och angriparens önskade utfall. Agenten arbetar i en sandlåda som tillhandahåller de verktyg och syntetiska data som krävs för att utföra uppgiften. En separat verifieringsmodell bedömer om attacken uppnådde sitt mål.
2. Kör ett försök: Vi infogar den aktuella injektionen på sidan och låter agenten utföra uppgiften. Verifieraren kontrollerar agentens svar och alla ändringar den har gjort i sandlådan för att avgöra om attacken lyckades. Det första försöket använder injektionen från den ursprungliga posten i BrowseSafe++.
3. Revidera och upprepa: Om en attack misslyckas arkiverar vi försöket, och en kritikermodell granskar vad som gick fel. En angriparmodell använder den återkopplingen för att skriva om injektionen; den kan ändra attackens formulering, formatering eller position på sidan. Attackmålet, framgångskriterierna och det omgivande sidinnehållet förblir desamma. Nästa försök använder den uppdaterade attacken. Processen upprepas tills attacken lyckas eller angriparen når en fastställd gräns för antal försök.

Förstora

Vi testade sju agenter, var och en byggd på en annan modell: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite samt modellerna med öppna vikter DeepSeek V3.1 och Kimi K2. Varje agent ställdes inför samma 1 024 uppgifter, med upp till 64 försök per uppgift. Vid första försöket var attackernas framgång låg för alla sju agenter. De ursprungliga injektionerna lyckades på högst 4 % av de utvärderade uppgifterna, oavsett agent. Med det adaptiva ramverket ökade attackernas framgång dramatiskt. Angriparen lyckades på minst 79 % av uppgifterna mot fem av de sju agenterna. Även de starkaste agenterna var sårbara: attackerna lyckades fortfarande på ungefär två av tre uppgifter mot GPT-5.5 och ungefär en av tre mot Claude Sonnet 5.

Skillnaden mellan agenterna är störst när angriparens mål är att få agenten att göra ett visst verktygsanrop. För uppgifter med den här typen av mål gav Sonnet 5 vika på ungefär 8 % av uppgifterna och GPT-5.5 på ungefär 29 %. De övriga fem genomförde angriparens mål på mer än hälften av sina uppgifter.

Vi körde också BrowseSafe-Adapt mot Gemini 3.5 Flash-Lite-agenten, där Guard först granskade varje sida. Guard blockerade 94,5 % av de ursprungliga injektionerna och nästan fördubblade det genomsnittliga antalet försök som angriparna behövde, från 9,7 till 17,0. Med alla 64 försök lyckades angriparen ändå på 84,2 % av uppgifterna (93,6 % utan Guard), nästan alltid med en injektion som Guard inte flaggade. Detta stämmer med den syn vi presenterade när vi lanserade BrowseSafe: ingen detekteringsmodell är en universallösning, så en detektor måste ingå i ett försvar i flera lager.

Förstora

Slutsats

Webbläsaragenter är ofta sårbara för indirekt promptinjektion, där attacker som döljs på vanliga sidor försöker störa agenternas förmåga att utföra användarnas uppgifter. Riskerna ökar bara med tiden, både i takt med att agenter får tillgång till mer data och fler verktyg, vilket höjer insatserna vid attacker, och i takt med att angripare kan revidera sina injektioner för att göra dem mer effektiva.

Vår BrowseSafe-svit hanterar dessa hot. BrowseSafe++-benchmarken innehåller 38 675 webbsidespar som främst bygger på verkliga injektioner, vilket möjliggör mer tillförlitlig träning och utvärdering av detektorer. BrowseSafe-Guard-detektorerna, som tränats på dessa par, ger mycket noggrann, snabb och billig detektering, vilket gör det möjligt att skanna sidor innan en agent agerar på dem. BrowseSafe-Adapt-ramverket gör det möjligt att testa modeller mot reviderade injektioner och lyfter fram sårbarheter som kanske inte syns vid enstaka försök med fasta injektioner.

Vi hoppas att dessa verktyg tillsammans gör det enklare för forskare och ingenjörer att hitta brister och förbättra försvaren mot webbaserade promptinjektionsattacker. Vi utvärderar och förbättrar också kontinuerligt de inbyggda försvaren i Comet och Computer för att skydda våra användare.

Kom igång

1. Installera SDK:n och få åtkomst till data. SDK:n installeras från GitHub:

Datasetet har begränsad åtkomst. Begär åtkomst en gång på dess Hugging Face-sida och logga sedan in med hf auth login.

2. Skicka in till topplistan. Utvärdera din egen detektor på testdelen av BrowseSafe++:

Detta skriver ett beslut per sida för varje vy du anger; ange alla tre textvyerna för att få ett genomsnitt på topplistan för text. Logga in på topplistans Space med ditt Hugging Face-konto och ladda upp predictions.jsonl. Där returneras F1, noggrannhet, andel falskt positiva och övriga mått för varje vy, och om du vill publiceras resultatet på topplistan. Varje konto (minst 60 dagar gammalt) får en poängsatt inlämning per UTC-vecka. Testsidorna är endast avsedda för utvärdering: träna inte på dem och distribuera dem inte vidare. Inlämningsguiden beskriver filformatet och reglerna för publicering.

Citering

@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}
}