BrowseSafe++: Vi bygger stærkere forsvar mod promptinjektioner i den virkelige verden

Agenter, der kan browse på nettet, såsom assistenten, der er indbygget i Comet eller Computer, skal interagere med websider, læse indhold og bruge det til at udføre handlinger på vegne af deres brugere. Det gør dem sårbare over for indirekte promptinjektion, hvor en angriber placerer ondsindet tekst på en webside. Hvis agenten følger disse instruktioner, kan den returnere et vildledende svar eller udføre en handling, som brugeren ikke har bedt om.

I december 2025 lancerede vi BrowseSafe, et benchmark og en detektionsmodel til denne trussel. Vi byggede det ved at tilføje syntetiske angreb til realistiske websider, som agenter sandsynligvis ville støde på. I løbet af det seneste år er angrebene blevet mere sofistikerede og ligner i højere grad almindeligt sideindhold. I stedet for at bruge afslørende vendinger som »ignorer tidligere instruktioner« efterligner de ofte indhold, som agenten sandsynligvis har tillid til, såsom en officiel meddelelse fra webstedet eller en note om brugerens præferencer.

Motiveret af disse ændringer byggede vi et opdateret benchmark, BrowseSafe++, for at måle, om de nuværende injektionsdetektorer fanger disse angreb, og om agenter kan modstå dem. Det indeholder 38.675 par af angrebne og rene sider, primært bygget op omkring injektioner indsamlet i den virkelige verden. For hver side omskriver vi det omgivende indhold for at beskytte privatlivet, men bevarer angrebet ordret. Hver side findes i de fire formater, som browseragenter læser: HTML, Markdown, tilgængelighedstræer og skærmbilleder. Vi brugte en delmængde af benchmarket til at træne BrowseSafe-Guard, et par detektorer med 0,8 mia. parametre: en tekstdetektor og en multimodal detektor. De to Guard-detektorer identificerer injektioner mere nøjagtigt end de promptede modeller, vi testede, herunder frontiermodeller. De er også hurtigere og billigere og markerer langt færre almindelige sider ved en fejl.

Vi frigiver BrowseSafe++ som et åbent benchmark. Projektets website linker til datasættet, SDK'et, forskningsartiklen og en offentlig rangliste. Alle teams kan score deres detektor på testsider, hvis etiketter ikke er oplyst, og indsende etiketterne til bedømmelse og mulig optagelse på ranglisten. Du kan evaluere og indsende dine resultater ved at følge Kom godt i gang.

Opbygning af et benchmark ud fra observerede injektioner

BrowseSafe++ er bygget ud fra promptinjektioner observeret på rigtige websites. Mellem september 2025 og september 2026 markerede Comets promptinjektionsdetektor 1,15 millioner injektioner på sider, som dens agent læste. Vi byggede 32.187 par omkring disse injektioner og tilføjede 6.488 par fra det oprindelige BrowseSafe-benchmark, i alt 38.675 par. Hvert par indeholder både en angrebet side og dens rene tvilling, som er den samme side uden injektionen.

Sådan ser injektioner ud i den virkelige verden

To eksempler fra benchmarket viser, hvordan disse injektioner ser ud i praksis.

I det ene eksempel tilskynder en falsk købsanmodning agenten til at udføre en uautoriseret handling. Comets detektor markerede denne blok engelsk tekst på en russisksproget side med udviklerdokumentation i oktober 2025:

Teksten starter og slutter med kommandoer og fylder midten ud med almindelig markedsføring af tokens. Den hævder at komme fra agentens egen udvikler og slutter med en autorisationskode for at få købet til at se godkendt ud.

I et andet eksempel forsøger en forfalsket samtale at forstyrre agentens opgave. Denne tekst blev fundet på en side i et kodelager i marts 2026:

Teksten er designet til at ligne en samtale mellem en bruger og en agent: <|im_start|> og <|im_end|> er markører, som nogle chatmodeller bruger til at adskille turene i en samtale. En agent, der faldt for dette angreb, ville besvare den forfalskede brugerforespørgsel og svare med angriberens sætning.

Vi ser lignende mønstre på tværs af de markerede injektioner:

• De efterligner betroede kilder. Begge eksempler får sideteksten til at lyde som en kilde, agenten har tillid til: dens udvikler i det første og dens egen samtale i det andet. Injektioner kan også udgive sig for at være selve webstedet ved at efterligne sikkerhedstjek og politikmeddelelser eller for at være brugeren ved at fremsætte falske præferencer. Omkring to ud af tre er skrevet i et formelt sprog.
• Mange er skrevet på andre sprog. I 24,4 % af parrene bruger injektionen et andet sprog end resten af siden. Det sker typisk i form af en engelsk instruktion på en ikke-engelsk side, som i det første eksempel. Sådanne angreb er tydeligvis rettet mod en agent, der læser alle sprog og som regel har engelsk som modersmål. Sprogskift gør også detektion sværere: I vores oprindelige BrowseSafe-evaluering var flersprogede angreb blandt de sværeste at fange.
• De fleste vil have handlinger, ikke ord. Mere end fire ud af ti skubber agenten mod en handling, brugeren aldrig har bedt om, som tokenkøbet i det første eksempel, og omkring en tredjedel forsøger at få den til at opgive brugerens opgave, som i det andet eksempel. Kun omkring 3 % forsøger at plante falske oplysninger i svaret.
• De udnytter ofte indhold, som alle kan lægge op. En angriber behøver ikke at kontrollere et websted. Et forumindlæg eller et delt dokument på almindelige websteder er nok, og mere end 23.000 injektioner i BrowseSafe++ kom ind på denne måde. Selv et betroet domæne kan bruges til at injicere en angribers tekst.

Injektionerne i det endelige benchmark spænder over 12 typer websites, 24 angrebstyper, 6 angribermål og 18 placeringer på siden.

Udvid

Fra en markeret side til et benchmarkpar

Vi kan ikke bruge markerede sider i benchmarket, som de er, fordi de kan indeholde personoplysninger om den bruger, agenten arbejdede for. At omdanne en side til et benchmarkpar, der kan deles, kræver tre hovedfaser:

1. Indhent injektionen: Vi indsamler de markerede sider, fjerner dubletter og maskerer personoplysninger med PII-Tracer. Derefter bekræfter vi, at siden indeholder en injektion; konkret kræver vi, at et panel af modeller er enige om, at den indeholder en instruktion, der forsøger at lede en agent væk fra brugerens tilsigtede opgave.
2. Byg parret: En agent fjerner injektionsteksten fra hver side og omskriver det omgivende sideindhold, hvor detaljer som navne og brands erstattes med fiktive. En anden agent kontrollerer den omskrevne side for rester af indhold fra den virkelige verden og sender fejl tilbage med feedback. Menneskelige korrekturlæsere gennemgår tilfældigt udvalgte 10 % af siderne; problemer, de finder, rettes i pipelinen, og rettelserne anvendes på hele korpusset. Injektionen indsættes igen på den omskrevne side for at skabe den angrebne kopi og udelades fra den rene kopi. De to sider deler samme opgave, forventede resultat og almindelige instruktioner.
3. Verificér: Agenter læser sider i forskellige former, så vi gengiver hver sides HTML som Markdown, et tilgængelighedstræ (en struktureret liste over en sides grænsefladeelementer og deres etiketter) og et skærmbillede. En anden agent kontrollerer, at injektionen optræder i alle fire visninger af den angrebne side, og at den rene side vurderes som harmløs i alle visninger. Hvis injektionen mangler i en af visningerne, flytter vi den til et andet sted på siden og gengiver igen, så injektionen forekommer på den endelige angrebne side i alle visninger. Et sidste sæt automatiserede kontroller retter eventuelle par, der stadig bærer spor af deres kilde, såsom rigtige værtsnavne eller brandnavne.

Udvid

BrowseSafe-Guard: Hurtige og præcise detektorer til alle visninger

En brugbar detektor skal kunne kontrollere hver side hurtigt og billigt. Den skal også være nøjagtig på både angrebne og rene sider. Høj præcision er særlig vigtig, da de fleste sider er sikre; selv en relativt lav falsk-positiv-rate ville gøre de fleste alarmer til falske alarmer. Promptede generelle modeller kommer ofte til kort på præcision og er for langsomme og dyre til at køre på hver side.

En detektor, der er trænet på angrebne og rene sider indsamlet hver for sig, kan lære genveje, der tilfældigvis adskiller de to sæt, såsom en sides emne eller layout. En sådan detektor generaliserer dog ikke godt. Guard trænes i stedet på par, hvor den eneste forskel er selve injektionen, hvilket hjælper med at forbedre detektorens præcision. For hvert par læser Guard den angrebne side og dens rene tvilling hver for sig og giver hver af dem en score for, hvor sandsynligt det er, at den indeholder en injektion. Der bruges to træningsmål til at opdatere modellen: det almindelige klassifikationsmål og et rangeringsmål, der straffer Guard, medmindre den angrebne side scorer mindst en fast margin højere end sin tvilling. Intuitivt lærer klassifikationsmålet Guard, hvilken beslutning der skal træffes, mens rangeringsmålet knytter beslutningen til selve injektionen og ignorerer harmløse distraktorer. Det træner Guard i at reagere på selve injektionen frem for det omgivende sideindhold.

Guard består af to detektorer, der hver er finjusteret ud fra Qwen3.5-0.8B. Tekstdetektoren læser én tekstvisning af en side: enten HTML, Markdown eller tilgængelighedstræet. Den multimodale detektor læser et skærmbillede af hele siden. I produktion læser Guard en side i et enkelt forward pass og returnerer en injektionsscore, og siden markeres, hvis scoren overstiger en tærskelværdi. Da Guard kun har 0,8 mia. parametre og returnerer en enkelt score, er den hurtig og billig nok til at køre på hver eneste side.

Benchmarking af ydeevne

Vi sammenlignede Guard med 18 modeller, der blev promptet til at opdage injektioner, på en tilbageholdt delmængde af benchmarket. Vi rapporterer fire metrikker målt på BrowseSafe++:

• Recall er andelen af sider med injektioner, som detektoren markerer. Den måler, hvor mange angreb den fanger, så højere er bedre.
• Falsk-positiv-raten (FPR) er andelen af rene sider, som detektoren markerer ved en fejl. Den måler, hvor ofte den slår falsk alarm, så lavere er bedre.
• Præcision er andelen af markerede sider, der faktisk indeholder en injektion. Den måler, hvor ofte en alarm er korrekt, så højere er bedre.
• F1 er det harmoniske gennemsnit af recall og præcision; den er kun høj, når en detektor fanger de fleste angreb, og få af dens markeringer er falske alarmer.

Vi bruger F1 som den primære metrik, da en god detektor bør have både høj præcision og høj recall. Alle fire metrikker er gennemsnit på tværs af de tre tekstvisninger.

Udvid

Udvid

Modelsammenligninger

De små modeller med åbne vægte, vi testede, endte i bunden. Mistral NeMo og Qwen3 30B-A3B markerer hver især omkring halvdelen af de rene sider, mens Llama 3.1 8B sjældent markerer noget og overser de fleste angreb. Selv den stærkeste model i gruppen, GPT-OSS 20B, når kun en F1 på 70,97 %. DeepSeek V3.1, en meget større model med åbne vægte, klarer sig lidt bedre med en F1 på 75,23 %.

Lette API-modeller, herunder GPT-5.4 nano, Gemini 3.1 Flash-Lite og Claude Haiku 4.5, fanger flere angreb med en recall på mellem 85 % og 97 %. Prisen er dog en høj andel af falske alarmer; Gemini 3.1 Flash-Lite har gruppens laveste FPR på 35,2 %, og Haikus FPR er næsten 69 %. Som følge heraf er gruppens højeste F1-score 80,9 %, som opnås af Gemini 3.1 Flash-Lite.

De resterende modeller er stærkere generelle modeller med F1-scorer mellem 85 % og 92 %. De står dog stadig over for afvejninger mellem recall og FPR; modeller, der hælder mod forsigtighed, blokerer legitime sider, og modeller, der markerer sjældnere, overser angreb. Claude Sonnet 5 har den højeste recall af alle detektorer med 98,73 %, men en FPR på 24,65 %. Gemini 3.1 Pro og GPT-5.5 når en recall på henholdsvis 97,78 % og 97,19 % med en FPR på 19,80 % og 20,44 %. GPT-6 Astra har den højeste samlede nøjagtighed med en recall på 96,42 % og en FPR på 14,41 %. Decider kommer på andenpladsen med en recall på 96,02 % og en FPR på 17,44 %. Claude Opus 5.5 har den laveste FPR på kun 4,21 %, men dens recall på 77,71 % betyder, at den overser mere end ét ud af fem angreb. Claude Fable 5.1 ser stærk ud på de sider, den svarer på, med en recall på 89,31 % og en FPR på 7,92 %, men den nægter at svare på omkring 30 % af siderne, som rækken »(all)« tæller som markeringer.

Udvid

Guard rykker Pareto-fronten frem og opnår en bedre balance mellem oversete angreb og falske alarmer. Den når en F1 på omkring 95 % og ligger nummer ét i alle tekstvisninger. Den markerer kun omkring én ud af 20 rene sider – cirka en tredjedel af raten for Astra, den mest nøjagtige promptede model. Forskellen skyldes vores træning; standardversionen af Qwen3.5-0.8B, som Guard er bygget på, når kun en F1 på 64 % og markerer næsten tre ud af fire rene sider, når den promptes på samme måde som de andre modeller. I scenariet med skærmbilledvisningen sammenligner vi Guards multimodale detektor med fire modeller, der kan behandle billeder. Med skærmbilleder af hele siden scorer Guard omkring 93 % F1 mod omkring 79 % for den bedste af de andre modeller, vi evaluerede.

At genkende et angreb er ikke det samme som at modstå det

Intuitivt burde en model, der korrekt kan identificere en injektion, også ignorere den injektion, når den støder på siden under udførelsen af brugeropgaver. Vores eksperimenter viser dog, at stærke detektionsscorer ikke garanterer, at en model modstår et angreb. Vi gav hver model den samme angrebne side to gange: én gang for at vurdere, om den indeholdt en injektion, og én gang for at udføre brugerens opgave uden at se den tidligere vurdering. En separat dommer kontrollerede, om den fulgte injektionen. Alle testede modeller fulgte stadig nogle injektioner, de havde markeret, fra 1,64 % af de markerede sider for GPT-6 Astra til 24,73 % for Llama 3.1 8B.

Udvid

Detektionsscorer forudsiger ikke pålideligt forskelle mellem modeller. Claude Sonnet 5 og GPT-5.5 opdager injektioner omtrent lige godt med F1-scorer på henholdsvis ca. 88 % og 89 %. Sonnet 5 fulgte dog en injektion, den havde markeret, på 19,74 % af siderne – ti gange så ofte som GPT-5.5 med 1,97 %.

Et implementerbart system til forsvar mod injektioner

Disse resultater tyder på, at der er værdi i at overlade beslutningen om at blokere en side til en specialiseret model i stedet for at forlade sig på den model, der udfører brugerens opgave. En separat detektor, der screener hver side, før agenten handler, giver et ekstra forsvarslag og har hverken en opgave, der kan kapres, eller værktøjer, der kan misbruges.

Guard er bygget til at være den detektor. Ud over at have den højeste F1-score og nøjagtighed af alle de modeller, vi testede, gør dens lille størrelse den billig nok til at køre på hver eneste side. I gennemsnit brugte Guard ca. 0,15 sekunders GPU-tid pr. tekstside. På en lejet H200 anslår vi en omkostning på 0,18 $ pr. 1.000 sider sammenlignet med 18,95–180,61 $ for frontier-API-modellerne til listepriser. I vores sammenligning gør det hyppig screening langt billigere, samtidig med at detektionsscorerne forbliver høje.

Figuren nedenfor viser hver detektors nøjagtighed i forhold til dens tid pr. side og dens omkostning pr. 1.000 sider, begge på logaritmiske skalaer. Guard ligger alene i øverste venstre hjørne af begge paneler: Den vinder på nøjagtighed, hastighed og omkostninger. Alle promptede modeller bruger omkring et sekund eller mere pr. side, og de to mest nøjagtige, GPT-6 Astra og Claude Fable 5.1, koster over 100 USD pr. 1.000 sider.

Udvid

Test af forsvar mod adaptive angreb

BrowseSafe++-benchmarket har et begrænset sæt injektioner. En rigtig angriber kan dog iværksætte et adaptivt angreb; når en injektion mislykkes, kan angriberen omskrive den og prøve igen. Derfor kan en agent, der modstår den oprindelige injektion, stadig være sårbar over for fremtidige angreb. Desuden trænes modeller på data indsamlet fra internettet, så de kan lære at modstå de fleste af dets injektioner; da vi offentliggør vores benchmark, vil det sandsynligvis blive mættet og ikke længere skelne godt mellem modeller. For at løse begge problemer byggede vi BrowseSafe-Adapt, et testmiljø, hvor en angribermodel kan omskrive injektioner. Hver test har tre faser:

1. Opret testcasen. En testcase kombinerer en BrowseSafe++-post med en målagent. BrowseSafe++-posten indeholder et scenarie med en brugerforespørgsel og en opgave, en angrebet side og angriberens ønskede resultat. Agenten arbejder i en sandbox, der stiller de værktøjer og syntetiske data til rådighed, som kræves for at udføre opgaven. En separat verifikationsmodel vurderer, om angrebet nåede sit mål.
2. Kør et forsøg: Vi indsætter den aktuelle injektion på siden og lader agenten udføre opgaven. Verifikatoren kontrollerer agentens svar og eventuelle ændringer, den har foretaget i sandboxen, for at afgøre, om angrebet lykkedes. Det første forsøg bruger injektionen fra den oprindelige post i BrowseSafe++.
3. Revidér og gentag: Hvis et angreb mislykkes, arkiverer vi forsøget, og en kritikermodel gennemgår, hvad der gik galt. En angribermodel bruger den feedback til at omskrive injektionen; den kan ændre angrebets ordlyd, formatering eller placering på siden. Angrebsmålet, succeskriterierne og det omgivende sideindhold forbliver de samme. Det næste forsøg bruger det opdaterede angreb. Processen gentages, indtil angrebet lykkes, eller angriberen når en fastsat grænse for antal forsøg.

Udvid

Vi testede syv agenter, der hver især er bygget på en forskellig model: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite samt modellerne med åbne vægte DeepSeek V3.1 og Kimi K2. Hver agent fik de samme 1.024 opgaver med op til 64 forsøg pr. opgave. Ved første forsøg var angrebenes succesrate lav for alle syv agenter. De oprindelige injektioner lykkedes højst i 4 % af de evaluerede opgaver, uanset agent. Med det adaptive framework steg angrebenes succesrate markant. Angriberen havde succes i mindst 79 % af opgaverne mod fem af de syv agenter. Selv de stærkeste agenter var sårbare: Angreb lykkedes stadig i omkring to ud af tre opgaver mod GPT-5.5 og omkring én ud af tre mod Claude Sonnet 5.

Forskellen mellem agenterne er størst, når angriberens mål er at få agenten til at foretage et bestemt værktøjskald. For opgaver med denne type mål gav Sonnet 5 efter i omkring 8 % af opgaverne og GPT-5.5 i omkring 29 %. De øvrige fem udførte angriberens mål i mere end halvdelen af deres opgaver.

Vi kørte også BrowseSafe-Adapt mod Gemini 3.5 Flash-Lite-agenten, hvor Guard først screenede hver side. Guard blokerede 94,5 % af de oprindelige injektioner og fordoblede næsten det gennemsnitlige antal forsøg, angriberne havde brug for, fra 9,7 til 17,0. Med alle 64 forsøg lykkedes det dog stadig for angriberen i 84,2 % af opgaverne (93,6 % uden Guard), næsten altid med en injektion, som Guard ikke markerede. Det stemmer overens med det synspunkt, vi fremlagde, da vi lancerede BrowseSafe: Ingen detektionsmodel er en mirakelkur, så en detektor skal indgå i et forsvar i flere lag.

Udvid

Konklusion

Browseragenter er ofte sårbare over for indirekte promptinjektion, hvor angreb skjult på almindelige sider forsøger at forstyrre agenternes evne til at udføre brugernes opgaver. Farerne vokser kun over tid, både fordi agenter får adgang til flere data og værktøjer, så der potentielt står mere på spil ved angreb, og fordi angribere kan revidere deres injektioner, så de bliver mere effektive.

Vores BrowseSafe-suite imødegår disse trusler. BrowseSafe++-benchmarket indeholder 38.675 websidepar, primært bygget ud fra rigtige injektioner, hvilket muliggør mere pålidelig træning og evaluering af detektorer. BrowseSafe-Guard-detektorerne, der er trænet på disse par, giver meget nøjagtig, hurtig og billig detektion, så det bliver muligt at scanne sider, før en agent handler på dem. BrowseSafe-Adapt-frameworket gør det muligt at teste modeller mod reviderede injektioner og fremhæver sårbarheder, som måske ikke er tydelige ud fra enkeltforsøg med faste injektioner.

Vi håber, at disse værktøjer tilsammen gør det lettere for forskere og ingeniører at finde fejl og forbedre forsvaret mod webbaserede promptinjektionsangreb. Vi evaluerer og forbedrer også løbende de indbyggede forsvarsmekanismer i Comet og Computer for at beskytte vores brugere.

Kom godt i gang

1. Installér SDK'et, og få adgang til dataene. SDK'et installeres fra GitHub:

Datasættet er adgangsbegrænset. Anmod om adgang én gang på dets Hugging Face-side, og log derefter ind med hf auth login.

2. Indsend til ranglisten. Evaluér din egen detektor på testsættet i BrowseSafe++:

Dette skriver én beslutning pr. side for hver visning, du angiver; angiv alle tre tekstvisninger for at få et gennemsnit på tekstranglisten. Log ind på ranglistens Space med din Hugging Face-konto, og upload predictions.jsonl. Dette Space returnerer F1, nøjagtighed, falsk positiv-rate og de øvrige målinger for hver visning og offentliggør, hvis du ønsker det, resultatet på ranglisten. Hver konto (mindst 60 dage gammel) får én bedømt indsendelse pr. UTC-uge. Testsiderne er kun til evaluering: Du må ikke træne på dem eller videredistribuere dem. Indsendelsesvejledningen beskriver filformatet og reglerne for offentliggørelse.

Kildehenvisning

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