Byg sikrere AI-browsere med BrowseSafe

I dag udgiver vi BrowseSafe, en åben forskningsbenchmark og indholdsdetekteringsmodel, der har til formål at beskytte brugere, når de navigerer på agent-webben.

Efterhånden som AI-assistenter bevæger sig fra søgefelter og ind i selve browseren, forventer vi, at den næste generation af the web vil skifte fra sider til agenter: mindre om, hvor information bor, og mere om, hvem der henter den og handler på den. Comet forvandler browseren til et sted, hvor en assistent kan udføre opgaver i stedet for blot at besvare spørgsmål, så ét princip er ufravigeligt: Den skal forblive på brugerens side.

BrowseSafe: Beskyttelse af agenter og brugere gennem indholdsscanning i realtid

BrowseSafe er en detekteringsmodel finpudset til at besvare ét fokuseret spørgsmål: Givet en sides HTML, indeholder den ondsindede instruktioner rettet mod agenten? Store generelle modeller kan ræsonnere godt om disse tilfælde, men de er ofte for langsomme og dyre til at køre på hver eneste side. BrowseSafe scanner fulde websider i realtid uden at sløve browseren. Vi udgiver også evalueringspakken BrowseSafe‑Bench som en ressource til evaluering og forbedring af forsvarets effektivitet.

Tillidsgrænser og lagdelte forsvar

En ny generation af AI-browsing betyder imidlertid også en ny generation af cybersikkerhedstrusler, der kræver nye tilgange til at holde brugerne sikre. I et tidligere indlæg gennemgik vi, hvordan Comet bruger flere lag af beskyttelse for at holde assistenten i gang med det, brugeren bad om, selv når et websted forsøger at kapre den med prompt-injektion. I dag zoomer vi ind på, hvordan vi tackler det problem: hvordan disse trusler defineres, testes mod angreb i den virkelige verden og bruges til at træne specialiserede modeller, der kan opdage og stoppe dårlige instruktioner hurtigt nok til at køre sikkert i browseren.

Hvordan browser-prompt-injektion fungerer

Prompt-injektion er ondsindet sprog indlejret i den tekst, som AI læser, og som er designet til at tilsidesætte dens oprindelige hensigt. I browseren læser agenter hele sider, så angreb kan gemme sig steder som kommentarer, skabeloner eller lange sidefødder.

Angribere bruger disse steder til i smug at indskyde instruktioner, der diskret omdirigerer agenten. Fordi den læser alt – inklusive indhold, som de fleste mennesker aldrig lægger mærke til – kan disse beskeder kapre adfærden uden stærke sikkerhedsforanstaltninger.

Disse angreb undgår ofte åbenlyse sætninger og kan være skrevet i poleret eller flersproget tekst eller placeret i HTML-elementer, der aldrig vises på skærmen, såsom data-attributter eller formularfelter, som browsere ikke gengiver synligt, men som agenter stadig fortolker.

BrowseSafe-Bench: Fremme af agentsikkerhed i virkelige miljøer

For at studere disse angreb i et miljø, der ligner det virkelige web, har vi bygget BrowseSafe, en detekteringsmodel, som vi har trænet og open-sourcet, og BrowseSafe‑Bench, en offentlig benchmark med 14.719 eksempler, der efterligner produktionssider. Den indeholder kompleks HTML, støjende indhold og en blanding af ondsindede og harmløse eksempler, der varierer langs tre akser: hvad angriberen forsøger at gøre, hvor instruktionen sidder på siden, og hvordan sproget er skrevet.

Benchmarken indeholder 11 angrebstyper, ni injektionsstrategier, der spænder fra skjulte felter til synlige afsnit og sidefødder, og tre sproglige stilarter, lige fra eksplicitte kommandoer til indirekte, camoufleret tekst.

En dybdegående forsvars-tilgang

I vores trusselmodel lever selve assistenten i et betroet miljø, men alt, der kommer fra webben, er utilgængeligt/ubetroet. Angribere kan kontrollere hele websteder eller blot indskyde indhold såsom produktbeskrivelser, kommentarer og indlæg i ellers godartede sider, som assistenten besøger. For at styre denne risiko markeres værktøjer, der kan returnere ubetroet indhold – såsom websider, e-mails eller filer – og deres rå output scannes altid af BrowseSafe, før agenten kan læse eller handle på dem.

BrowseSafe er ét lag i en bredere forsvarsindsats. Råt indhold scannes før brug, værktøjstilladelser begrænses som standard, og følsomme handlinger kan kræve eksplicit brugerbekræftelse – alt oven på eksisterende browsersikkerhedsfunktioner. Dybdegående forsvar gør det muligt for brugere at tage kraftfulde browsere i brug uden at opgive sikkerhed for funktionalitet.

Hvad påvirker angrebs effektivitet?

Evalueringsresultater på BrowseSafe‑Bench viser klare mønstre. Direkte angreb, såsom at bede agenten om at afsløre sin system-prompt eller udfiltrere information via URL-segmenter, er blandt de nemmeste for modeller at opfange. I modsætning hertil er flersprogede angreb og dem, der er skrevet som indirekte eller hypotetiske instruktioner, betydeligt sværere, fordi de undgår de åbenlyse nøgleord, som mange detektorer implicit stoler på.

Placering betyder også noget. Angreb, der er skjult i kommentarer, detekteres relativt godt, mens versioner, der er omskrevet til synlige sidefødder, tabelceller eller indbyggede afsnit, viser sig at være meget sværere, hvilket afslører en strukturel skævhed mod “skjulte” injektioner. Omhyggelig træning på veldesignede eksempler kan markant forbedre modellers evne til at opdage disse mønstre.

Byg sikrere agenter med BrowseSafe

BrowseSafe og BrowseSafe-Bench er fuldt open-source. Enhver udvikler, der bygger autonome agenter, kan øjeblikkeligt hærde deres systemer mod prompt-injektion – der er ingen grund til at bygge sikkerhedsforanstaltninger op helt fra bunden. Det detekteringsmodel med åben vægt kører lokalt og markerer ondsindede instruktioner, før de når din agents kernelogik, hurtigt nok til at scanne hver side uden at sløve brugerne.

Brug BrowseSafe-Bench's 14.000+ angrebsscenarier i den virkelige verden til at stressteste dine egne modeller mod de rodede HTML-fælder, der bryder standard-LLM'er. Vores chunking- og parallelscanningsteknikker giver agenter mulighed for at behandle massive, ubetroede sider effektivt – kraftfulde browsingfunktioner uden at udsætte brugere for fare.

For at lære mere om, hvordan vi byggede BrowseSafe og BrowseSafe-Bench, kan du tjekke Perplexity Research-bloggen.