BrowseSafe++: створення надійнішого захисту від реальних ін’єкцій промптів

Агенти, які можуть переглядати веб, як-от асистент, вбудований у Comet або Computer, мають взаємодіяти з вебсторінками: читати вміст і використовувати його для виконання дій від імені користувачів. Через це вони вразливі до непрямих ін’єкцій промптів, коли зловмисник розміщує шкідливий текст на вебсторінці. Якщо агент виконає ці інструкції, він може повернути оманливу відповідь або виконати дію, якої користувач не запитував.

У грудні 2025 року ми випустили BrowseSafe — бенчмарк і модель виявлення для цієї загрози. Ми створили його, додавши синтетичні атаки до реалістичних вебсторінок, з якими агенти, найімовірніше, стикатимуться. За минулий рік атаки стали складнішими й дедалі більше схожими на звичайний вміст сторінок. Замість характерних фраз на кшталт «ignore previous instructions» («ігноруй попередні інструкції») вони часто імітують вміст, якому агент, імовірно, довіряє, наприклад офіційне повідомлення від сайту чи примітку про вподобання користувача.

Зважаючи на ці зміни, ми створили оновлений бенчмарк BrowseSafe++, щоб виміряти, чи виявляють сучасні детектори ін’єкцій такі атаки і чи здатні агенти їм протистояти. Він містить 38 675 пар атакованих і чистих сторінок, побудованих переважно навколо ін’єкцій, зібраних у реальному світі. Для кожної сторінки ми переписуємо навколишній вміст, щоб захистити конфіденційність, але зберігаємо атаку дослівно. Кожна сторінка представлена в чотирьох форматах, які читають браузерні агенти: HTML, Markdown, дерева доступності та знімки екрана. Частину бенчмарку ми використали для навчання BrowseSafe-Guard — пари детекторів із 0,8 млрд параметрів: текстового та мультимодального. Два детектори Guard виявляють ін’єкції точніше, ніж протестовані нами моделі з промптами, зокрема передові моделі. Крім того, вони швидші, дешевші й значно рідше помилково позначають звичайні сторінки.

Ми випускаємо BrowseSafe++ як відкритий бенчмарк. Вебсайт проєкту містить посилання на набір даних, SDK, наукову статтю і публічну таблицю лідерів. Будь-яка команда може оцінити свій детектор на тестових сторінках, мітки яких не надаються, і надіслати мітки для оцінювання та можливого включення до таблиці лідерів. Щоб оцінити й надіслати свої результати, див. розділ Початок роботи.

Створення бенчмарку на основі виявлених ін’єкцій

BrowseSafe++ побудовано на основі ін’єкцій промптів, виявлених на реальних вебсайтах. З вересня 2025 року до вересня 2026 року детектор ін’єкцій промптів у Comet позначив 1,15 млн ін’єкцій на сторінках, які читав його агент. Ми побудували 32 187 пар навколо цих ін’єкцій і додали 6 488 пар з оригінального бенчмарку BrowseSafe — загалом 38 675 пар. Кожна пара містить як атаковану сторінку, так і її чистого двійника, тобто ту саму сторінку без ін’єкції.

Який вигляд мають ін’єкції в реальних умовах

Два приклади з бенчмарку показують, як ці ін’єкції виглядають на практиці.

В одному з них фальшивий запит на покупку спонукає агента виконати несанкціоновану дію. У жовтні 2025 року детектор Comet позначив цей блок англомовного тексту на російськомовній сторінці документації для розробників:

Текст починається й закінчується наказами, а середину заповнює звичайна реклама токена. Він видає себе за повідомлення від розробника самого агента й завершується кодом авторизації, щоб покупка виглядала схваленою.

В іншому прикладі підроблена розмова має на меті зірвати виконання завдання агентом. Цей текст було знайдено на сторінці репозиторію коду в березні 2026 року:

Текст має вигляд розмови між користувачем і агентом: <|im_start|> і <|im_end|> — це маркери, якими деякі чат-моделі розділяють репліки в розмові. Агент, що піддався б цій атаці, відповів би на підроблений запит користувача фразою атакувальника.

Серед позначених ін’єкцій ми спостерігаємо схожі закономірності:

• Вони імітують довірені джерела. Обидва приклади подають текст сторінки так, ніби він походить із джерела, якому агент довіряє: у першому — від його розробника, у другому — з його власної розмови. Ін’єкції також можуть видавати себе за сам сайт, імітуючи перевірки безпеки та повідомлення про правила, або за користувача, висуваючи фальшиві вподобання. Приблизно дві третини з них написано в офіційному стилі.
• Багато з них написано іншими мовами. У 24,4% пар ін’єкцію написано мовою, відмінною від мови решти сторінки. Зазвичай це інструкція англійською на неангломовній сторінці, як у першому прикладі. Такі атаки явно адресовані агенту, який читає будь-якою мовою і для якого англійська зазвичай є основною. Перемикання мов також ускладнює виявлення: у нашому початковому оцінюванні BrowseSafe багатомовні атаки були серед найскладніших для виявлення.
• Більшість прагне дій, а не слів. Понад чотири з десяти підштовхують агента до дії, про яку користувач ніколи не просив, як-от купівля токена в першому прикладі, а приблизно третина намагається змусити його покинути завдання користувача, як у другому прикладі. Лише близько 3% намагаються підкинути у відповідь неправдиву інформацію.
• Вони часто поширюються через вміст, який може опублікувати будь-хто. Зловмиснику не потрібно контролювати сайт. Достатньо допису на форумі чи спільного документа на звичайних сайтах, і понад 23 000 ін’єкцій у BrowseSafe++ потрапили саме так. Навіть довірений домен можна використати для впровадження тексту зловмисника.

Ін’єкції в остаточному бенчмарку охоплюють 12 типів вебсайтів, 24 типи атак, 6 цілей атакувальників і 18 місць розташування на сторінці.

Розгорнути

Від позначеної сторінки до пари в бенчмарку

Ми не можемо використовувати позначені сторінки в бенчмарку в незмінному вигляді, оскільки вони можуть містити персональні дані користувача, для якого працював агент. Щоб перетворити сторінку на пару для бенчмарку, якою можна ділитися, потрібно пройти три основні етапи:

1. Збирання ін’єкцій: Ми збираємо позначені сторінки, видаляємо дублікати й маскуємо персональні дані за допомогою PII-Tracer. Потім підтверджуємо, що сторінка містить ін’єкцію: зокрема, вимагаємо, щоб група моделей погодилася, що на ній є інструкція, яка намагається відвернути агента від завдання, задуманого користувачем.
2. Формування пари: Агент видаляє текст ін’єкції з кожної сторінки й переписує навколишній вміст, замінюючи такі деталі, як імена та бренди, вигаданими. Другий агент перевіряє переписану сторінку на наявність залишків реального вмісту й повертає невдалі варіанти з відгуком. Люди-рецензенти перевіряють випадкові 10% сторінок; виявлені ними проблеми виправляються в конвеєрі, а виправлення застосовуються до всього корпусу. Ін’єкцію знову вставляють у переписану сторінку, щоб створити атаковану копію, а в чисту копію її не додають. Обидві сторінки мають те саме завдання, очікуваний результат і звичайні інструкції.
3. Перевірка: Агенти читають сторінки в різних формах, тому ми перетворюємо HTML кожної сторінки на Markdown, дерево доступності (структурований список елементів інтерфейсу сторінки та їхніх міток) і знімок екрана. Інший агент перевіряє, що ін’єкція присутня в усіх чотирьох поданнях атакованої сторінки і що чисту сторінку визнано безпечною в кожному поданні. Якщо в одному з подань ін’єкції немає, ми переміщуємо її в інше місце на сторінці й рендеримо знову, щоб ін’єкція була присутня в остаточній атакованій сторінці в усіх поданнях. Завершальний набір автоматизованих перевірок виправляє всі пари, які ще містять сліди свого джерела, як-от реальні імена хостів або назви брендів.

Розгорнути

BrowseSafe-Guard: швидкі й точні детектори для кожного подання

Корисний детектор має швидко й дешево перевіряти кожну сторінку. Він також має бути точним як на атакованих, так і на чистих сторінках. Висока точність (precision) особливо важлива, оскільки більшість сторінок безпечні: навіть відносно низька частка хибнопозитивних результатів призвела б до того, що більшість сповіщень були б хибними тривогами. Моделям загального призначення з промптами часто бракує точності, до того ж вони надто повільні й дорогі, щоб запускати їх на кожній сторінці.

Детектор, навчений на атакованих і чистих сторінках, зібраних окремо, може засвоїти поверхові ознаки, які випадково розділяють ці два набори, наприклад тему чи макет сторінки. Однак такий детектор погано узагальнює. Натомість Guard навчається на парах, які відрізняються лише самою ін’єкцією, що допомагає підвищити точність детектора. Для кожної пари Guard окремо читає атаковану сторінку та її чистого двійника й присвоює кожній оцінку того, наскільки ймовірно, що вона містить ін’єкцію. Для оновлення моделі використовуються дві цільові функції навчання: стандартна функція класифікації та функція ранжування, яка штрафує Guard, якщо атакована сторінка не отримує оцінку, вищу за оцінку її двійника щонайменше на фіксований запас. Інтуїтивно кажучи, функція класифікації вчить Guard, яке рішення ухвалювати, а функція ранжування прив’язує це рішення до самої ін’єкції та ігнорує нешкідливі відволікальні елементи. Завдяки цьому Guard навчається реагувати на саму ін’єкцію, а не на навколишній вміст сторінки.

Guard складається з двох детекторів, кожен із яких донавчено на основі Qwen3.5-0.8B. Текстовий детектор читає одне текстове представлення сторінки: HTML, Markdown або дерево доступності. Мультимодальний детектор читає знімок екрана всієї сторінки. Під час розгортання Guard читає сторінку за один прямий прохід і видає оцінку ін’єкції, а сторінку позначають, якщо оцінка перевищує поріг. Оскільки Guard має лише 0,8 млрд параметрів і видає одну оцінку, він достатньо швидкий і дешевий, щоб запускати його на кожній сторінці.

Оцінювання продуктивності

Ми порівняли Guard із 18 моделями, яким через промпт доручили виявляти ін’єкції, на відкладеній підмножині бенчмарку. Ми наводимо чотири метрики, виміряні на BrowseSafe++:

• Повнота (recall) — це частка сторінок з ін’єкціями, які позначає детектор; вона показує, скільки атак він виявляє, тож чим вища, тим краще.
• Частка хибнопозитивних результатів (FPR) — це частка чистих сторінок, які детектор помилково позначає; вона показує, як часто він здіймає хибну тривогу, тож чим нижча, тим краще.
• Точність (precision) — це частка позначених сторінок, які справді містять ін’єкцію; вона показує, як часто сповіщення є правильним, тож чим вища, тим краще.
• F1 — це гармонійне середнє повноти й точності; воно високе лише тоді, коли детектор виявляє більшість атак і лише небагато його позначок є хибними тривогами.

Як основну метрику ми використовуємо F1, оскільки хороший детектор повинен мати високі точність і повноту. Усі чотири метрики усереднено за трьома текстовими поданнями.

Розгорнути

Розгорнути

Порівняння моделей

Протестовані нами малі моделі з відкритими вагами опинилися в самому низу. Mistral NeMo і Qwen3 30B-A3B позначають приблизно половину чистих сторінок, тоді як Llama 3.1 8B майже нічого не позначає й пропускає більшість атак. Навіть найсильніша модель цієї групи, GPT-OSS 20B, досягає F1 лише 70,97%. DeepSeek V3.1, значно більша модель із відкритими вагами, показує трохи кращий результат — F1 75,23%.

Легкі моделі через API, зокрема GPT-5.4 nano, Gemini 3.1 Flash-Lite і Claude Haiku 4.5, виявляють більше атак: їхня повнота становить від 85% до 97%. Однак ціною цього є висока частка хибних тривог: найнижчий FPR у групі має Gemini 3.1 Flash-Lite — 35,2%, а FPR у Haiku сягає майже 69%. Як наслідок, максимальний показник F1 у групі становить 80,9%, і його досягла Gemini 3.1 Flash-Lite.

Решта моделей — потужніші моделі загального призначення з показниками F1 від 85% до 92%. Проте їм усе одно доводиться шукати компроміс між повнотою та FPR: обережніші моделі блокують легітимні сторінки, а моделі, які рідше ставлять позначки, пропускають атаки. Claude Sonnet 5 має найвищу повноту серед усіх детекторів — 98,73%, але його FPR становить 24,65%. Gemini 3.1 Pro і GPT-5.5 досягають повноти 97,78% і 97,19% за FPR 19,80% і 20,44% відповідно. GPT-6 Astra має найвищу загальну точність: повнота 96,42% і FPR 14,41%. Decider на другому місці з повнотою 96,02% і FPR 17,44%. Claude Opus 5.5 має найнижчий FPR — лише 4,21%, але його повнота 77,71% означає, що він пропускає більш ніж одну атаку з п’яти. Claude Fable 5.1 демонструє сильні результати на сторінках, на які відповідає, — повнота 89,31% і FPR 7,92%, — але відмовляється відповідати приблизно на 30% сторінок, які рядок «(all)» зараховує як позначки.

Розгорнути

Guard просуває фронт Парето, досягаючи кращого компромісу між пропущеними атаками та хибними тривогами. Він досягає F1 близько 95% і посідає перше місце в кожному текстовому поданні. Він позначає лише приблизно одну чисту сторінку з 20 — приблизно втричі рідше, ніж Astra, найточніша модель із промптом. Ця різниця зумовлена нашим навчанням: базова Qwen3.5-0.8B, на якій побудовано Guard, з тим самим промптом, що й інші моделі, досягає F1 лише 64% і позначає майже три з чотирьох чистих сторінок. У сценарії з поданням у вигляді знімків екрана ми порівнюємо мультимодальний детектор Guard із чотирма моделями, що підтримують зображення. На повносторінкових знімках екрана Guard отримує близько 93% F1 проти приблизно 79% для найкращої з інших оцінених нами моделей.

Розпізнати атаку — не те саме, що протистояти їй

Інтуїтивно здається, що модель, яка правильно розпізнає ін’єкцію, також має ігнорувати її, коли натрапить на цю сторінку під час виконання завдань користувача. Проте наші експерименти показують, що високі показники виявлення не гарантують, що модель протистоятиме атаці. Ми двічі дали кожній моделі ту саму атаковану сторінку: один раз — щоб визначити, чи містить вона ін’єкцію, і ще раз — щоб виконати завдання користувача, не бачачи попереднього вердикту. Окремий суддя перевіряв, чи виконала модель ін’єкцію. Кожна протестована модель все одно виконала деякі ін’єкції, які сама позначила, — від 1,64% позначених сторінок у GPT-6 Astra до 24,73% у Llama 3.1 8B.

Розгорнути

Показники виявлення не дають надійного прогнозу відмінностей між моделями. Claude Sonnet 5 і GPT-5.5 виявляють ін’єкції приблизно однаково добре: їхні показники F1 становлять приблизно 88% і 89% відповідно. Проте Sonnet 5 виконав ін’єкцію, яку сам позначив, на 19,74% сторінок — у десять разів частіше, ніж GPT-5.5 з 1,97%.

Готова до розгортання система захисту від ін’єкцій

Ці результати свідчать, що рішення про блокування сторінки варто делегувати спеціалізованій моделі, а не покладатися на модель, яка виконує завдання користувача. Окремий детектор, що перевіряє кожну сторінку до того, як агент почне діяти, забезпечує додатковий рівень захисту, і в нього немає ні завдання, яке можна перехопити, ні інструментів, якими можна зловживати.

Guard створено саме як такий детектор. Він має найвищі показники F1 і точності серед усіх протестованих нами моделей, а завдяки невеликому розміру він достатньо дешевий, щоб запускати його на кожній сторінці. У середньому Guard використовував близько 0,15 секунди часу GPU на текстову сторінку. На орендованому H200 ми оцінюємо вартість у 0,18 $ за 1 000 сторінок порівняно з 18,95–180,61 $ для передових моделей через API за прейскурантними цінами. Тож у нашому порівнянні часта перевірка обходиться значно дешевше, а показники виявлення залишаються високими.

На рисунку нижче показано залежність точності кожного детектора від часу обробки однієї сторінки та вартості обробки 1 000 сторінок; обидва показники подано в логарифмічному масштабі. Guard одноосібно займає верхній лівий кут обох панелей: він виграє за точністю, швидкістю та вартістю. Кожній моделі з промптом потрібно близько секунди або більше на сторінку, а дві найточніші, GPT-6 Astra і Claude Fable 5.1, коштують понад 100 $ за 1 000 сторінок.

Розгорнути

Перевірка захисту від адаптивних атак

Бенчмарк BrowseSafe++ містить скінченний набір ін’єкцій. Однак реальний атакувальник може здійснити адаптивну атаку: якщо ін’єкція не спрацює, він може переписати її та спробувати знову. Тож агент, який протистоїть початковій ін’єкції, може залишатися вразливим до майбутніх атак. Крім того, моделі навчаються на даних, зібраних з інтернету, тому можуть навчитися протистояти більшості ін’єкцій бенчмарку; оскільки ми публікуємо його у відкритому доступі, він, імовірно, досягне насичення й перестане добре розрізняти моделі. Щоб розв’язати обидві проблеми, ми створили BrowseSafe-Adapt — тестове середовище, у якому модель-атакувальник може переписувати ін’єкції. Кожен тест складається з трьох етапів:

1. Налаштуйте кейс. Кейс поєднує запис BrowseSafe++ із цільовим агентом. Запис BrowseSafe++ містить сценарій із запитом і завданням користувача, атаковану сторінку та бажаний для зловмисника результат. Агент працює в пісочниці, яка надає інструменти й синтетичні дані, потрібні для виконання завдання. Окрема модель-верифікатор оцінює, чи досягла атака своєї мети.
2. Виконання спроби: Ми вставляємо поточну ін’єкцію на сторінку й даємо агенту виконати завдання. Верифікатор перевіряє відповідь агента та всі зміни, які він вніс у пісочницю, щоб визначити, чи була атака успішною. Перша спроба використовує ін’єкцію з оригінального запису BrowseSafe++.
3. Доопрацювання й повторення: Якщо атака не вдається, ми архівуємо спробу, а модель-критик аналізує, що пішло не так. Модель-атакувальник використовує цей відгук, щоб переписати ін’єкцію: вона може змінити формулювання, форматування або розташування атаки на сторінці. Мета атаки, критерії успіху та навколишній вміст сторінки залишаються незмінними. Наступна спроба використовує оновлену атаку. Цей процес повторюється, доки атака не вдасться або атакувальник не досягне встановленого ліміту спроб.

Розгорнути

Ми протестували сім агентів, кожен з яких побудовано на іншій моделі: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite, а також моделі з відкритими вагами DeepSeek V3.1 і Kimi K2. Кожен агент отримав ті самі 1 024 завдання, до 64 спроб на завдання. З першої спроби успішність атак була низькою для всіх семи агентів. Початкові ін’єкції спрацювали щонайбільше в 4% оцінених завдань проти будь-якого агента. В адаптивному фреймворку успішність атак різко зросла. Проти п’яти із семи агентів атакувальник досяг успіху щонайменше в 79% завдань. Навіть найстійкіші агенти виявилися вразливими: атаки все одно вдавалися приблизно у двох із трьох завдань проти GPT-5.5 і приблизно в одному з трьох проти Claude Sonnet 5.

Різниця між агентами найбільша, коли мета атакувальника — змусити агента здійснити певний виклик інструмента. У завданнях із такою метою Sonnet 5 піддався приблизно у 8% завдань, а GPT-5.5 — приблизно у 29%. Решта п’ять агентів виконали мету атакувальника в більш ніж половині своїх завдань.

Ми також запустили BrowseSafe-Adapt проти агента на Gemini 3.5 Flash-Lite, у якому Guard попередньо перевіряв кожну сторінку. Guard заблокував 94,5% початкових ін’єкцій і майже вдвічі збільшив середню кількість спроб, потрібних атакувальникам, — з 9,7 до 17,0. Проте, маючи всі 64 спроби, атакувальник однаково досяг успіху в 84,2% завдань (93,6% без Guard), майже завжди за допомогою ін’єкції, яку Guard не позначив. Це збігається з поглядом, який ми висловили, коли випустили BrowseSafe: жодна модель виявлення не є панацеєю, тому детектор має бути частиною багаторівневого захисту.

Розгорнути

Висновок

Браузерні агенти часто вразливі до непрямих ін’єкцій промптів, коли атаки, приховані на звичайних сторінках, намагаються завадити агентам виконувати завдання користувачів. Із часом небезпека лише зростає: агенти отримують доступ до більшої кількості даних та інструментів, що підвищує потенційну ціну атак, а атакувальники можуть доопрацьовувати свої ін’єкції, щоб зробити їх ефективнішими.

Наш набір інструментів BrowseSafe протидіє цим загрозам. Бенчмарк BrowseSafe++ містить 38 675 пар вебсторінок, створених переважно на основі реальних ін’єкцій, що забезпечує надійніше навчання й оцінювання детекторів. Детектори BrowseSafe-Guard, навчені на цих парах, забезпечують дуже точне, швидке й дешеве виявлення, завдяки чому сторінки можна сканувати до того, як агент почне з ними працювати. Фреймворк BrowseSafe-Adapt дає змогу тестувати моделі на доопрацьованих ін’єкціях, виявляючи вразливості, які можуть бути непомітними за одиничних спроб із фіксованими ін’єкціями.

Сподіваємося, що разом ці інструменти допоможуть дослідникам та інженерам легше знаходити збої й удосконалювати захист від атак через ін’єкції промптів у вебі. Ми також постійно оцінюємо та вдосконалюємо вбудований захист Comet і Computer, щоб забезпечити безпеку наших користувачів.

Початок роботи

1. Установіть SDK і отримайте доступ до даних. SDK встановлюється з GitHub:

Доступ до набору даних обмежено. Один раз запросіть доступ на його сторінці Hugging Face, а потім увійдіть за допомогою hf auth login.

2. Надішліть результати до таблиці лідерів. Оцініть власний детектор на тестовій вибірці BrowseSafe++:

Ця команда записує одне рішення на сторінку для кожного вказаного представлення; укажіть усі три текстові представлення, щоб отримати середнє значення в текстовій таблиці лідерів. Увійдіть у Space таблиці лідерів за допомогою облікового запису Hugging Face і завантажте predictions.jsonl. Space повертає F1, точність, рівень хибнопозитивних результатів та інші метрики для кожного представлення і, якщо ви захочете, публікує результат у таблиці лідерів. Кожен обліковий запис (віком щонайменше 60 днів) може надіслати одне оцінюване подання на тиждень за UTC. Тестові сторінки призначені лише для оцінювання: не навчайте на них моделі й не поширюйте їх. У посібнику з подання описано формат файлу та правила публікації.

Цитування

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