BrowseSafe++: Slik bygger vi sterkere forsvar mot promptinjeksjon i den virkelige verden

Agenter som kan surfe på nettet, for eksempel assistenten som er innebygd i Comet eller Computer, må samhandle med nettsider, lese innhold og bruke det til å utføre handlinger på vegne av brukerne sine. Dette gjør dem sårbare for indirekte promptinjeksjon, der en angriper plasserer ondsinnet tekst på en nettside. Hvis agenten følger disse instruksjonene, kan den gi et misvisende svar eller utføre en handling brukeren ikke ba om.

I desember 2025 lanserte vi BrowseSafe, en benchmark og en deteksjonsmodell for denne trusselen. Vi bygde den ved å legge syntetiske angrep inn i realistiske nettsider som agenter sannsynligvis ville støte på. Det siste året har angrepene blitt mer sofistikerte og ligner mer på vanlig sideinnhold. I stedet for å bruke avslørende fraser som «ignorer tidligere instruksjoner», etterligner de ofte innhold som agenten sannsynligvis stoler på, for eksempel en offisiell melding fra nettstedet eller en merknad om brukerens preferanser.

Motivert av disse endringene bygde vi en oppdatert benchmark, BrowseSafe++, for å måle om dagens injeksjonsdetektorer fanger opp disse angrepene, og om agenter kan motstå dem. Den inneholder 38 675 par med angrepne og rene sider, hovedsakelig bygget rundt injeksjoner samlet inn i den virkelige verden. For hver side omskriver vi det omkringliggende innholdet for å beskytte personvernet, men beholder angrepet ordrett. Hver side finnes i de fire formatene nettleseragenter leser: HTML, Markdown, tilgjengelighetstrær og skjermbilder. Vi brukte et utvalg av benchmarken til å trene BrowseSafe-Guard, et par detektorer med 0,8 milliarder parametere: en tekstdetektor og en multimodal detektor. De to Guard-detektorene identifiserer injeksjoner mer nøyaktig enn de promptede modellene vi testet, inkludert frontier-modeller. De er også raskere og billigere, og de flagger langt færre vanlige sider ved en feil.

Vi lanserer BrowseSafe++ som en åpen benchmark. Prosjektnettstedet lenker til datasettet, SDK-et, forskningsartikkelen og en offentlig ledertavle. Alle team kan teste detektoren sin mot testsider uten oppgitte etiketter og sende inn etikettene for vurdering og mulig oppføring på ledertavlen. Se Kom i gang for å evaluere og sende inn resultatene dine.

Bygging av en benchmark fra observerte injeksjoner

BrowseSafe++ er bygget fra promptinjeksjoner observert på ekte nettsteder. Mellom september 2025 og september 2026 flagget promptinjeksjonsdetektoren i Comet 1,15 millioner injeksjoner på sider som agenten leste. Vi bygde 32 187 par rundt disse injeksjonene og la til 6488 par fra den opprinnelige BrowseSafe-benchmarken, til sammen 38 675 par. Hvert par inneholder både en angrepet side og dens rene tvilling, som er den samme siden uten injeksjonen.

Hvordan injeksjoner ser ut i praksis

To eksempler fra benchmarken viser hvordan disse injeksjonene ser ut i praksis.

I det ene eksemplet oppfordrer en falsk kjøpsforespørsel agenten til å utføre en uautorisert handling. Comets detektor flagget denne blokken med engelsk tekst på en russiskspråklig side med utviklerdokumentasjon i oktober 2025:

Teksten åpner og avslutter med kommandoer og fyller midten med vanlig tokenmarkedsføring. Den hevder å komme fra agentens egen utvikler og avsluttes med en autorisasjonskode for å få kjøpet til å se godkjent ut.

I et annet eksempel har en forfalsket samtale som mål å forstyrre agentens oppgave. Denne teksten ble funnet på en side i et kodelager i mars 2026:

Teksten er laget for å se ut som en samtale mellom en bruker og en agent: <|im_start|> og <|im_end|> er markører som enkelte chatmodeller bruker for å skille replikkene i en samtale. En agent som gikk i denne fellen, ville svart på den forfalskede brukerforespørselen med angriperens frase.

Vi ser lignende mønstre på tvers av de flaggede injeksjonene:

• De etterligner pålitelige kilder. Begge eksemplene får sideteksten til å fremstå som en kilde agenten stoler på: agentens utvikler i det første og agentens egen samtale i det andre. Injeksjoner kan også utgi seg for å være selve nettstedet ved å etterligne sikkerhetskontroller og meldinger om retningslinjer, eller for å være brukeren ved å presentere falske preferanser. Omtrent to av tre er skrevet i et formelt språk.
• Mange er skrevet på andre språk. I 24,4 % av parene bruker injeksjonen et annet språk enn resten av siden. Dette har typisk form av en engelsk instruksjon på en ikke-engelsk side, som i det første eksemplet. Slike angrep er tydelig rettet mot en agent som leser alle språk og vanligvis har engelsk som morsmål. Språkskifter gjør også deteksjon vanskeligere: I vår opprinnelige BrowseSafe-evaluering var flerspråklige angrep blant de vanskeligste å fange opp.
• De fleste vil ha handlinger, ikke ord. Mer enn fire av ti presser agenten mot en handling brukeren aldri ba om, som tokenkjøpet i det første eksemplet, og omtrent en tredjedel prøver å få den til å droppe brukerens oppgave, som i det andre eksemplet. Bare omtrent 3 % prøver å plante falsk informasjon i svaret.
• De bruker ofte innhold som hvem som helst kan publisere. En angriper trenger ikke å kontrollere et nettsted. Et foruminnlegg eller et delt dokument på vanlige nettsteder er nok, og mer enn 23 000 injeksjoner i BrowseSafe++ kom inn på denne måten. Selv et pålitelig domene kan altså brukes til å injisere en angripers tekst.

Injeksjonene i den endelige benchmarken dekker 12 typer nettsteder, 24 angrepstyper, 6 angripermål og 18 plasseringer på siden.

Forstørr

Fra en flagget side til et benchmarkpar

Vi kan ikke bruke de flaggede sidene i benchmarken slik de er, fordi de kan inneholde personopplysninger om brukeren agenten jobbet for. Å gjøre en side om til et delbart benchmarkpar krever tre hovedtrinn:

1. Hent inn injeksjonen: Vi samler inn de flaggede sidene, fjerner duplikater og maskerer personopplysninger med PII-Tracer. Deretter bekrefter vi at siden inneholder en injeksjon; nærmere bestemt krever vi at et panel av modeller er enige om at den inneholder en instruksjon som prøver å lede en agent bort fra brukerens tiltenkte oppgave.
2. Bygg paret: En agent fjerner injeksjonsteksten fra hver side og omskriver det omkringliggende sideinnholdet, der detaljer som navn og merkevarer erstattes med fiktive. En annen agent kontrollerer den omskrevne siden for gjenværende innhold fra den virkelige verden og sender feil tilbake med tilbakemelding. Menneskelige kontrollører gjennomgår et tilfeldig utvalg på 10 % av sidene; problemer de finner, rettes i pipelinen, og rettelsene brukes på hele korpuset. Injeksjonen settes inn igjen på den omskrevne siden for å lage den angrepne kopien og utelates fra den rene kopien. De to sidene har samme oppgave, forventede resultat og vanlige instruksjoner.
3. Verifiser: Agenter leser sider i ulike former, så vi gjengir hver sides HTML som Markdown, et tilgjengelighetstre (en strukturert liste over en sides grensesnittelementer og etikettene deres) og et skjermbilde. En annen agent kontrollerer at injeksjonen vises i alle fire visningene av den angrepne siden, og at den rene siden vurderes som harmløs i alle visninger. Hvis injeksjonen mangler i en av visningene, flytter vi den til et annet sted på siden og gjengir på nytt, slik at injeksjonen finnes i den endelige angrepne siden i alle visninger. Et siste sett med automatiserte kontroller korrigerer eventuelle par som fortsatt har spor av kilden sin, for eksempel ekte vertsnavn eller merkenavn.

Forstørr

BrowseSafe-Guard: raske og presise detektorer for alle visninger

En nyttig detektor må kontrollere hver side raskt og rimelig. Den må også være nøyaktig på både angrepne og rene sider. Høy presisjon er spesielt viktig, siden de fleste sider er trygge; selv en relativt lav falsk positiv-rate ville gjøre de fleste varsler til falske alarmer. Promptede generelle modeller kommer ofte til kort på presisjon og er for trege og kostbare til å kjøres på hver side.

En detektor som er trent på angrepne og rene sider samlet inn hver for seg, kan lære snarveier som tilfeldigvis skiller de to settene, for eksempel en sides tema eller layout. En slik detektor generaliserer imidlertid ikke godt. Guard trener i stedet på par der den eneste forskjellen er selve injeksjonen, noe som bidrar til å forbedre detektorens presisjon. For hvert par leser Guard den angrepne siden og dens rene tvilling hver for seg og gir hver av dem en poengsum for hvor sannsynlig det er at den inneholder en injeksjon. To treningsmål brukes til å oppdatere modellen: det vanlige klassifiseringsmålet og et rangeringsmål som straffer Guard med mindre den angrepne siden får en poengsum som er minst en fast margin høyere enn tvillingen. Intuitivt lærer klassifiseringsmålet Guard hvilken beslutning den skal ta, mens rangeringsmålet knytter beslutningen til selve injeksjonen og ser bort fra harmløse distraksjoner. Dette trener Guard til å reagere på selve injeksjonen i stedet for på sideinnholdet rundt.

Guard består av to detektorer, som begge er finjustert fra Qwen3.5-0.8B. Tekstdetektoren leser én tekstvisning av en side: enten HTML, Markdown eller tilgjengelighetstreet. Den multimodale detektoren leser et skjermbilde av hele siden. I produksjon leser Guard en side i én enkelt foroverpassering og gir ut en injeksjonspoengsum, og siden flagges hvis poengsummen overstiger en terskel. Siden Guard bare har 0,8 milliarder parametere og gir ut én enkelt poengsum, er den rask og billig nok til å kjøres på hver side.

Måling av ytelse

Vi sammenlignet Guard med 18 modeller som ble promptet til å oppdage injeksjoner på et tilbakeholdt utvalg av benchmarken. Vi rapporterer fire måltall, målt på BrowseSafe++:

• Gjenkalling er andelen sider med injeksjon som detektoren flagger, noe som måler hvor mange angrep den fanger opp, så høyere er bedre.
• Falsk positiv-raten (FPR) er andelen rene sider som detektoren flagger ved en feil, noe som måler hvor ofte den gir falske alarmer, så lavere er bedre.
• Presisjon er andelen flaggede sider som faktisk inneholder en injeksjon, noe som måler hvor ofte et varsel er riktig, så høyere er bedre.
• F1 er det harmoniske gjennomsnittet av gjenkalling og presisjon; verdien er bare høy når en detektor fanger opp de fleste angrep og få av flaggene er falske alarmer.

Vi bruker F1 som primært måltall, siden en god detektor bør ha høy presisjon og gjenkalling. Alle fire måltallene er gjennomsnitt over de tre tekstvisningene.

Forstørr

Forstørr

Sammenligning av modeller

De små modellene med åpne vekter som vi testet, havnet nederst. Mistral NeMo og Qwen3 30B-A3B flagger hver omtrent halvparten av de rene sidene, mens Llama 3.1 8B sjelden flagger noe og går glipp av de fleste angrepene. Selv den sterkeste modellen i gruppen, GPT-OSS 20B, når bare en F1 på 70,97 %. DeepSeek V3.1, en mye større modell med åpne vekter, gjør det litt bedre, med en F1 på 75,23 %.

Lette API-modeller, inkludert GPT-5.4 nano, Gemini 3.1 Flash-Lite og Claude Haiku 4.5, fanger opp flere angrep, med en recall på mellom 85 % og 97 %. Prisen er imidlertid en høy andel falske alarmer: Gemini 3.1 Flash-Lite har gruppens laveste FPR på 35,2 %, og Haiku har en FPR på nesten 69 %. Dermed er gruppens høyeste F1-score 80,9 %, oppnådd av Gemini 3.1 Flash-Lite.

De øvrige modellene er sterkere generelle modeller som når F1-verdier mellom 85 % og 92 %. De må likevel gjøre avveininger mellom gjenkalling og FPR; modeller som heller mot forsiktighet, blokkerer legitime sider, og modeller som flagger sjeldnere, går glipp av angrep. Claude Sonnet 5 har den høyeste gjenkallingen av alle detektorene med 98,73 %, men en FPR på 24,65 %. Gemini 3.1 Pro og GPT-5.5 når en gjenkalling på henholdsvis 97,78 % og 97,19 %, med FPR på 19,80 % og 20,44 %. GPT-6 Astra har den høyeste totale nøyaktigheten, med en gjenkalling på 96,42 % og en FPR på 14,41 %. Decider kommer på andreplass, med en gjenkalling på 96,02 % og en FPR på 17,44 %. Claude Opus 5.5 har den laveste FPR-en med bare 4,21 %, men gjenkallingen på 77,71 % betyr at den går glipp av mer enn ett av fem angrep. Claude Fable 5.1 virker sterk på sidene den svarer på, med en gjenkalling på 89,31 % og en FPR på 7,92 %, men den nekter å svare på omtrent 30 % av sidene, som raden «(all)» teller som flagg.

Forstørr

Guard flytter Pareto-fronten og oppnår en bedre avveining mellom angrep som ikke oppdages, og falske alarmer. Den når en F1 på omtrent 95 % og rangeres først i alle tekstvisninger. Den flagger bare omtrent én av 20 rene sider, omtrent en tredjedel av raten til Astra, den mest nøyaktige promptede modellen. Denne forskjellen kommer fra treningen vår; standardversjonen av Qwen3.5-0.8B som Guard er bygget på, promptet på samme måte som de andre modellene, når bare en F1 på 64 % og flagger nesten tre av fire rene sider. I skjermbildevisningen sammenligner vi Guards multimodale detektor med fire modeller som kan behandle bilder. Med helsideskjermbilder oppnår Guard omtrent 93 % F1, mot omtrent 79 % for den beste av de andre modellene vi evaluerte.

Å gjenkjenne et angrep er ikke det samme som å motstå det

Intuitivt burde en modell som kan identifisere en injeksjon riktig, også ignorere denne injeksjonen når den støter på siden mens den utfører brukeroppgaver. Eksperimentene våre viser imidlertid at gode deteksjonsresultater ikke garanterer at en modell vil motstå et angrep. Vi ga hver modell den samme angrepne siden to ganger, én gang for å vurdere om den inneholdt en injeksjon, og én gang for å utføre brukerens oppgave uten å se den forrige vurderingen. En separat dommer kontrollerte om den fulgte injeksjonen. Alle modellene som ble testet, fulgte fortsatt noen injeksjoner de hadde flagget, fra 1,64 % av de flaggede sidene for GPT-6 Astra til 24,73 % for Llama 3.1 8B.

Forstørr

Deteksjonsresultater forutsier ikke på en pålitelig måte forskjellene mellom modellene. Claude Sonnet 5 og GPT-5.5 oppdager injeksjoner omtrent like godt, med F1-verdier på henholdsvis omtrent 88 % og 89 %. Likevel fulgte Sonnet 5 en injeksjon den hadde flagget, på 19,74 % av sidene, ti ganger så ofte som GPT-5.5 med 1,97 %.

Et driftsklart system for forsvar mot injeksjoner

Disse resultatene tyder på at det er verdifullt å overlate beslutningen om å blokkere en side til en spesialisert modell, i stedet for å stole på modellen som utfører brukerens oppgave. En separat detektor som screener hver side før agenten handler, gir et ekstra forsvarslag og har ingen oppgave som kan kapres, eller verktøy som kan misbrukes.

Guard er laget for å være nettopp en slik detektor. I tillegg til at den har høyest F1 og nøyaktighet av alle modellene vi testet, gjør den lille størrelsen at den er billig nok til å kjøres på hver side. I gjennomsnitt brukte Guard omtrent 0,15 sekunder GPU-tid per tekstside. På en leid H200 anslår vi en kostnad på 0,18 USD per 1 000 sider, sammenlignet med 18,95–180,61 USD for de ledende API-modellene til listepris. I vår sammenligning gjør dette hyppig screening mye billigere, samtidig som deteksjonsresultatene forblir høye.

Figuren nedenfor viser hver detektors nøyaktighet mot tidsbruken per side og kostnaden per 1000 sider, begge på logaritmiske skalaer. Guard står alene i øvre venstre hjørne i begge panelene: Den vinner på nøyaktighet, hastighet og kostnad. Alle de promptede modellene bruker omtrent ett sekund eller mer per side, og de to mest nøyaktige, GPT-6 Astra og Claude Fable 5.1, koster over 100 dollar per 1000 sider.

Forstørr

Testing av forsvar mot adaptive angrep

BrowseSafe++-benchmarken har et begrenset sett med injeksjoner. En reell angriper kan imidlertid gjennomføre et adaptivt angrep; når en injeksjon mislykkes, kan angriperen omskrive den og prøve igjen. Dermed kan en agent som motstår den opprinnelige injeksjonen, likevel være sårbar for fremtidige angrep. Dessuten trenes modeller på data samlet inn fra internett, så de kan lære å motstå de fleste av benchmarkens injeksjoner; siden vi publiserer benchmarken offentlig, vil den sannsynligvis bli mettet og ikke lenger skille godt mellom modeller. For å løse begge problemene bygde vi BrowseSafe-Adapt, et testmiljø der en angripermodell kan omskrive injeksjoner. Hver test har tre trinn:

1. Sett opp testtilfellet. Et testtilfelle kobler en BrowseSafe++-oppføring sammen med en målagent. BrowseSafe++-oppføringen inneholder et scenario med en brukerforespørsel og en oppgave, en angrepet side og angriperens ønskede utfall. Agenten arbeider i en sandbox som gir verktøyene og de syntetiske dataene som kreves for å utføre oppgaven. En separat verifiseringsmodell vurderer om angrepet nådde målet sitt.
2. Kjør et forsøk: Vi setter inn den gjeldende injeksjonen på siden og lar agenten utføre oppgaven. Verifikatoren kontrollerer agentens svar og eventuelle endringer den har gjort i sandboxen, for å avgjøre om angrepet lyktes. Det første forsøket bruker injeksjonen fra den opprinnelige BrowseSafe++-oppføringen.
3. Revider og gjenta: Hvis et angrep mislykkes, arkiverer vi forsøket, og en kritikermodell gjennomgår hva som gikk galt. En angripermodell bruker denne tilbakemeldingen til å omskrive injeksjonen; den kan endre angrepets ordlyd, formatering eller plassering på siden. Angrepsmålet, suksesskriteriene og det omkringliggende sideinnholdet forblir uendret. Neste forsøk bruker det oppdaterte angrepet. Denne prosessen gjentas til angrepet lykkes eller angriperen når en fastsatt forsøksgrense.

Forstørr

Vi testet sju agenter, hver bygget på en ulik modell: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite og modellene med åpne vekter DeepSeek V3.1 og Kimi K2. Hver agent fikk de samme 1024 oppgavene, med opptil 64 forsøk per oppgave. På første forsøk var angrepssuksessen lav for alle sju agentene. De opprinnelige injeksjonene lyktes på høyst 4 % av de evaluerte oppgavene, uansett agent. Med det adaptive rammeverket økte angrepssuksessen dramatisk. Angriperen lyktes på minst 79 % av oppgavene mot fem av de sju agentene. Selv de sterkeste agentene var sårbare: Angrepene lyktes fortsatt på omtrent to av tre oppgaver mot GPT-5.5 og omtrent én av tre mot Claude Sonnet 5.

Forskjellen mellom agentene er størst når angriperens mål er å få agenten til å utføre et bestemt verktøykall. For oppgaver med denne typen mål ga Sonnet 5 etter på omtrent 8 % av oppgavene og GPT-5.5 på omtrent 29 %. De fem andre utførte angriperens mål på mer enn halvparten av oppgavene sine.

Vi kjørte også BrowseSafe-Adapt mot Gemini 3.5 Flash-Lite-agenten, der Guard først screenet hver side. Guard blokkerte 94,5 % av de opprinnelige injeksjonene og nesten doblet det gjennomsnittlige antallet forsøk angriperne trengte, fra 9,7 til 17,0. Med alle 64 forsøk lyktes angriperen likevel på 84,2 % av oppgavene (93,6 % uten Guard), nesten alltid med en injeksjon som Guard ikke flagget. Dette samsvarer med synet vi la frem da vi lanserte BrowseSafe: Ingen deteksjonsmodell er en mirakelkur, så en detektor må inngå i et forsvar i flere lag.

Forstørr

Konklusjon

Nettleseragenter er ofte sårbare for indirekte promptinjeksjon, der angrep skjult på vanlige sider forsøker å forstyrre agentenes evne til å utføre brukeroppgaver. Farene blir bare større over tid, både fordi agenter får tilgang til flere data og verktøy, noe som øker hva som står på spill ved angrep, og fordi angripere kan revidere injeksjonene sine for å gjøre dem mer effektive.

BrowseSafe-pakken vår tar tak i disse truslene. BrowseSafe++-benchmarken inneholder 38 675 nettsidepar bygget hovedsakelig fra reelle injeksjoner, noe som gir mer pålitelig trening og evaluering av detektorer. BrowseSafe-Guard-detektorene, som er trent på disse parene, gir svært nøyaktig, rask og rimelig deteksjon, slik at det blir mulig å skanne sider før en agent handler ut fra dem. BrowseSafe-Adapt-rammeverket gjør det mulig å teste modeller mot reviderte injeksjoner og avdekker sårbarheter som kanskje ikke er synlige ved enkeltforsøk med faste injeksjoner.

Vi håper at disse verktøyene sammen gjør det enklere for forskere og ingeniører å finne svakheter og forbedre forsvaret mot nettbaserte promptinjeksjonsangrep. Vi evaluerer og forbedrer også kontinuerlig de innebygde forsvarsmekanismene i Comet og Computer for å holde brukerne våre trygge.

Kom i gang

1. Installer SDK-et og få tilgang til dataene. SDK-et installeres fra GitHub:

Datasettet har begrenset tilgang. Be om tilgang én gang på datasettets Hugging Face-side, og logg deretter inn med hf auth login.

2. Send inn til ledertavlen. Evaluer din egen detektor på testsettet i BrowseSafe++:

Dette skriver én beslutning per side for hver visning du angir; angi alle tre tekstvisningene for å få et gjennomsnitt på tekstlederlisten. Logg inn på lederlistens Space med Hugging Face-kontoen din, og last opp predictions.jsonl. Denne Spacen returnerer F1, nøyaktighet, andel falske positiver og de andre måltallene for hver visning, og publiserer resultatet på lederlisten hvis du ønsker det. Hver konto (minst 60 dager gammel) får én poengsatt innsending per UTC-uke. Testsidene er kun til evaluering: Ikke tren på dem, og ikke distribuer dem videre. Veiledningen for innsending beskriver filformatet og publiseringsreglene.

Sitering

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