Bygga säkrare AI-webbläsare med BrowseSafe

Idag släpper vi BrowseSafe, ett öppet forskningsriktmärke och innehållsdetekteringsmodell som syftar till att hålla användarna säkra när de navigerar på den agentiska webben.

Allt eftersom AI-assistenter flyttar från sökrutor in i själva webbläsaren förväntar vi oss att nästa generation av webben skiftar från sidor till agenter: mindre om var information finns och mer om vem som hämtar och agerar på den. Comet förvandlar webbläsaren till en plats där en assistent kan utföra uppgifter, inte bara svara på frågor, så en princip är inte förhandlingsbar: den måste förbli på användarens sida.

BrowseSafe: skyddar agenter och användare genom innehållsskanning i realtid

BrowseSafe är en detekteringsmodell finjusterad för att besvara en enda fokuserad fråga: givet en sidas HTML, innehåller den skadliga instruktioner riktade mot agenten? Stora allmänna modeller kan resonera väl om dessa fall, men de är ofta för långsamma och dyra för att köras på varje sida. BrowseSafe skannar fullständiga webbsidor i realtid utan att sakta ner webbläsaren. Vi släpper också utvärderingssviten BrowseSafe-Bench som en resurs för att utvärdera och förbättra försvarets effektivitet.

Förtroendegränser och skiktade försvar

En ny generation av AI-surfning innebär dock också en ny generation av cybersäkerhetshot som kräver nya metoder för att hålla användarna säkra. I ett tidigare inlägg gicks det igenom hur Comet använder flera skyddslager för att hålla assistenten görandes det som användaren bad om, även när en webbplats försöker kapa den med promptinjektion. Idag zoomar vi in på hur vi tacklar det problemet: hur dessa hot definieras, testas mot verkliga attacker och används för att träna specialiserade modeller som kan upptäcka och stoppa dåliga instruktioner tillräckligt snabbt för att köras säkert i webbläsaren.

Hur webbläsarpromptinjektion fungerar

Promptinjektion är skadligt språk inbäddat i texten som AI läser som är utformat för att åsidosätta dess ursprungliga avsikt. I webbläsaren läser agenter hela sidor, så attacker kan gömma sig på platser som kommentarer, mallar eller långa sidfötter.

Angripare använder dessa platser för att smyga in instruktioner som i tysthet omdirigerar agenten. Eftersom den läser allt, inklusive innehåll som de flesta aldrig lägger märke till, kan dessa meddelanden kapa beteendet utan starka skyddsåtgärder.

Dessa attacker undviker ofta uppenbara fraser och kan skrivas in i polerad eller flerspråkig text, eller placeras i HTML-element som aldrig visas på skärmen, till exempel dataattribut eller formulärfält som webbläsare inte renderar synligt men som agenter ändå tolkar.

BrowseSafe-Bench: främjar agentsäkerhet i verkliga miljöer

För att studera dessa attacker i en miljö som liknar den verkliga webben byggde vi BrowseSafe, en detekteringsmodell som vi tränade och släppte med öppen källkod, och BrowseSafe-Bench, ett publikt riktmärke med 14 719 exempel som efterliknar produktionssidor. Det inkluderar komplex HTML, brusigt innehåll och en blandning av skadliga och ofarliga prov som varierar längs tre axlar: vad angriparen försöker göra, var instruktionen sitter på sidan och hur språket är skrivet.

Riktmärket innehåller 11 attacktyper, nio injektionsstrategier som spänner från dolda fält till synliga stycken och sidfötter, och tre språkliga stilar, från uttryckliga kommandon till indirekt, kamouflerad text.

Ett djupt försvarsangreppssätt

I vår hotmodell lever själva assistenten i en betrodd miljö, men allt som kommer från webben är opålitligt. Angripare kan kontrollera hela webbplatser eller bara injicera innehåll, såsom produktbeskrivningar, kommentarer och inlägg i i övrigt godartade sidor som assistenten besöker. För att hantera den risken flaggas verktyg som kan returnera opålitligt innehåll, såsom webbsidor, e-postmeddelanden eller filer, och deras råa utdata skannas alltid av BrowseSafe innan agenten kan läsa eller agera på dem.

BrowseSafe är ett lager i ett bredare försvarsangreppssätt. Rått innehåll skannas före användning, verktygsbehörigheter begränsas som standard och känsliga åtgärder kan kräva uttrycklig användarbekräftelse, allt utöver befintliga webbläsarfunktioner för säkerhet. Djupförsvar gör det möjligt för användare att anta kraftfulla webbläsarassistenter utan att byta bort säkerhet mot funktionalitet.

Vad påverkar attackens effektivitet?

Utvärderingsresultat på BrowseSafe-Bench visar tydliga mönster. Direkta attacker, som att be agenten att avslöja sin systemprompt eller exfiltrera information via URL-segment, är bland de enklaste för modeller att fånga upp. Däremot är flerspråkiga attacker och de som är skrivna som indirekta eller hypotetiska instruktioner betydligt svårare, eftersom de undviker de uppenbara sökord som många detektorer implicit förlitar sig på.

Placering spelar också roll. Attattacker som är dolda i kommentarer upptäcks relativt väl, medan versioner som skrivits om till synliga sidfötter, tabellceller eller inbyggda stycken visar sig vara mycket svårare, vilket avslöjar en strukturell partiskhet mot "dolda" injektioner. Noggrann träning på väl utformade exempel kan avsevärt förbättra modellernas förmåga att upptäcka dessa mönster.

Bygg säkrare agenter med BrowseSafe

BrowseSafe och BrowseSafe-Bench har helt öppen källkod. Alla utvecklare som bygger autonoma agenter kan omedelbart härda sina system mot promptinjektion – inget behov av att bygga säkerhetsräcken från grunden. Detektionsmodellen med öppna vikter körs lokalt och flaggar skadliga instruktioner innan de når din agents kärnlogik, tillräckligt snabbt för att skanna varje sida utan att sakta ner användarna.

Använd BrowseSafe-Bench-s 14 000+ attacker i verkligheten för att stresspesta dina egna modeller mot de röriga HTML-fällor som bryter standard-LLM:er. Våra styckelnings- och parallellskanningstekniker låter agenter bearbeta massiva, opålitliga sidor effektivt – kraftfulla surfmöjligheter utan att utsätta användare för fara. För att lära dig mer om hur vi byggde BrowseSafe och BrowseSafe-Bench, kolla in Perplexity Research-bloggen.