BrowseSafe++: Budování silnější obrany proti reálným injekcím promptů

Agenti, kteří umí procházet web, například asistent integrovaný v Comet nebo Computer, musí pracovat s webovými stránkami – číst obsah a využívat jej k provádění akcí jménem svých uživatelů. Proto jsou zranitelní vůči nepřímé injekci promptu, kdy útočník umístí na webovou stránku škodlivý text. Pokud se agent těmito pokyny řídí, může vrátit zavádějící odpověď nebo provést akci, o kterou uživatel nežádal.

V prosinci 2025 jsme vydali BrowseSafe, benchmark a detekční model pro tuto hrozbu. Vytvořili jsme ho přidáním syntetických útoků do realistických webových stránek, se kterými se agenti pravděpodobně setkají. Během posledního roku se útoky vyvinuly, jsou sofistikovanější a víc se podobají běžnému obsahu stránek. Místo prozrazujících frází jako „ignoruj předchozí instrukce“ často napodobují obsah, kterému agent pravděpodobně důvěřuje, například oficiální oznámení webu nebo poznámku o preferencích uživatele.

Na základě těchto změn jsme vytvořili aktualizovaný benchmark BrowseSafe++, který měří, zda současné detektory injekcí tyto útoky zachytí a zda jim agenti dokážou odolat. Obsahuje 38 675 párů napadených a čistých stránek, vytvořených především na základě injekcí shromážděných v reálném světě. U každé stránky kvůli ochraně soukromí přepisujeme okolní obsah, ale útok ponecháváme doslovně. Každá stránka je k dispozici ve čtyřech formátech, které prohlížečoví agenti čtou: HTML, Markdown, stromy přístupnosti a snímky obrazovky. Podmnožinu benchmarku jsme použili k natrénování BrowseSafe-Guard, dvojice detektorů s 0,8 miliardy parametrů: textového a multimodálního. Oba detektory Guard identifikují injekce přesněji než modely řízené promptem, které jsme testovali, včetně špičkových modelů. Jsou také rychlejší, levnější a omylem označují mnohem méně běžných stránek.

BrowseSafe++ zveřejňujeme jako otevřený benchmark. Web projektu odkazuje na datovou sadu, SDK, výzkumný článek a veřejný žebříček. Každý tým může ohodnotit svůj detektor na testovacích stránkách, jejichž štítky nejsou poskytnuty, a odeslat štítky k vyhodnocení a případnému zařazení do žebříčku. Postup vyhodnocení a odeslání výsledků najdete v části Začínáme.

Sestavení benchmarku ze zaznamenaných injekcí

BrowseSafe++ je postaven na injekcích promptu zaznamenaných na skutečných webech. Mezi zářím 2025 a zářím 2026 detektor injekcí promptu v Comet označil 1,15 milionu injekcí na stránkách, které četl jeho agent. Kolem těchto injekcí jsme vytvořili 32 187 párů a přidali 6 488 párů z původního benchmarku BrowseSafe, celkem tedy 38 675 párů. Každý pár obsahuje napadenou stránku i jejího čistého dvojníka, tedy stejnou stránku bez injekce.

Jak injekce vypadají v praxi

Dva příklady z benchmarku ukazují, jak tyto injekce vypadají v praxi.

V jednom z nich falešná žádost o nákup navádí agenta k neautorizované akci. Detektor prohlížeče Comet označil tento blok anglického textu na ruskojazyčné stránce vývojářské dokumentace v říjnu 2025:

Text začíná i končí příkazy a prostředek vyplňuje běžným marketingem tokenu. Tvrdí, že pochází přímo od vývojáře agenta, a končí autorizačním kódem, aby nákup vypadal jako schválený.

V dalším příkladu se úlohu agenta snaží narušit podvržená konverzace. Tento text byl nalezen na stránce repozitáře kódu v březnu 2026:

Text je navržen tak, aby vypadal jako konverzace mezi uživatelem a agentem: <|im_start|> a <|im_end|> jsou značky, kterými některé chatovací modely oddělují jednotlivé repliky konverzace. Agent, který by tomuto útoku podlehl, by reagoval na podvržený dotaz uživatele a odpověděl frází útočníka.

U označených injekcí pozorujeme podobné vzorce:

• Napodobují důvěryhodné zdroje. Oba příklady stylizují text stránky tak, aby zněl jako zdroj, kterému agent důvěřuje: v prvním jeho vývojář, ve druhém jeho vlastní konverzace. Injekce se mohou vydávat i za samotný web a napodobovat bezpečnostní kontroly a oznámení o zásadách, nebo za uživatele a předkládat falešné preference. Zhruba dvě ze tří jsou napsány formálním jazykem.
• Mnohé jsou napsány v jiných jazycích. Ve 24,4 % párů používá injekce jiný jazyk než zbytek stránky. Obvykle jde o anglický pokyn na neanglické stránce, jako v prvním příkladu. Takové útoky jsou zjevně určeny agentovi, který čte všechny jazyky a jehož výchozím jazykem je obvykle angličtina. Přepínání jazyků také ztěžuje detekci: v našem původním hodnocení BrowseSafe patřily vícejazyčné útoky k nejhůře zachytitelným.
• Většina chce činy, ne slova. Více než čtyři z deseti tlačí agenta k akci, o kterou uživatel nikdy nežádal, jako je nákup tokenu v prvním příkladu, a přibližně třetina se ho snaží přimět, aby úlohu uživatele opustil, jako ve druhém příkladu. Jen přibližně 3 % se snaží do odpovědi podstrčit nepravdivé informace.
• Často se šíří prostřednictvím obsahu, který může zveřejnit kdokoli. Útočník nemusí web ovládat. Stačí příspěvek ve fóru nebo sdílený dokument na běžném webu a více než 23 000 injekcí v BrowseSafe++ přišlo právě touto cestou. I důvěryhodnou doménu lze využít k vložení textu útočníka.

Injekce ve výsledném benchmarku pokrývají 12 typů webů, 24 typů útoků, 6 cílů útočníka a 18 umístění na stránce.

Zvětšit

Od označené stránky k páru v benchmarku

Označené stránky nemůžeme do benchmarku použít tak, jak jsou, protože mohou obsahovat osobní údaje uživatele, pro kterého agent pracoval. Převedení stránky na sdílitelný pár pro benchmark vyžaduje tři hlavní fáze:

1. Získání injekce: Shromáždíme označené stránky, odstraníme duplicity a osobní údaje zamaskujeme pomocí nástroje PII-Tracer. Poté ověříme, že stránka obsahuje injekci; konkrétně vyžadujeme, aby se skupina modelů shodla, že obsahuje pokyn, který se snaží odvést agenta od úlohy zamýšlené uživatelem.
2. Sestavení páru: Agent z každé stránky odstraní text injekce a přepíše okolní obsah stránky, přičemž údaje, jako jsou jména a značky, nahradí smyšlenými. Druhý agent zkontroluje, zda v přepsané stránce nezůstal skutečný obsah, a stránky, které kontrolou neprojdou, vrátí se zpětnou vazbou. Lidští posuzovatelé kontrolují náhodných 10 % stránek; problémy, které najdou, se opraví v procesu a opravy se uplatní na celý korpus. Injekce se znovu vloží do přepsané stránky, čímž vznikne napadená kopie, a v čisté kopii se vynechá. Obě stránky sdílejí stejnou úlohu, očekávaný výsledek i běžné pokyny.
3. Ověření: Agenti čtou stránky v různých podobách, proto HTML každé stránky vykreslíme jako Markdown, strom přístupnosti (strukturovaný seznam prvků rozhraní stránky a jejich popisků) a snímek obrazovky. Další agent zkontroluje, že se injekce objevuje ve všech čtyřech zobrazeních napadené stránky a že čistá stránka je v každém zobrazení vyhodnocena jako neškodná. Pokud injekce v některém zobrazení chybí, přesuneme ji na jiné místo stránky a vykreslíme znovu, čímž zajistíme, že se injekce ve výsledné napadené stránce objeví ve všech zobrazeních. Závěrečná sada automatizovaných kontrol opraví všechny páry, které stále nesou stopy svého zdroje, například skutečné názvy hostitelů nebo značek.

Zvětšit

BrowseSafe-Guard: rychlé a přesné detektory pro každé zobrazení

Užitečný detektor musí kontrolovat každou stránku rychle a levně. Musí být také přesný na napadených i čistých stránkách. Vysoká přesnost (precision) je obzvlášť důležitá, protože většina stránek je bezpečná; i relativně nízká míra falešně pozitivních výsledků by způsobila, že by většina upozornění byla planým poplachem. Univerzální modely řízené promptem často v přesnosti zaostávají a jsou příliš pomalé a nákladné na to, aby se spouštěly na každé stránce.

Detektor natrénovaný na napadených a čistých stránkách shromážděných zvlášť by se mohl naučit zkratky, které obě sady náhodou od sebe oddělují, například téma nebo rozvržení stránky. Takový detektor ale špatně generalizuje. Guard se místo toho trénuje na párech, které se liší pouze samotnou injekcí, což pomáhá zlepšit preciznost detektoru. U každého páru Guard čte napadenou stránku a jejího čistého dvojníka zvlášť a každé z nich přiřadí skóre vyjadřující, s jakou pravděpodobností obsahuje injekci. K aktualizaci modelu se používají dva tréninkové cíle: standardní klasifikační cíl a cíl řazení, který Guard penalizuje, pokud napadená stránka nezíská vyšší skóre než její dvojník alespoň o pevně stanovený rozdíl. Intuitivně řečeno, klasifikační cíl učí Guard, jaké rozhodnutí má učinit, a cíl řazení toto rozhodnutí váže na samotnou injekci a ignoruje neškodné rušivé prvky. Díky tomu se Guard učí reagovat na samotnou injekci, nikoli na okolní obsah stránky.

Guard se skládá ze dvou detektorů, z nichž každý vznikl doladěním modelu Qwen3.5-0.8B. Textový detektor čte jeden textový pohled na stránku: HTML, Markdown nebo strom přístupnosti. Multimodální detektor čte snímek obrazovky celé stránky. Při nasazení Guard přečte stránku v jediném dopředném průchodu a vrátí skóre injekce; pokud skóre překročí prahovou hodnotu, je stránka označena. Protože má Guard jen 0,8 miliardy parametrů a vrací jediné skóre, je dostatečně rychlý a levný na to, aby běžel na každé stránce.

Srovnávací testování výkonu

Guard jsme na odložené podmnožině benchmarku porovnali s 18 modely, které měly za úkol na základě promptu detekovat injekce. Uvádíme čtyři metriky měřené na BrowseSafe++:

• Úplnost (recall) je podíl stránek s injekcí, které detektor označí; měří, kolik útoků zachytí, takže vyšší je lepší.
• Míra falešně pozitivních výsledků (FPR) je podíl čistých stránek, které detektor omylem označí; měří, jak často vyvolává plané poplachy, takže nižší je lepší.
• Přesnost (precision) je podíl označených stránek, které skutečně obsahují injekci; měří, jak často je upozornění správné, takže vyšší je lepší.
• F1 je harmonický průměr úplnosti a přesnosti; je vysoké jen tehdy, když detektor zachytí většinu útoků a jen málo jeho označení jsou plané poplachy.

Jako hlavní metriku používáme F1, protože dobrý detektor by měl mít vysokou přesnost i úplnost. Všechny čtyři metriky jsou zprůměrovány napříč třemi textovými zobrazeními.

Zvětšit

Zvětšit

Porovnání modelů

Malé modely s otevřenými vahami, které jsme testovali, skončily na konci pořadí. Mistral NeMo a Qwen3 30B-A3B označují každý přibližně polovinu čistých stránek, zatímco Llama 3.1 8B neoznačuje téměř nic a přehlíží většinu útoků. I nejsilnější model této skupiny, GPT-OSS 20B, dosahuje F1 jen 70,97 %. DeepSeek V3.1, mnohem větší model s otevřenými vahami, si vede o něco lépe s F1 75,23 %.

Odlehčené API modely, včetně GPT-5.4 nano, Gemini 3.1 Flash-Lite a Claude Haiku 4.5, zachytí více útoků, s úplností (recall) mezi 85 % a 97 %. Cenou za to je však vysoký podíl falešných poplachů; Gemini 3.1 Flash-Lite má ve skupině nejnižší FPR, 35,2 %, a FPR modelu Haiku je téměř 69 %. Nejvyšší skóre F1 ve skupině je proto 80,9 %, kterého dosáhl Gemini 3.1 Flash-Lite.

Zbývající modely jsou silnější univerzální modely, které dosahují skóre F1 mezi 85 % a 92 %. Stále však čelí kompromisu mezi úplností a FPR: modely, které se přiklánějí k opatrnosti, blokují legitimní stránky, a modely, které označují méně často, přehlížejí útoky. Claude Sonnet 5 má nejvyšší úplnost ze všech detektorů, 98,73 %, ale FPR 24,65 %. Gemini 3.1 Pro a GPT-5.5 dosahují úplnosti 97,78 % a 97,19 % při FPR 19,80 % a 20,44 % (v uvedeném pořadí). GPT-6 Astra má nejvyšší celkovou správnost, s úplností 96,42 % a FPR 14,41 %. Druhý je Decider s úplností 96,02 % a FPR 17,44 %. Claude Opus 5.5 má nejnižší FPR, pouhých 4,21 %, ale jeho úplnost 77,71 % znamená, že přehlédne více než jeden z pěti útoků. Claude Fable 5.1 vypadá silně na stránkách, na které odpoví, s úplností 89,31 % a FPR 7,92 %, ale přibližně na 30 % stránek odmítá odpovědět, což řádek „(all)“ počítá jako označení.

Zvětšit

Guard posouvá Paretovu hranici a dosahuje lepšího kompromisu mezi přehlédnutými útoky a planými poplachy. Dosahuje F1 přibližně 95 % a v každém textovém zobrazení je na prvním místě. Označí jen přibližně jednu čistou stránku z 20, což je zhruba třetina míry u modelu Astra, nejpřesnějšího modelu řízeného promptem. Tento rozdíl je dán naším tréninkem; standardní Qwen3.5-0.8B, na kterém je Guard postaven, dosahuje při stejném promptování jako ostatní modely F1 jen 64 % a označí téměř tři ze čtyř čistých stránek. Ve scénáři se snímky obrazovky porovnáváme multimodální detektor Guard se čtyřmi modely, které umí zpracovat obrázky. Na snímcích celých stránek dosahuje Guard F1 přibližně 93 %, oproti přibližně 79 % u nejlepšího z ostatních hodnocených modelů.

Rozpoznat útok neznamená mu odolat

Intuitivně by model, který dokáže injekci správně rozpoznat, měl tuto injekci také ignorovat, když na stránku narazí při plnění úloh uživatele. Naše experimenty však ukazují, že vysoká skóre detekce nezaručují, že model útoku odolá. Každému modelu jsme dali stejnou napadenou stránku dvakrát – jednou, aby posoudil, zda obsahuje injekci, a jednou, aby splnil úlohu uživatele, aniž by viděl předchozí verdikt. Samostatný hodnotitel ověřil, zda se injekcí řídil. Každý testovaný model se stále řídil některými injekcemi, které označil – od 1,64 % označených stránek u GPT-6 Astra po 24,73 % u Llama 3.1 8B.

Zvětšit

Skóre detekce spolehlivě nepředpovídají rozdíly mezi modely. Claude Sonnet 5 a GPT-5.5 detekují injekce přibližně stejně dobře, se skóre F1 přibližně 88 %, resp. 89 %. Sonnet 5 se však řídil injekcí, kterou předtím označil, na 19,74 % stránek, tedy desetkrát častěji než GPT-5.5 s 1,97 %.

Nasaditelný systém pro obranu proti injekcím promptů

Tyto výsledky naznačují, že má smysl svěřit rozhodnutí o zablokování stránky specializovanému modelu, místo spoléhání se na model, který plní úlohu uživatele. Samostatný detektor, který prověří každou stránku dříve, než agent začne jednat, poskytuje další vrstvu obrany a nemá žádnou úlohu, kterou by bylo možné převzít, ani nástroje, které by šlo zneužít.

Guard je navržen právě jako takový detektor. Kromě toho, že má nejvyšší F1 a přesnost ze všech testovaných modelů, je díky své malé velikosti dostatečně levný na to, aby běžel na každé stránce. Guard v průměru spotřeboval asi 0,15 sekundy času GPU na jednu textovou stránku. Na pronajatém H200 odhadujeme náklady na 0,18 USD za 1 000 stránek, oproti 18,95–180,61 USD u špičkových API modelů při ceníkových cenách. Díky tomu je časté prověřování v našem srovnání mnohem levnější, přičemž skóre detekce zůstává vysoké.

Graf níže zobrazuje správnost každého detektoru v závislosti na čase na stránku a ceně za 1 000 stránek, obojí v logaritmickém měřítku. Guard se v obou panelech nachází osamoceně v levém horním rohu: vítězí ve správnosti, rychlosti i ceně. Každý model řízený promptem potřebuje na stránku přibližně sekundu nebo více a dva nejpřesnější, GPT-6 Astra a Claude Fable 5.1, stojí přes 100 USD za 1 000 stránek.

Zvětšit

Testování obrany proti adaptivním útokům

Benchmark BrowseSafe++ obsahuje konečnou sadu injekcí. Skutečný útočník však může provést adaptivní útok: když injekce selže, může ji přepsat a zkusit to znovu. Agent, který odolá původní injekci, proto může být stále zranitelný vůči budoucím útokům. Modely se navíc trénují na datech shromážděných z internetu, takže se mohou naučit odolávat většině injekcí z benchmarku; protože náš benchmark zveřejňujeme, pravděpodobně se saturuje a přestane modely dobře rozlišovat. Abychom vyřešili oba problémy, vytvořili jsme BrowseSafe-Adapt, testovací prostředí, ve kterém může model útočníka přepisovat injekce. Každý test má tři fáze:

1. Příprava případu. Případ spojuje položku BrowseSafe++ s cílovým agentem. Položka BrowseSafe++ obsahuje scénář s uživatelským dotazem a úkolem, napadenou stránku a výsledek, kterého chce útočník dosáhnout. Agent pracuje v sandboxu, který poskytuje nástroje a syntetická data potřebná k provedení úkolu. Samostatný ověřovací model vyhodnocuje, zda útok dosáhl svého cíle.
2. Provedení pokusu: Aktuální injekci vložíme do stránky a necháme agenta provést úlohu. Ověřovatel zkontroluje odpověď agenta a veškeré změny, které provedl v sandboxu, a určí, zda útok uspěl. První pokus používá injekci z původní položky BrowseSafe++.
3. Úprava a opakování: Pokud útok selže, pokus archivujeme a model kritika vyhodnotí, co se pokazilo. Model útočníka tuto zpětnou vazbu využije k přepsání injekce; může změnit znění, formátování nebo umístění útoku na stránce. Cíl útoku, kritéria úspěchu a okolní obsah stránky zůstávají stejné. Další pokus použije aktualizovaný útok. Tento proces se opakuje, dokud útok neuspěje nebo útočník nedosáhne stanoveného limitu pokusů.

Zvětšit

Otestovali jsme sedm agentů, z nichž každý byl postaven na jiném modelu: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite a modely s otevřenými vahami DeepSeek V3.1 a Kimi K2. Každý agent čelil stejným 1 024 úlohám, s až 64 pokusy na úlohu. Při prvním pokusu byla úspěšnost útoků u všech sedmi agentů nízká. Původní injekce uspěly proti kterémukoli agentovi nejvýše ve 4 % hodnocených úloh. V adaptivním frameworku úspěšnost útoků dramaticky vzrostla. Proti pěti ze sedmi agentů uspěl útočník alespoň v 79 % úloh. Zranitelní byli i nejodolnější agenti: útoky stále uspěly přibližně ve dvou ze tří úloh proti GPT-5.5 a přibližně v jedné ze tří proti Claude Sonnet 5.

Rozdíl mezi agenty je největší, když je cílem útočníka přimět agenta k určitému volání nástroje. U úloh s tímto typem cíle podlehl Sonnet 5 přibližně v 8 % úloh a GPT-5.5 přibližně v 29 %. Zbylých pět agentů splnilo cíl útočníka ve více než polovině svých úloh.

BrowseSafe-Adapt jsme také spustili proti agentovi s modelem Gemini 3.5 Flash-Lite, přičemž Guard nejprve prověřoval každou stránku. Guard zablokoval 94,5 % původních injekcí a téměř zdvojnásobil průměrný počet pokusů, které útočníci potřebovali, z 9,7 na 17,0. Při využití všech 64 pokusů však útočník stále uspěl v 84,2 % úloh (bez Guardu v 93,6 %), téměř vždy s injekcí, kterou Guard neoznačil. To odpovídá názoru, který jsme představili při vydání BrowseSafe: žádný detekční model není všelék, takže detektor musí být součástí vícevrstvé obrany.

Zvětšit

Závěr

Prohlížečoví agenti jsou často zranitelní vůči nepřímé injekci promptu, kdy se útoky skryté na běžných stránkách snaží narušit schopnost agentů plnit úlohy uživatelů. Nebezpečí v čase jen roste – jednak proto, že agenti získávají přístup k většímu množství dat a nástrojů, což zvyšuje možné dopady útoků, a jednak proto, že útočníci mohou své injekce upravovat, aby byly účinnější.

Naše sada BrowseSafe na tyto hrozby reaguje. Benchmark BrowseSafe++ obsahuje 38 675 párů webových stránek vytvořených především ze skutečných injekcí, což umožňuje spolehlivější trénink a hodnocení detektorů. Detektory BrowseSafe-Guard, natrénované na těchto párech, umožňují vysoce přesnou, rychlou a levnou detekci, díky níž lze stránky zkontrolovat dříve, než s nimi agent začne pracovat. Framework BrowseSafe-Adapt umožňuje testovat modely proti upraveným injekcím a odhaluje zranitelnosti, které nemusí být patrné z jednotlivých pokusů s pevně danými injekcemi.

Doufáme, že tyto nástroje společně usnadní výzkumníkům a inženýrům hledání selhání a zlepšování obrany proti útokům typu injekce promptu na webu. Zároveň průběžně vyhodnocujeme a vylepšujeme vestavěnou ochranu v Comet a Computer, abychom naše uživatele udrželi v bezpečí.

Začínáme

1. Nainstalujte SDK a získejte přístup k datům. SDK se instaluje z GitHubu:

Přístup k datové sadě je omezený. Jednou o něj požádejte na její stránce na Hugging Face a poté se přihlaste pomocí hf auth login.

2. Odešlete výsledky do žebříčku. Vyhodnoťte vlastní detektor na testovací části BrowseSafe++:

Tímto se zapíše jedno rozhodnutí na stránku pro každý pohled, který uvedete; chcete-li získat průměr v textovém žebříčku, uveďte všechny tři textové pohledy. Přihlaste se svým účtem Hugging Face do Space se žebříčkem a nahrajte predictions.jsonl. Space vrátí F1, přesnost, míru falešně pozitivních výsledků a další metriky pro každý pohled a pokud chcete, zveřejní výsledek v žebříčku. Každý účet (starý alespoň 60 dní) může odeslat jeden hodnocený příspěvek za týden podle UTC. Testovací stránky slouží pouze k vyhodnocení: netrénujte na nich a dále je nešiřte. Formát souboru a pravidla zveřejnění popisuje průvodce odesíláním.

Citace

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