Bygger sikrere KI-nettlesere med BrowseSafe

I dag lanserer vi BrowseSafe, en åpen forskningsreferanse og innholdsdeteksjonsmodell som har som mål å holde brukere trygge når de navigerer på nettet for agenter.

Ettersom KI-assistenter flytter fra søkebokser og inn i selve nettleseren, forventer vi at neste generasjon av Internett skifter fra sider til agenter: mindre om hvor informasjonen befinner seg, og mer om hvem som henter den inn og handler på grunnlag av den. Comet gjør nettleseren om til et sted der en assistent kan utføre oppgaver, ikke bare svare på spørsmål, slik at ett prinsipp ikke er til å diskutere: den må forbli på brukerens side.

BrowseSafe: beskytter agenter og brukere gjennom innholdsskanning i sanntid

BrowseSafe er en deteksjonsmodell finjustert til å svare på ett enkelt og fokusert spørsmål: Gitt en sides HTML, inneholder den ondsinnede instruksjoner rettet mot agenten? Store generelle modeller kan resonnere godt rundt disse tilfellene, men de er ofte for trege og kostbare til å kjøre på hver enkelt side. BrowseSafe skanner fulle nettsider i sanntid uten å senke hastigheten på nettleseren. Vi lanserer også evalueringspakken BrowseSafe-Bench som en ressurs for å evaluere og forbedre forsvarets effektivitet.

Tillitsgrenser og lagdelte forsvar

En ny generasjon med KI-nettlesing betyr imidlertid også en ny generasjon cybersikkerhetstrusler som krever nye tilnærminger for å holde brukere trygge. I et tidligere innlegg gikk vi gjennom hvordan Comet bruker flere lag med beskyttelse for å holde assistenten i gang med det brukeren ba om, selv når et nettsted prøver å kapre den med ledetekstinjeksjon (prompt injection). I dag retter vi søkelyset mot hvordan vi takler dette problemet: hvordan disse truslene defineres, testes mot virkelige angrep, og brukes til å trene opp spesialiserte modeller som kan oppdage og stoppe dårlige instruksjoner raskt nok til å kjøre trygt i nettleseren.

Hvordan ledetekstinjeksjon i nettlesere fungerer

Ledetekstinjeksjon er ondsinnet språk innebygd i teksten som KI-en leser, som er utformet for å overstyre dens opprinnelige hensikt. I nettleseren leser agenter hele sider, så angrep kan gjemme seg på steder som kommentarer, maler eller lange bunntekster.

Angripere bruker disse stedene til å snike inn instruksjoner som i det stille omdirigerer agenten. Fordi den leser alt, inkludert innhold de fleste aldri legger merke til, kan disse meldingene kapre oppførselen uten sterke sikkerhetstiltak.

Disse angrepene unngår ofte åpenbare fraser og kan skrives i polert eller flerspråklig tekst, eller plasseres i HTML-elementer som aldri vises på skjermen, for eksempel dataattributter eller skjemaelementer som nettlesere ikke gjengir synlig, men som agenter fremdeles analyserer.

BrowseSafe-Bench: fremmer agentsikkerhet i virkelige miljøer

For å studere disse angrepene i omgivelser som ligner det ekte Internett, bygde vi BrowseSafe, en deteksjonsmodell som vi har trent opp og åpnet kildekoden til, og BrowseSafe-Bench, en offentlig referansetest med 14 719 eksempler som etterligner produksjonssider. Den inkluderer kompleks HTML, støyende innhold og en blanding av ondsinnede og ufarlige eksempler som varierer langs tre akser: hva angriperen prøver å gjøre, hvor instruksjonen befinner seg på siden, og hvordan språket er skrevet.

Referansetesten inneholder 11 angrepstyper, ni injeksjonsstrategier som spenner fra skjulte felt til synlige avsnitt og bunntekster, og tre språklige stiler, fra eksplisitte kommandoer til indirekte, kamuflert tekst.

En dybdeforsvarstilnærming

I trusselmodellen vår befinner selve assistenten seg i et klarert miljø, men alt som kommer fra nettet, er utilstrekkelig sikret. Angripere kan kontrollere hele nettsteder eller bare injisere innhold som produktbeskrivelser, kommentarer og innlegg i ellers godartede sider som assistenten besøker. For å håndtere den risikoen blir verktøy som kan returnere utilstrekkelig sikret innhold – som nettsider, e-poster eller filer – flagget, og deres råutdata blir alltid skannet av BrowseSafe før agenten kan lese eller handle ut fra dem.

BrowseSafe er ett lag i en bredere forsvarstilnærming. Råinnhold skannes før bruk, verktøytillatelser begrenses som standard, og sensitive handlinger kan kreve eksplisitt brukerbekreftelse, alt på toppen av eksisterende nettlesersikkerhetsfunksjoner. Dybdeforsvar gjør det muliggjøre for brukere å ta i bruk kraftige nettleserassistenter uten å ofre sikkerhet for funksjonalitet.

Hva påvirker angrepets effektivitet?

Evalueringsresultater på BrowseSafe-Bench viser tydelige mønstre. Direkte angrep, som å be agenten om å avsløre systemledeteksten sin eller ekstraturere informasjon via URL-segmenter, er blant de enkleste for modeller å fange opp. I kontrast er flerspråklige angrep og de som er skrevet som indirekte eller hypotetiske instruksjoner, vesentlig vanskeligere fordi de unngår de åpenbare nøkkelordene mange detektorer implisitt stoler på.

Plassering har også noe å si. Angrep som er skjult i kommentarer, oppdages relativt godt, mens versjoner skrevet om til synlige bunntekster, tabellceller eller innebygde avsnitt viser seg å være mye vanskeligere, noe som avslører en strukturell skjevhet mot «skjulte» injeksjoner. Grundig opplæring på godt utformede eksempler kan i vesentlig grad forbedre modellenes evne til å oppdage disse mønstrene.

Bygg sikrere agenter med BrowseSafe

BrowseSafe og BrowseSafe-Bench har fullstendig åpen kildekode. Enhver utvikler som bygger autonome agenter, kan umiddelbart herde systemene sine mot ledetekstinjeksjon – du trenger ikke å bygge sikkerhetsrekkverk fra bunnen av. Deteksjonsmodellen med åpne vekter kjører lokalt og flagger ondsinnede instruksjoner før de når agentens kjernelogikk, og den er rask nok til å skanne hver side uten at det går ut over brukerens hastighet.

Bruk BrowseSafe-Bench sine over 14 000 virkelige angrepsscenarier til gassteste dine egne modeller mot de rotete HTML-fellene som knekker standard LLM-er. Våre oppdelings- og parallellskanningsteknikker lar agenter behandle massive, utilstrekkelig sikrede sider effektivt – kraftige nettleserfunksjoner uten å utsette brukere for fare.

Vil du vite mer om hvordan vi bygget BrowseSafe og BrowseSafe-Bench, kan du sjekke bloggen til Perplexity Research.