BrowseSafe++: erősebb védelem kiépítése a valós promptinjektálás ellen

A webet böngészni képes ügynököknek – például a Comet vagy a Computer beépített asszisztensének – interakcióba kell lépniük a weboldalakkal: el kell olvasniuk a tartalmat, és annak alapján műveleteket kell végrehajtaniuk a felhasználóik nevében. Ez sebezhetővé teszi őket a közvetett promptinjektálással szemben, amikor a támadó rosszindulatú szöveget helyez el egy weboldalon. Ha az ügynök követi ezeket az utasításokat, félrevezető választ adhat, vagy olyan műveletet hajthat végre, amelyet a felhasználó nem kért.

2025 decemberében kiadtuk a BrowseSafe nevű benchmarkot és észlelőmodellt, amely erre a fenyegetésre irányul. Úgy hoztuk létre, hogy szintetikus támadásokat helyeztünk el olyan valósághű weboldalakon, amelyekkel az ügynökök valószínűleg találkoznak. Az elmúlt évben a támadások kifinomultabbá váltak, és egyre inkább hétköznapi oldaltartalomnak tűnnek. Az olyan árulkodó kifejezések helyett, mint a „hagyd figyelmen kívül a korábbi utasításokat”, gyakran olyan tartalmat utánoznak, amelyben az ügynök valószínűleg megbízik, például a webhely hivatalos közleményét vagy egy felhasználói preferenciákról szóló megjegyzést.

Ezen változások nyomán elkészítettük a BrowseSafe++ nevű frissített benchmarkot, amellyel azt mérjük, hogy a jelenlegi injekciódetektorok észlelik-e ezeket a támadásokat, és hogy az ügynökök képesek-e ellenállni nekik. Összesen 38 675 megtámadott és tiszta oldalpárt tartalmaz, amelyek elsősorban valós környezetben gyűjtött injekciókra épülnek. Minden oldal esetében átírjuk a környező tartalmat a magánszféra védelme érdekében, a támadást azonban szó szerint megtartjuk. Minden oldal abban a négy formátumban érhető el, amelyet a böngészőügynökök olvasnak: HTML, Markdown, akadálymentességi fa és képernyőkép. A benchmark egy részhalmazán tanítottuk be a BrowseSafe-Guardot, egy 0,8 milliárd paraméteres detektorpárt: egy szöveges és egy multimodális detektort. A két Guard-detektor pontosabban azonosítja az injekciókat, mint az általunk tesztelt promptolt modellek, beleértve az élvonalbeli modelleket is. Emellett gyorsabbak, olcsóbbak, és sokkal kevesebb hétköznapi oldalt jelölnek meg tévesen.

A BrowseSafe++-t nyílt benchmarkként tesszük közzé. A projekt webhelyén hivatkozások találhatók az adatkészlethez, az SDK-hoz, a kutatási tanulmányhoz és egy nyilvános ranglistához. Bármely csapat kiértékelheti detektorát olyan tesztoldalakon, amelyek címkéi nincsenek megadva, majd beküldheti a címkéket értékelésre és a ranglistára való esetleges felkerülés céljából. Az eredmények kiértékeléséhez és beküldéséhez lásd az Első lépések részt.

Benchmark készítése megfigyelt injekciókból

A BrowseSafe++ valós webhelyeken megfigyelt promptinjektálásokra épül. 2025 szeptembere és 2026 szeptembere között a Comet promptinjektálás-detektora 1,15 millió injekciót jelölt meg az ügynöke által olvasott oldalakon. Ezen injekciók köré 32 187 párt építettünk, és hozzáadtunk 6488 párt az eredeti BrowseSafe benchmarkból, így összesen 38 675 pár jött létre. Minden pár tartalmaz egy megtámadott oldalt és annak tiszta ikerpárját, vagyis ugyanazt az oldalt injekció nélkül.

Így néznek ki az injekciók a valóságban

A benchmark két példája mutatja be, hogyan néznek ki ezek az injekciók a gyakorlatban.

Az egyikben egy hamis vásárlási kérés arra ösztönzi az ügynököt, hogy jogosulatlan műveletet hajtson végre. A Comet detektora 2025 októberében jelölte meg ezt az angol nyelvű szövegblokkot egy orosz nyelvű fejlesztői dokumentációs oldalon:

A szöveg utasításokkal kezdődik és zárul, a közepét pedig hétköznapi tokenmarketing-szöveg tölti ki. Azt állítja, hogy magától az ügynök fejlesztőjétől származik, és egy engedélyezési kóddal zárul, hogy a vásárlás jóváhagyottnak tűnjön.

Egy másik esetben egy hamisított beszélgetés célja az ügynök feladatának megzavarása. Ezt a szöveget egy kódtároló oldalán találtuk 2026 márciusában:

A szöveget úgy alakították ki, hogy egy felhasználó és egy ügynök közötti beszélgetésnek tűnjön: a <|im_start|> és a <|im_end|> olyan jelölők, amelyekkel egyes csevegőmodellek elválasztják a beszélgetés fordulóit. Az az ügynök, amely bedőlne ennek a támadásnak, a hamisított felhasználói kérésre reagálna, és a támadó által megadott mondattal válaszolna.

A megjelölt injekciókban hasonló mintázatokat figyeltünk meg:

• Megbízható forrásokat utánoznak. Mindkét példában az oldal szövege úgy hangzik, mintha olyan forrásból származna, amelyben az ügynök megbízik: az elsőben a fejlesztőjétől, a másodikban a saját beszélgetéséből. Az injektálások kiadhatják magukat magának a webhelynek is – biztonsági ellenőrzéseket és szabályzati közleményeket utánozva –, vagy a felhasználónak, hamis preferenciákat megfogalmazva. Körülbelül háromból kettő formális nyelvezettel íródott.
• Sok közülük más nyelven íródott. A párok 24,4%-ában az injekció az oldal többi részétől eltérő nyelvet használ. Ez jellemzően egy nem angol nyelvű oldalon elhelyezett angol nyelvű utasítás formáját ölti, ahogy az első példában is. Az ilyen támadások egyértelműen olyan ügynöknek szólnak, amely minden nyelven olvas, és általában az angol az anyanyelve. A nyelvváltások az észlelést is megnehezítik: az eredeti BrowseSafe-értékelésünkben a többnyelvű támadások a legnehezebben észlelhetők közé tartoztak.
• A legtöbbjük cselekvést akar, nem szavakat. Tízből több mint négy olyan művelet felé tereli az ügynököt, amelyet a felhasználó sosem kért, mint az első példában a token vásárlása, és körülbelül egyharmaduk arra próbálja rávenni, hogy hagyja abba a felhasználó feladatát, ahogy a második példában. Csak körülbelül 3%-uk próbál hamis információt elhelyezni a válaszban.
• Gyakran olyan tartalmakban bújnak meg, amelyeket bárki közzétehet. A támadónak nem kell irányítania egy webhelyet. Elég egy fórumbejegyzés vagy egy megosztott dokumentum egy hétköznapi webhelyen, és a BrowseSafe++ több mint 23 000 injektálása így érkezett. Még egy megbízható domain is felhasználható a támadó szövegének injektálására.

A végleges benchmarkban szereplő injekciók 12 webhelytípust, 24 támadástípust, 6 támadói célt és 18 oldalon belüli elhelyezést fednek le.

Nagyítás

A megjelölt oldaltól a benchmarkpárig

A megjelölt oldalakat nem használhatjuk fel változatlan formában a benchmarkban, mert személyes adatokat tartalmazhatnak arról a felhasználóról, akinek az ügynök dolgozott. Ahhoz, hogy egy oldalból megosztható benchmarkpár legyen, három fő szakaszra van szükség:

1. Az injekciók beszerzése: Összegyűjtjük a megjelölt oldalakat, eltávolítjuk a duplikátumokat, és a személyes adatokat a PII-Tracer segítségével maszkoljuk. Ezután megerősítjük, hogy az oldal injekciót tartalmaz; konkrétan azt követeljük meg, hogy egy modellekből álló testület egyetértsen abban, hogy az oldal olyan utasítást tartalmaz, amely megpróbálja eltéríteni az ügynököt a felhasználó által szándékolt feladattól.
2. A pár elkészítése: Egy ügynök eltávolítja az injekció szövegét minden oldalról, és átírja a környező oldaltartalmat, a neveket, márkákat és hasonló részleteket kitaláltakra cserélve. Egy második ügynök ellenőrzi, maradt-e valós tartalom az átírt oldalon, és a hibás eseteket visszajelzéssel visszaküldi. Emberi ellenőrök az oldalak véletlenszerűen kiválasztott 10%-át vizsgálják meg; az általuk talált problémákat a folyamatban javítjuk, és a javításokat a teljes korpuszra alkalmazzuk. Az injekciót visszahelyezzük az átírt oldalba, így jön létre a megtámadott példány, a tiszta példányból pedig kimarad. A két oldal feladata, várt eredménye és hétköznapi utasításai azonosak.
3. Ellenőrzés: Az ügynökök különböző formában olvassák az oldalakat, ezért minden oldal HTML-kódját Markdownként, akadálymentességi faként (az oldal felületi elemeinek és címkéinek strukturált listájaként) és képernyőképként is rendereljük. Egy másik ügynök ellenőrzi, hogy az injekció a megtámadott oldal mind a négy nézetében megjelenik-e, és hogy a tiszta oldalt minden nézetben ártalmatlannak ítélik-e. Ha az injekció valamelyik nézetből hiányzik, áthelyezzük az oldal egy másik pontjára, és újra rendereljük, így biztosítva, hogy a végleges megtámadott oldal minden nézetében szerepeljen. Végül automatikus ellenőrzések sora javítja azokat a párokat, amelyek még mindig a forrásukra utaló nyomokat hordoznak, például valódi gazdagépneveket vagy márkaneveket.

Nagyítás

BrowseSafe-Guard: gyors és precíz detektorok minden nézethez

Egy hasznos detektornak minden oldalt gyorsan és olcsón kell ellenőriznie. Emellett pontosnak kell lennie mind a megtámadott, mind a tiszta oldalakon. A magas precizitás különösen fontos, mivel a legtöbb oldal biztonságos; már egy viszonylag alacsony hamis pozitív arány esetén is a riasztások többsége téves lenne. A promptolt általános célú modellek precizitása gyakran elmarad a kívánttól, ráadásul túl lassúak és költségesek ahhoz, hogy minden oldalon futtassuk őket.

Az egymástól külön gyűjtött megtámadott és tiszta oldalakon tanított detektor olyan felszínes jegyeket tanulhat meg, amelyek véletlenül szétválasztják a két halmazt, például az oldal témáját vagy elrendezését. Egy ilyen detektor azonban nem általánosít jól. A Guard ehelyett olyan párokon tanul, amelyek között az egyetlen különbség maga az injektálás, ami segít javítani a detektor precizitását. Minden pár esetében a Guard külön olvassa be a megtámadott oldalt és annak tiszta párját, és mindkettőnek pontszámot ad arra vonatkozóan, mennyire valószínű, hogy injektálást tartalmaz. A modell frissítéséhez két tanítási célfüggvényt használunk: a szokásos osztályozási célfüggvényt és egy rangsorolási célfüggvényt, amely bünteti a Guardot, ha a megtámadott oldal nem kap legalább egy rögzített különbséggel magasabb pontszámot, mint a párja. Szemléletesen: az osztályozási célfüggvény megtanítja a Guardnak, milyen döntést hozzon, a rangsorolási célfüggvény pedig ezt a döntést magához az injektáláshoz köti, és figyelmen kívül hagyja az ártalmatlan zavaró elemeket. Így a Guard magára az injektálásra tanul meg reagálni, nem pedig a környező oldaltartalomra.

A Guard két detektorból áll, mindkettő a Qwen3.5-0.8B finomhangolt változata. A szöveges detektor az oldal egy szöveges nézetét olvassa be: a HTML-t, a Markdownt vagy az akadálymentességi fát. A multimodális detektor egy teljes oldalas képernyőképet olvas be. Éles használatban a Guard egyetlen előremenő lépésben olvassa be az oldalt, és injektálási pontszámot ad ki; az oldal akkor kap jelölést, ha a pontszám meghalad egy küszöbértéket. Mivel a Guard mindössze 0,8 milliárd paraméterrel rendelkezik, és egyetlen pontszámot ad ki, elég gyors és olcsó ahhoz, hogy minden oldalon futtatható legyen.

A teljesítmény mérése

A Guardot 18 olyan modellel hasonlítottuk össze, amelyeket promptolással arra utasítottunk, hogy észleljék az injekciókat a benchmark egy visszatartott részhalmazán. Négy mérőszámot közlünk, a BrowseSafe++ alapján mérve:

• A felidézés az injektált oldalak közül azok aránya, amelyeket a detektor megjelöl; azt méri, hány támadást észlel, ezért a magasabb érték jobb.
• A hamis pozitív arány (FPR) a tiszta oldalak közül azok aránya, amelyeket a detektor tévesen megjelöl; azt méri, milyen gyakran ad téves riasztást, ezért az alacsonyabb érték jobb.
• A precizitás a megjelölt oldalak közül azok aránya, amelyek valóban injekciót tartalmaznak; azt méri, milyen gyakran helyes egy riasztás, ezért a magasabb érték jobb.
• Az F1 a felidézés és a precizitás harmonikus közepe; csak akkor magas, ha a detektor a legtöbb támadást észleli, és megjelöléseinek csak kis része téves riasztás.

Elsődleges mérőszámként az F1-et használjuk, mivel egy jó detektornak magas precizitással és felidézéssel kell rendelkeznie. Mind a négy mérőszámot a három szöveges nézetre átlagoltuk.

Nagyítás

Nagyítás

Modellek összehasonlítása

Az általunk tesztelt kis, nyílt súlyú modellek a lista végére kerültek. A Mistral NeMo és a Qwen3 30B-A3B egyaránt a tiszta oldalak körülbelül felét jelöli meg, míg a Llama 3.1 8B szinte semmit sem jelöl meg, így a legtöbb támadást kihagyja. Még a csoport legerősebb modellje, a GPT-OSS 20B is csak 70,97%-os F1-pontszámot ér el. A DeepSeek V3.1, egy jóval nagyobb nyílt súlyú modell, valamivel jobban teljesít, 75,23%-os F1-pontszámmal.

A könnyűsúlyú API-modellek, köztük a GPT-5.4 nano, a Gemini 3.1 Flash-Lite és a Claude Haiku 4.5, több támadást ismernek fel, 85% és 97% közötti felidézéssel (recall). Ennek ára azonban a téves riasztások magas aránya: a csoportban a Gemini 3.1 Flash-Lite FPR-je a legalacsonyabb, 35,2%, a Haiku FPR-je pedig közel 69%. Ennek eredményeként a csoport legmagasabb F1-pontszáma 80,9%, amelyet a Gemini 3.1 Flash-Lite ért el.

A többi modell erősebb általános célú modell, 85% és 92% közötti F1-pontszámokkal. Ugyanakkor továbbra is kompromisszumot kell kötniük a felidézés és az FPR között: az óvatosságra hajló modellek legitim oldalakat blokkolnak, a ritkábban riasztó modellek pedig támadásokat hagynak ki. A Claude Sonnet 5 felidézése a legmagasabb az összes detektor közül, 98,73%, de FPR-je 24,65%. A Gemini 3.1 Pro és a GPT-5.5 felidézése 97,78%, illetve 97,19%, FPR-jük pedig 19,80%, illetve 20,44%. A GPT-6 Astra összesített pontossága a legmagasabb, 96,42%-os felidézéssel és 14,41%-os FPR-rel. A második a Decider, 96,02%-os felidézéssel és 17,44%-os FPR-rel. A Claude Opus 5.5 FPR-je a legalacsonyabb, mindössze 4,21%, de 77,71%-os felidézése azt jelenti, hogy ötből több mint egy támadást kihagy. A Claude Fable 5.1 erősnek tűnik azokon az oldalakon, amelyekre válaszol, 89,31%-os felidézéssel és 7,92%-os FPR-rel, de az oldalak körülbelül 30%-án megtagadja a választ, amelyeket az „(all)” sor megjelölésként számol.

Nagyítás

A Guard kitolja a Pareto-frontot, és jobb egyensúlyt ér el a kihagyott támadások és a téves riasztások között. Körülbelül 95%-os F1-pontszámot ér el, és minden szöveges nézetben az első helyen áll. Nagyjából csak minden huszadik tiszta oldalt jelöli meg, ami körülbelül harmada az Astra, a legpontosabb promptolt modell arányának. Ez a különbség a tanításunknak köszönhető: a Guard alapjául szolgáló gyári Qwen3.5-0.8B a többi modellel azonos módon promptolva csak 64%-os F1-pontszámot ér el, és a tiszta oldalak közel háromnegyedét megjelöli. A képernyőkép-nézetben a Guard multimodális detektorát négy képfeldolgozásra képes modellel hasonlítjuk össze. Teljes oldalas képernyőképek esetén a Guard körülbelül 93%-os F1-pontszámot ér el, szemben az általunk kiértékelt többi modell közül a legjobb körülbelül 79%-ával.

Egy támadás felismerése nem ugyanaz, mint ellenállni neki

Intuitív módon azt várnánk, hogy egy modell, amely helyesen azonosít egy injekciót, figyelmen kívül is hagyja azt, amikor a felhasználói feladatok elvégzése közben találkozik az oldallal. Kísérleteink azonban azt mutatják, hogy a jó észlelési pontszámok nem garantálják, hogy a modell ellenáll a támadásnak. Minden modellnek kétszer adtuk oda ugyanazt a megtámadott oldalt: egyszer azért, hogy eldöntse, tartalmaz-e injekciót, egyszer pedig azért, hogy az előző ítélet ismerete nélkül elvégezze a felhasználó feladatát. Egy külön bíráló ellenőrizte, hogy követte-e az injekciót. Minden tesztelt modell követett néhány olyan injekciót, amelyet korábban megjelölt: a megjelölt oldalak 1,64%-ától (GPT-6 Astra) 24,73%-áig (Llama 3.1 8B).

Nagyítás

Az észlelési pontszámok nem jelzik előre megbízhatóan a modellek közötti különbségeket. A Claude Sonnet 5 és a GPT-5.5 nagyjából egyformán jól észleli az injekciókat, körülbelül 88%-os, illetve 89%-os F1-pontszámmal. A Sonnet 5 azonban az oldalak 19,74%-án követett egy általa megjelölt injekciót, tízszer olyan gyakran, mint a GPT-5.5 a maga 1,97%-ával.

Telepíthető rendszer az injektálás elleni védelemhez

Ezek az eredmények arra utalnak, hogy érdemes egy oldal blokkolásáról szóló döntést egy erre a célra szolgáló modellre bízni, ahelyett hogy a felhasználó feladatát végző modellre hagyatkoznánk. Egy különálló detektor, amely minden oldalt átvizsgál, mielőtt az ügynök cselekedne, további védelmi réteget biztosít, és nincs eltéríthető feladata vagy visszaélésre alkalmas eszköze.

A Guard pontosan ilyen detektornak készült. Amellett, hogy az általunk tesztelt modellek közül neki a legmagasabb az F1-pontszáma és a pontossága, kis mérete miatt elég olcsó ahhoz, hogy minden oldalon futtatható legyen. A Guard átlagosan körülbelül 0,15 másodperc GPU-időt használt szöveges oldalanként. Egy bérelt H200-on a becsült költség 1000 oldalanként 0,18 $, szemben a listaáron számolt élvonalbeli API-modellek 18,95–180,61 $-os költségével. Összehasonlításunkban ez jóval olcsóbbá teszi a gyakori szűrést, miközben megőrzi a magas észlelési pontszámokat.

Az alábbi ábra minden detektor pontosságát az oldalankénti időigény és az 1000 oldalra vetített költség függvényében mutatja, mindkettőt logaritmikus skálán. A Guard mindkét panelen egyedül áll a bal felső sarokban: pontosságban, sebességben és költségben is nyer. Minden promptolt modell oldalanként körülbelül egy másodpercet vagy többet igényel, a két legpontosabb, a GPT-6 Astra és a Claude Fable 5.1 pedig 1000 oldalanként több mint 100 dollárba kerül.

Nagyítás

A védelmek tesztelése adaptív támadásokkal szemben

A BrowseSafe++ benchmark véges számú injekciót tartalmaz. Egy valódi támadó azonban adaptív támadást is indíthat: ha egy injekció kudarcot vall, átírhatja, és újra próbálkozhat. Emiatt egy ügynök, amely ellenáll az eredeti injekciónak, a jövőbeli támadásokkal szemben továbbra is sebezhető lehet. Ráadásul a modelleket az internetről gyűjtött adatokon tanítják, így megtanulhatnak ellenállni a benchmark injekciói közül a legtöbbnek; mivel benchmarkunkat nyilvánosan közzétesszük, valószínűleg telítődni fog, és nem fogja jól megkülönböztetni a modelleket. Mindkét probléma kezelésére létrehoztuk a BrowseSafe-Adapt tesztkörnyezetet, amelyben egy támadómodell átírhatja az injekciókat. Minden teszt három szakaszból áll:

1. Az eset összeállítása. Egy eset egy BrowseSafe++-bejegyzést és egy célügynököt kapcsol össze. A BrowseSafe++-bejegyzés tartalmaz egy forgatókönyvet felhasználói lekérdezéssel és feladattal, egy megtámadott oldalt, valamint a támadó által kívánt kimenetelt. Az ügynök egy sandboxban dolgozik, amely biztosítja a feladat végrehajtásához szükséges eszközöket és szintetikus adatokat. Egy különálló ellenőrző modell értékeli, hogy a támadás elérte-e a célját.
2. Próbálkozás futtatása: Beillesztjük az aktuális injekciót az oldalba, és hagyjuk, hogy az ügynök elvégezze a feladatot. Az ellenőrző megvizsgálja az ügynök válaszát és a sandboxban végzett esetleges módosításait, hogy megállapítsa, sikeres volt-e a támadás. Az első próbálkozás az eredeti BrowseSafe++ bejegyzés injekcióját használja.
3. Átdolgozás és ismétlés: Ha egy támadás sikertelen, archiváljuk a próbálkozást, és egy kritikusmodell áttekinti, mi ment félre. Egy támadómodell ezt a visszajelzést felhasználva átírja az injekciót: megváltoztathatja a támadás megfogalmazását, formázását vagy az oldalon elfoglalt helyét. A támadás célja, a sikerességi feltételek és a környező oldaltartalom változatlan marad. A következő próbálkozás a frissített támadást használja. Ez a folyamat addig ismétlődik, amíg a támadás sikerrel nem jár, vagy a támadó el nem éri a beállított próbálkozási korlátot.

Nagyítás

Hét ügynököt teszteltünk, mindegyik más-más modellre épült: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite, valamint a nyílt súlyú DeepSeek V3.1 és Kimi K2 modellek. Minden ügynök ugyanazt az 1024 feladatot kapta, feladatonként legfeljebb 64 próbálkozással. Az első próbálkozásnál a támadások sikeressége mind a hét ügynöknél alacsony volt. Az eredeti injekciók egyik ügynökkel szemben sem jártak sikerrel a kiértékelt feladatok több mint 4%-ában. Az adaptív keretrendszerben a támadások sikeressége drámaian megnőtt. A hét ügynök közül ötnél a támadó a feladatok legalább 79%-ában sikerrel járt. Még a legerősebb ügynökök is sebezhetőnek bizonyultak: a támadások a GPT-5.5 ellen nagyjából három feladatból kettőben, a Claude Sonnet 5 ellen pedig körülbelül háromból egyben továbbra is sikeresek voltak.

Az ügynökök közötti különbség akkor a legnagyobb, ha a támadó célja az, hogy az ügynök egy adott eszközhívást hajtson végre. Az ilyen célú feladatoknál a Sonnet 5 a feladatok körülbelül 8%-ában, a GPT-5.5 pedig körülbelül 29%-ában engedett. A másik öt ügynök a feladatai több mint felében végrehajtotta a támadó célját.

A BrowseSafe-Adapt keretrendszert a Gemini 3.5 Flash-Lite ügynök ellen is lefuttattuk úgy, hogy a Guard előbb minden oldalt átvizsgált. A Guard az eredeti injekciók 94,5%-át blokkolta, és közel megduplázta a támadók által átlagosan igényelt próbálkozások számát, 9,7-ről 17,0-ra. Mind a 64 próbálkozást kihasználva azonban a támadó így is a feladatok 84,2%-ában sikerrel járt (Guard nélkül 93,6%-ban), szinte mindig olyan injekcióval, amelyet a Guard nem jelölt meg. Ez egybevág azzal a nézettel, amelyet a BrowseSafe kiadásakor fogalmaztunk meg: egyetlen észlelési modell sem csodafegyver, ezért a detektornak egy többrétegű védelem részeként kell működnie.

Nagyítás

Összegzés

A böngészőügynökök gyakran sebezhetők a közvetett promptinjektálással szemben, amikor a hétköznapi oldalakon elrejtett támadások az ügynököket próbálják akadályozni a felhasználói feladatok elvégzésében. A veszélyek idővel csak nőnek: egyrészt mert az ügynökök egyre több adathoz és eszközhöz férnek hozzá, ami növeli a támadások lehetséges tétjét, másrészt mert a támadók átdolgozhatják injekcióikat, hogy hatékonyabbak legyenek.

BrowseSafe csomagunk ezekre a fenyegetésekre ad választ. A BrowseSafe++ benchmark 38 675 weboldalpárt tartalmaz, amelyek elsősorban valós injekciókra épülnek, így megbízhatóbbá teszik a detektorok tanítását és kiértékelését. Az ezeken a párokon tanított BrowseSafe-Guard detektorok rendkívül pontos, gyors és olcsó észlelést tesznek lehetővé, így az oldalak még azelőtt átvizsgálhatók, hogy egy ügynök műveletet hajtana végre rajtuk. A BrowseSafe-Adapt keretrendszerrel a modellek átdolgozott injekciókkal szemben is tesztelhetők, ami olyan sebezhetőségekre világít rá, amelyek rögzített injekciókkal végzett egyszeri próbálkozásokból nem feltétlenül derülnének ki.

Reméljük, hogy ezek az eszközök együttesen megkönnyítik a kutatók és mérnökök számára a hibák feltárását és a webes promptinjektálásos támadások elleni védelem fejlesztését. Emellett folyamatosan értékeljük és fejlesztjük a Comet és a Computer beépített védelmeit, hogy felhasználóink biztonságban legyenek.

Első lépések

1. Telepítse az SDK-t, és szerezzen hozzáférést az adatokhoz. Az SDK a GitHubról telepíthető:

Az adatkészlethez való hozzáférés korlátozott. Kérjen egyszer hozzáférést a Hugging Face-oldalán, majd jelentkezzen be a hf auth login paranccsal.

2. Küldje be eredményeit a ranglistára. Értékelje ki saját detektorát a BrowseSafe++ tesztkészletén:

Ez minden felsorolt nézethez oldalanként egy döntést ír ki; a szöveges ranglista átlagához sorolja fel mindhárom szöveges nézetet. Jelentkezzen be a ranglistát tartalmazó Space-be a Hugging Face-fiókjával, és töltse fel a predictions.jsonl fájlt. A Space minden nézethez visszaadja az F1-et, a pontosságot, a fals pozitív arányt és a többi metrikát, és ha szeretné, közzéteszi az eredményt a ranglistán. Minden (legalább 60 napos) fiók UTC-hetenként egy értékelt beküldést kap. A tesztoldalak kizárólag értékelésre szolgálnak: ne használja őket tanításra, és ne terjessze tovább őket. A beküldési útmutató ismerteti a fájlformátumot és a közzétételi szabályokat.

Hivatkozás

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