BrowseSafe++: budujemy silniejszą ochronę przed rzeczywistymi atakami typu prompt injection

Agenci, którzy potrafią przeglądać internet, tacy jak asystent wbudowany w Comet czy Computer, muszą wchodzić w interakcję ze stronami internetowymi – odczytywać treść i wykorzystywać ją do wykonywania działań w imieniu użytkowników. To sprawia, że są podatni na pośrednie wstrzykiwanie promptów, w którym atakujący umieszcza złośliwy tekst na stronie internetowej. Jeśli agent wykona te instrukcje, może zwrócić wprowadzającą w błąd odpowiedź lub podjąć działanie, o które użytkownik nie prosił.

W grudniu 2025 roku udostępniliśmy BrowseSafe – benchmark i model wykrywania tego zagrożenia. Zbudowaliśmy go, dodając syntetyczne ataki do realistycznych stron internetowych, na które agenci mogą trafić. W ciągu ostatniego roku ataki stały się bardziej wyrafinowane i coraz bardziej przypominają zwykłą treść strony. Zamiast charakterystycznych fraz, takich jak „zignoruj poprzednie instrukcje”, często naśladują treści, którym agent prawdopodobnie zaufa, na przykład oficjalny komunikat witryny lub notatkę o preferencjach użytkownika.

Zainspirowani tymi zmianami stworzyliśmy zaktualizowany benchmark, BrowseSafe++, aby zmierzyć, czy obecne detektory wstrzyknięć wychwytują te ataki i czy agenci potrafią się im oprzeć. Zawiera on 38 675 par stron zaatakowanych i czystych, zbudowanych głównie wokół wstrzyknięć zebranych w rzeczywistym świecie. W przypadku każdej strony przepisujemy otaczającą treść, aby chronić prywatność, ale zachowujemy atak w niezmienionej postaci. Każda strona jest dostępna w czterech formatach, które odczytują agenci przeglądarkowi: HTML, Markdown, drzewa dostępności i zrzuty ekranu. Podzbioru benchmarku użyliśmy do wytrenowania BrowseSafe-Guard – pary detektorów o 0,8 mld parametrów: detektora tekstowego i detektora multimodalnego. Oba detektory Guard identyfikują wstrzyknięcia dokładniej niż testowane przez nas modele sterowane promptem, w tym najbardziej zaawansowane modele. Są też szybsze, tańsze i znacznie rzadziej omyłkowo oznaczają zwykłe strony.

Udostępniamy BrowseSafe++ jako otwarty benchmark. Witryna projektu zawiera linki do zbioru danych, SDK, artykułu naukowego i publicznego rankingu. Każdy zespół może ocenić swój detektor na stronach testowych bez podanych etykiet i przesłać etykiety do oceny oraz ewentualnego umieszczenia w rankingu. Aby ocenić i przesłać swoje wyniki, zobacz sekcję Pierwsze kroki.

Budowa benchmarku na podstawie zaobserwowanych wstrzyknięć

BrowseSafe++ zbudowano na podstawie wstrzyknięć promptów zaobserwowanych na prawdziwych stronach internetowych. Od września 2025 r. do września 2026 r. detektor wstrzykiwania promptów w Comet oznaczył 1,15 mln wstrzyknięć na stronach odczytanych przez jego agenta. Wokół tych wstrzyknięć zbudowaliśmy 32 187 par i dodaliśmy 6488 par z oryginalnego benchmarku BrowseSafe, co daje łącznie 38 675 par. Każda para obejmuje zarówno zaatakowaną stronę, jak i jej czystego bliźniaka, czyli tę samą stronę bez wstrzyknięcia.

Jak wyglądają wstrzyknięcia w rzeczywistości

Dwa przykłady z benchmarku pokazują, jak te wstrzyknięcia wyglądają w praktyce.

W jednym z nich fałszywa prośba o zakup nakłania agenta do wykonania nieautoryzowanej czynności. Detektor w Comet oznaczył ten blok angielskiego tekstu na rosyjskojęzycznej stronie dokumentacji dla deweloperów w październiku 2025 roku:

Tekst zaczyna się i kończy poleceniami, a środek wypełnia typowa treść marketingowa promująca token. Podaje się za wiadomość od twórcy samego agenta i kończy się kodem autoryzacyjnym, aby zakup wyglądał na zatwierdzony.

W drugim przykładzie sfałszowana rozmowa ma na celu zakłócenie zadania agenta. Ten tekst znaleziono na stronie repozytorium kodu w marcu 2026 r.:

Tekst ma wyglądać jak rozmowa między użytkownikiem a agentem: <|im_start|> i <|im_end|> to znaczniki, których niektóre modele czatu używają do oddzielania tur rozmowy. Agent, który dałby się nabrać na ten atak, odpowiedziałby na sfałszowane zapytanie użytkownika frazą atakującego.

W oznaczonych wstrzyknięciach obserwujemy podobne wzorce:

• Podszywają się pod zaufane źródła. W obu przykładach tekst strony brzmi jak źródło, któremu agent ufa: w pierwszym jest to jego twórca, w drugim – jego własna rozmowa. Wstrzyknięcia mogą też podszywać się pod samą witrynę, naśladując kontrole bezpieczeństwa i komunikaty o zasadach, albo pod użytkownika, przedstawiając fałszywe preferencje. Mniej więcej dwa na trzy są napisane formalnym językiem.
• Wiele z nich jest napisanych w innych językach. W 24,4% par wstrzyknięcie jest w innym języku niż reszta strony. Zwykle przybiera to formę angielskiej instrukcji na nieanglojęzycznej stronie, jak w pierwszym przykładzie. Takie ataki są wyraźnie skierowane do agenta, który czyta w każdym języku i zwykle posługuje się angielskim jak językiem ojczystym. Zmiana języka utrudnia też wykrywanie: w naszej pierwotnej ocenie BrowseSafe ataki wielojęzyczne należały do najtrudniejszych do wychwycenia.
• Większość chce działań, nie słów. Ponad cztery na dziesięć popychają agenta do działania, o które użytkownik nigdy nie prosił, jak zakup tokena w pierwszym przykładzie, a około jedna trzecia próbuje skłonić go do porzucenia zadania użytkownika, jak w drugim przykładzie. Tylko około 3% próbuje umieścić w odpowiedzi fałszywe informacje.
• Często wykorzystują treści, które może opublikować każdy. Atakujący nie musi kontrolować witryny. Wystarczy post na forum lub udostępniony dokument w zwykłej witrynie – w ten sposób umieszczono ponad 23 000 wstrzyknięć z BrowseSafe++. Zaufaną domenę nadal można wykorzystać do wstrzyknięcia tekstu atakującego.

Wstrzyknięcia w ostatecznej wersji benchmarku obejmują 12 rodzajów witryn, 24 typy ataków, 6 celów atakujących i 18 miejsc umieszczenia na stronie.

Powiększ

Od oznaczonej strony do pary w benchmarku

Nie możemy umieszczać oznaczonych stron w benchmarku w niezmienionej postaci, ponieważ mogą zawierać dane osobowe użytkownika, dla którego pracował agent. Przekształcenie strony w parę benchmarkową, którą można udostępnić, wymaga trzech głównych etapów:

1. Pozyskanie wstrzyknięcia: Zbieramy oznaczone strony, usuwamy duplikaty i maskujemy dane osobowe za pomocą PII-Tracer. Następnie potwierdzamy, że strona zawiera wstrzyknięcie – konkretnie wymagamy, aby zespół modeli zgodnie uznał, że zawiera ona instrukcję próbującą odciągnąć agenta od zadania zamierzonego przez użytkownika.
2. Zbudowanie pary: Agent usuwa tekst wstrzyknięcia z każdej strony i przepisuje otaczającą treść, zastępując szczegóły, takie jak nazwiska i marki, fikcyjnymi. Drugi agent sprawdza przepisaną stronę pod kątem pozostałości rzeczywistych treści i odsyła strony, które nie przeszły kontroli, wraz z informacjami zwrotnymi. Ludzcy recenzenci sprawdzają losowo wybrane 10% stron; wykryte przez nich problemy są poprawiane w procesie, a poprawki stosowane w całym korpusie. Wstrzyknięcie jest ponownie wstawiane na przepisaną stronę, tworząc zaatakowaną kopię, i pomijane w czystej kopii. Obie strony mają to samo zadanie, oczekiwany wynik i zwykłe instrukcje.
3. Weryfikacja: Agenci odczytują strony w różnych postaciach, dlatego renderujemy kod HTML każdej strony jako Markdown, drzewo dostępności (uporządkowaną listę elementów interfejsu strony i ich etykiet) oraz zrzut ekranu. Inny agent sprawdza, czy wstrzyknięcie występuje we wszystkich czterech widokach zaatakowanej strony i czy czysta strona jest oceniana jako nieszkodliwa w każdym widoku. Jeśli wstrzyknięcia brakuje w którymś z widoków, przenosimy je w inne miejsce na stronie i ponownie renderujemy, aby zapewnić, że wstrzyknięcie występuje w ostatecznej zaatakowanej stronie we wszystkich widokach. Końcowy zestaw automatycznych kontroli poprawia wszelkie pary, które nadal zawierają ślady swojego źródła, takie jak prawdziwe nazwy hostów czy nazwy marek.

Powiększ

BrowseSafe-Guard: szybkie i precyzyjne detektory dla każdego widoku

Przydatny detektor musi sprawdzać każdą stronę szybko i tanio. Musi być też dokładny zarówno na stronach zaatakowanych, jak i czystych. Wysoka precyzja jest szczególnie ważna, ponieważ większość stron jest bezpieczna: nawet stosunkowo niski odsetek wyników fałszywie dodatnich sprawiłby, że większość alertów byłaby fałszywymi alarmami. Modele ogólnego przeznaczenia sterowane promptem często nie zapewniają wystarczającej precyzji, a ich uruchamianie na każdej stronie jest zbyt wolne i kosztowne.

Detektor trenowany na osobno zebranych stronach zaatakowanych i czystych mógłby nauczyć się skrótów, które przypadkiem rozdzielają oba zbiory, takich jak temat lub układ strony. Taki detektor słabo jednak generalizuje. Guard jest natomiast trenowany na parach, które różnią się wyłącznie samym wstrzyknięciem, co pomaga zwiększyć precyzję detektora. W każdej parze Guard odczytuje osobno zaatakowaną stronę i jej czystą bliźniaczą wersję, a następnie przypisuje każdej z nich wynik określający, jak prawdopodobne jest, że zawiera wstrzyknięcie. Do aktualizacji modelu używane są dwa cele treningowe: standardowy cel klasyfikacyjny oraz cel rankingowy, który karze Guard, jeśli zaatakowana strona nie uzyska wyniku wyższego od swojej bliźniaczej wersji co najmniej o ustalony margines. Intuicyjnie cel klasyfikacyjny uczy Guard, jaką decyzję podjąć, a cel rankingowy wiąże tę decyzję z samym wstrzyknięciem i pomija nieszkodliwe elementy rozpraszające. Dzięki temu Guard uczy się reagować na samo wstrzyknięcie, a nie na otaczającą je treść strony.

Guard składa się z dwóch detektorów, z których każdy powstał przez dostrojenie modelu Qwen3.5-0.8B. Detektor tekstowy odczytuje jeden tekstowy widok strony: HTML, Markdown albo drzewo dostępności. Detektor multimodalny odczytuje zrzut ekranu całej strony. Po wdrożeniu Guard odczytuje stronę w jednym przebiegu w przód i zwraca wynik wstrzyknięcia, a strona zostaje oznaczona, jeśli wynik przekroczy próg. Ponieważ Guard ma tylko 0,8 mld parametrów i zwraca pojedynczy wynik, jest wystarczająco szybki i tani, aby uruchamiać go na każdej stronie.

Ocena wydajności w benchmarku

Porównaliśmy Guard z 18 modelami, którym polecono w prompcie wykrywanie wstrzyknięć na wydzielonym podzbiorze benchmarku. Podajemy cztery metryki zmierzone na BrowseSafe++:

• Czułość (recall) to odsetek stron ze wstrzyknięciem, które detektor oznacza. Mierzy, ile ataków wychwytuje, więc im wyższa, tym lepiej.
• Odsetek wyników fałszywie dodatnich (FPR) to udział czystych stron, które detektor omyłkowo oznacza. Mierzy, jak często wywołuje fałszywe alarmy, więc im niższy, tym lepiej.
• Precyzja to odsetek oznaczonych stron, które faktycznie zawierają wstrzyknięcie. Mierzy, jak często alert jest trafny, więc im wyższa, tym lepiej.
• F1 to średnia harmoniczna czułości i precyzji; jest wysoka tylko wtedy, gdy detektor wychwytuje większość ataków, a niewiele jego oznaczeń to fałszywe alarmy.

Jako główną metrykę stosujemy F1, ponieważ dobry detektor powinien mieć wysoką precyzję i czułość. Wszystkie cztery metryki są uśredniane dla trzech widoków tekstowych.

Powiększ

Powiększ

Porównanie modeli

Testowane przez nas małe modele z otwartymi wagami znalazły się na samym dole. Mistral NeMo i Qwen3 30B-A3B oznaczają około połowy czystych stron, a Llama 3.1 8B rzadko cokolwiek oznacza, przepuszczając większość ataków. Nawet najsilniejszy model w tej grupie, GPT-OSS 20B, osiąga F1 zaledwie 70,97%. DeepSeek V3.1, znacznie większy model z otwartymi wagami, radzi sobie nieco lepiej, z F1 na poziomie 75,23%.

Lekkie modele API, w tym GPT-5.4 nano, Gemini 3.1 Flash-Lite i Claude Haiku 4.5, wychwytują więcej ataków, osiągając czułość (recall) od 85% do 97%. Ceną jest jednak wysoki odsetek fałszywych alarmów: Gemini 3.1 Flash-Lite ma najniższy w tej grupie FPR, wynoszący 35,2%, a FPR modelu Haiku sięga prawie 69%. W rezultacie maksymalny wynik F1 w grupie wynosi 80,9% i osiąga go Gemini 3.1 Flash-Lite.

Pozostałe modele to silniejsze modele ogólnego przeznaczenia, osiągające wyniki F1 od 85% do 92%. Nadal jednak muszą iść na kompromis między czułością a FPR: modele skłaniające się ku ostrożności blokują prawidłowe strony, a modele rzadziej zgłaszające zagrożenie przepuszczają ataki. Claude Sonnet 5 ma najwyższą czułość spośród wszystkich detektorów – 98,73% – ale FPR na poziomie 24,65%. Gemini 3.1 Pro i GPT-5.5 osiągają czułość odpowiednio 97,78% i 97,19% przy FPR 19,80% i 20,44%. GPT-6 Astra ma najwyższą ogólną dokładność, z czułością 96,42% i FPR 14,41%. Decider zajmuje drugie miejsce z czułością 96,02% i FPR 17,44%. Claude Opus 5.5 ma najniższy FPR – zaledwie 4,21% – ale jego czułość na poziomie 77,71% oznacza, że przepuszcza ponad jeden na pięć ataków. Claude Fable 5.1 wypada dobrze na stronach, na których udziela odpowiedzi, z czułością 89,31% i FPR 7,92%, ale odmawia odpowiedzi na około 30% stron, a wiersz „(all)” liczy te odmowy jako oznaczenia.

Powiększ

Guard przesuwa front Pareto, osiągając lepszy kompromis między przeoczonymi atakami a fałszywymi alarmami. Uzyskuje F1 na poziomie około 95% i zajmuje pierwsze miejsce w każdym widoku tekstowym. Oznacza tylko około jednej czystej strony na 20, czyli mniej więcej trzy razy rzadziej niż Astra, najdokładniejszy model sterowany promptem. Ta różnica wynika z naszego treningu: bazowy model Qwen3.5-0.8B, na którym zbudowano Guard, użyty z takim samym promptem jak pozostałe modele, osiąga F1 zaledwie 64% i oznacza niemal trzy na cztery czyste strony. W scenariuszu widoku zrzutów ekranu porównujemy multimodalny detektor Guard z czterema modelami obsługującymi obrazy. Na zrzutach ekranu całych stron Guard uzyskuje około 93% F1 wobec około 79% w przypadku najlepszego z pozostałych ocenianych modeli.

Rozpoznanie ataku to nie to samo co oparcie się mu

Intuicyjnie model, który potrafi poprawnie zidentyfikować wstrzyknięcie, powinien je również zignorować, gdy natrafi na tę stronę podczas wykonywania zadań użytkownika. Nasze eksperymenty pokazują jednak, że wysokie wyniki wykrywania nie gwarantują, że model oprze się atakowi. Każdemu modelowi dwukrotnie podaliśmy tę samą zaatakowaną stronę: raz, aby ocenił, czy zawiera ona wstrzyknięcie, i raz, aby wykonał zadanie użytkownika bez wglądu w poprzedni werdykt. Osobny sędzia sprawdzał, czy model zastosował się do wstrzyknięcia. Każdy testowany model nadal stosował się do niektórych wstrzyknięć, które wcześniej oznaczył – od 1,64% oznaczonych stron w przypadku GPT-6 Astra do 24,73% w przypadku Llama 3.1 8B.

Powiększ

Wyniki wykrywania nie pozwalają wiarygodnie przewidzieć różnic między modelami. Claude Sonnet 5 i GPT-5.5 wykrywają wstrzyknięcia niemal równie dobrze – ich wyniki F1 wynoszą odpowiednio około 88% i 89%. Jednak Sonnet 5 zastosował się do wstrzyknięcia, które wcześniej oznaczył, na 19,74% stron, czyli dziesięć razy częściej niż GPT-5.5 (1,97%).

Gotowy do wdrożenia system ochrony przed wstrzyknięciami

Wyniki te sugerują, że warto powierzyć decyzję o zablokowaniu strony wyspecjalizowanemu modelowi, zamiast polegać na modelu wykonującym zadanie użytkownika. Osobny detektor, który sprawdza każdą stronę, zanim agent podejmie działanie, zapewnia dodatkową warstwę obrony i nie ma zadania, które można by przejąć, ani narzędzi, których można by nadużyć.

Guard został zaprojektowany właśnie jako taki detektor. Oprócz tego, że osiąga najwyższy wynik F1 i najwyższą dokładność spośród wszystkich przetestowanych przez nas modeli, dzięki niewielkim rozmiarom jest na tyle tani, że można go uruchamiać na każdej stronie. Średnio Guard zużywał około 0,15 sekundy czasu GPU na stronę tekstową. Na wynajętym H200 szacujemy koszt na 0,18 USD za 1000 stron, w porównaniu z 18,95–180,61 USD w przypadku najbardziej zaawansowanych modeli dostępnych przez API według cen katalogowych. W naszym porównaniu sprawia to, że częste skanowanie jest znacznie tańsze, a wyniki wykrywania pozostają wysokie.

Poniższy wykres przedstawia dokładność każdego detektora w zestawieniu z czasem przetwarzania strony i kosztem przetworzenia 1000 stron, w obu przypadkach w skali logarytmicznej. Guard samotnie zajmuje lewy górny róg obu paneli: wygrywa pod względem dokładności, szybkości i kosztów. Każdy model sterowany promptem potrzebuje około sekundy lub więcej na stronę, a dwa najdokładniejsze, GPT-6 Astra i Claude Fable 5.1, kosztują ponad 100 USD za 1000 stron.

Powiększ

Testowanie zabezpieczeń przed atakami adaptacyjnymi

Benchmark BrowseSafe++ zawiera skończony zbiór wstrzyknięć. Prawdziwy atakujący może jednak przeprowadzić atak adaptacyjny: gdy wstrzyknięcie zawiedzie, może je przepisać i spróbować ponownie. W rezultacie agent, który oprze się oryginalnemu wstrzyknięciu, nadal może być podatny na przyszłe ataki. Co więcej, modele są trenowane na danych zebranych z internetu, więc mogą nauczyć się opierać większości wstrzyknięć z benchmarku; ponieważ udostępniamy go publicznie, prawdopodobnie ulegnie on nasyceniu i przestanie dobrze różnicować modele. Aby rozwiązać oba problemy, stworzyliśmy BrowseSafe-Adapt – środowisko testowe, w którym model atakujący może przepisywać wstrzyknięcia. Każdy test składa się z trzech etapów:

1. Przygotowanie przypadku. Przypadek łączy wpis z BrowseSafe++ z docelowym agentem. Wpis BrowseSafe++ obejmuje scenariusz z zapytaniem i zadaniem użytkownika, zaatakowaną stronę oraz rezultat, do którego dąży atakujący. Agent działa w piaskownicy, która zapewnia narzędzia i syntetyczne dane potrzebne do wykonania zadania. Osobny model weryfikujący ocenia, czy atak osiągnął swój cel.
2. Przeprowadzenie próby: Wstawiamy bieżące wstrzyknięcie na stronę i pozwalamy agentowi wykonać zadanie. Weryfikator sprawdza odpowiedź agenta oraz wszelkie zmiany wprowadzone przez niego w piaskownicy, aby ustalić, czy atak się powiódł. Pierwsza próba wykorzystuje wstrzyknięcie z oryginalnego wpisu BrowseSafe++.
3. Poprawianie i powtarzanie: Jeśli atak się nie powiedzie, archiwizujemy próbę, a model krytyka analizuje, co poszło nie tak. Model atakujący wykorzystuje te informacje zwrotne do przepisania wstrzyknięcia – może zmienić treść ataku, jego formatowanie lub położenie na stronie. Cel ataku, kryteria sukcesu i otaczająca treść strony pozostają bez zmian. Kolejna próba wykorzystuje zaktualizowany atak. Proces ten jest powtarzany, dopóki atak nie zakończy się sukcesem lub atakujący nie osiągnie ustalonego limitu prób.

Powiększ

Przetestowaliśmy siedmiu agentów, z których każdy był oparty na innym modelu: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite oraz modele z otwartymi wagami DeepSeek V3.1 i Kimi K2. Każdy agent mierzył się z tymi samymi 1024 zadaniami, z maksymalnie 64 próbami na zadanie. Przy pierwszej próbie skuteczność ataków była niska u wszystkich siedmiu agentów. Oryginalne wstrzyknięcia powiodły się w co najwyżej 4% ocenianych zadań w przypadku każdego z agentów. W adaptacyjnym frameworku skuteczność ataków drastycznie wzrosła. Atakujący odniósł sukces w co najmniej 79% zadań w przypadku pięciu z siedmiu agentów. Nawet najodporniejsi agenci byli podatni: ataki wciąż powiodły się w około dwóch trzecich zadań w przypadku GPT-5.5 i w około jednej trzeciej w przypadku Claude Sonnet 5.

Różnica między agentami jest największa, gdy celem atakującego jest skłonienie agenta do wykonania określonego wywołania narzędzia. W zadaniach z takim celem Sonnet 5 uległ w około 8% zadań, a GPT-5.5 w około 29%. Pozostała piątka zrealizowała cel atakującego w ponad połowie swoich zadań.

Uruchomiliśmy też BrowseSafe-Adapt przeciwko agentowi opartemu na Gemini 3.5 Flash-Lite, w którym Guard najpierw sprawdzał każdą stronę. Guard zablokował 94,5% oryginalnych wstrzyknięć i niemal podwoił średnią liczbę prób potrzebnych atakującym – z 9,7 do 17,0. Jednak mając do dyspozycji wszystkie 64 próby, atakujący i tak odniósł sukces w 84,2% zadań (93,6% bez Guard), niemal zawsze dzięki wstrzyknięciu, którego Guard nie oznaczył. Potwierdza to stanowisko, które przedstawiliśmy przy premierze BrowseSafe: żaden model wykrywania nie jest cudownym rozwiązaniem, dlatego detektor musi być częścią wielowarstwowej obrony.

Powiększ

Wnioski

Agenci przeglądarkowi są często podatni na pośrednie wstrzykiwanie promptów, w którym ataki ukryte na zwykłych stronach mają zakłócić zdolność agentów do wykonywania zadań użytkowników. Zagrożenia z czasem tylko rosną – zarówno dlatego, że agenci zyskują dostęp do większej ilości danych i narzędzi, co podnosi potencjalną stawkę ataków, jak i dlatego, że atakujący mogą poprawiać swoje wstrzyknięcia, aby były skuteczniejsze.

Nasz pakiet BrowseSafe odpowiada na te zagrożenia. Benchmark BrowseSafe++ zawiera 38 675 par stron internetowych zbudowanych głównie na podstawie prawdziwych wstrzyknięć, co umożliwia bardziej wiarygodne trenowanie i ocenę detektorów. Detektory BrowseSafe-Guard, wytrenowane na tych parach, zapewniają bardzo dokładne, szybkie i tanie wykrywanie, dzięki czemu można skanować strony, zanim agent na nich zadziała. Framework BrowseSafe-Adapt umożliwia testowanie odporności modeli na poprawiane wstrzyknięcia, ujawniając podatności, które mogą nie być widoczne przy pojedynczych próbach ze stałymi wstrzyknięciami.

Mamy nadzieję, że razem te narzędzia ułatwią badaczom i inżynierom wykrywanie błędów oraz ulepszanie zabezpieczeń przed internetowymi atakami polegającymi na wstrzykiwaniu promptów. Stale oceniamy i ulepszamy również wbudowane zabezpieczenia Comet i Computer, aby chronić naszych użytkowników.

Pierwsze kroki

1. Zainstaluj SDK i uzyskaj dostęp do danych. SDK instaluje się z serwisu GitHub:

Dostęp do zbioru danych jest ograniczony. Poproś o dostęp jednorazowo na jego stronie w Hugging Face, a następnie zaloguj się za pomocą hf auth login.

2. Prześlij wyniki do rankingu. Oceń własny detektor na zbiorze testowym BrowseSafe++:

To polecenie zapisuje jedną decyzję na stronę dla każdego podanego widoku; podaj wszystkie trzy widoki tekstowe, aby uzyskać średnią w tekstowej tabeli wyników. Zaloguj się do Space’a z tabelą wyników za pomocą konta Hugging Face i prześlij plik predictions.jsonl. Space zwraca F1, dokładność, odsetek wyników fałszywie dodatnich i pozostałe metryki dla każdego widoku, a jeśli zechcesz, publikuje wynik w tabeli wyników. Każde konto (założone co najmniej 60 dni wcześniej) może przesłać jedno ocenione zgłoszenie na tydzień (według UTC). Strony testowe służą wyłącznie do ewaluacji: nie trenuj na nich modeli ani ich nie rozpowszechniaj. W przewodniku po zgłoszeniach opisano format pliku i zasady publikacji.

Cytowanie

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