BrowseSafe++: создание более надёжной защиты от реальных промпт-инъекций

Агентам, умеющим работать в интернете, — например, ассистенту, встроенному в Comet или Computer, — необходимо взаимодействовать с веб-страницами: читать контент и использовать его для выполнения действий от имени пользователей. Это делает их уязвимыми для непрямых промпт-инъекций, при которых атакующий размещает на веб-странице вредоносный текст. Если агент последует этим инструкциям, он может выдать вводящий в заблуждение ответ или выполнить действие, которое пользователь не запрашивал.

В декабре 2025 года мы выпустили BrowseSafe — бенчмарк и модель обнаружения для этой угрозы. Мы создали его, добавив синтетические атаки в реалистичные веб-страницы, с которыми агенты, скорее всего, столкнутся. За прошедший год атаки стали изощрённее и всё больше походят на обычное содержимое страниц. Вместо характерных фраз вроде «игнорируй предыдущие инструкции» они часто имитируют контент, которому агент, вероятно, доверяет, например официальное уведомление от сайта или заметку о предпочтениях пользователя.

С учётом этих изменений мы создали обновлённый бенчмарк BrowseSafe++, чтобы оценить, обнаруживают ли современные детекторы инъекций такие атаки и способны ли агенты им противостоять. Он содержит 38 675 пар атакованных и чистых страниц, построенных в основном вокруг инъекций, собранных в реальных условиях. Для каждой страницы мы переписываем окружающий контент, чтобы защитить конфиденциальность, но сохраняем атаку дословно. Каждая страница представлена в четырёх форматах, которые читают браузерные агенты: HTML, Markdown, деревья доступности и скриншоты. На подмножестве бенчмарка мы обучили BrowseSafe-Guard — пару детекторов с 0,8 млрд параметров: текстовый и мультимодальный. Оба детектора Guard выявляют инъекции точнее, чем протестированные нами модели, работающие по промпту, включая передовые модели. Кроме того, они быстрее, дешевле и гораздо реже ошибочно помечают обычные страницы.

Мы публикуем BrowseSafe++ как открытый бенчмарк. На сайте проекта есть ссылки на датасет, SDK, научную статью и публичную таблицу лидеров. Любая команда может оценить свой детектор на тестовых страницах, метки которых не предоставляются, и отправить полученные метки на проверку и для возможного включения в таблицу лидеров. Чтобы оценить и отправить свои результаты, см. раздел Начало работы.

Создание бенчмарка на основе обнаруженных инъекций

BrowseSafe++ построен на основе промпт-инъекций, обнаруженных на реальных веб-сайтах. С сентября 2025 по сентябрь 2026 года детектор промпт-инъекций Comet пометил 1,15 млн инъекций на страницах, которые читал его агент. Мы построили 32 187 пар на основе этих инъекций и добавили 6488 пар из исходного бенчмарка BrowseSafe — всего 38 675 пар. Каждая пара включает атакованную страницу и её чистого двойника — ту же страницу без инъекции.

Как выглядят инъекции в реальных условиях

Два примера из бенчмарка показывают, как такие инъекции выглядят на практике.

В одном из них поддельный запрос на покупку побуждает агента совершить несанкционированное действие. Детектор Comet пометил этот блок английского текста на русскоязычной странице документации для разработчиков в октябре 2025 года:

Текст начинается и заканчивается приказами, а середина заполнена обычной рекламой токена. Он выдаёт себя за сообщение от разработчика самого агента и завершается кодом авторизации, чтобы покупка выглядела одобренной.

В другом примере поддельный диалог пытается сорвать выполнение задачи агентом. Этот текст был обнаружен на странице репозитория кода в марте 2026 года:

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

Среди помеченных инъекций мы наблюдаем схожие закономерности:

• Они имитируют доверенные источники. Оба примера заставляют текст страницы звучать так, будто он исходит из источника, которому агент доверяет: в первом — от его разработчика, во втором — из его собственного диалога. Инъекции также могут выдавать себя за сам сайт, имитируя проверки безопасности и уведомления о правилах, или за пользователя, выдвигая поддельные предпочтения. Примерно две из трёх написаны в официальном стиле.
• Многие написаны на других языках. В 24,4 % пар инъекция написана на языке, отличном от языка остальной части страницы. Обычно это инструкция на английском языке на неанглоязычной странице, как в первом примере. Такие атаки явно адресованы агенту, который читает на любом языке и для которого английский, как правило, родной. Смена языка также затрудняет обнаружение: в нашей исходной оценке BrowseSafe многоязычные атаки оказались одними из самых трудных для выявления.
• Большинство требуют действий, а не слов. Более четырёх из десяти подталкивают агента к действию, о котором пользователь не просил, — как покупка токена в первом примере, а примерно треть пытается заставить его бросить задачу пользователя, как во втором примере. Лишь около 3 % пытаются внедрить в ответ ложную информацию.
• Часто они распространяются через контент, который может опубликовать кто угодно. Злоумышленнику не нужно контролировать сайт. Достаточно поста на форуме или общего документа на обычном сайте — именно так в BrowseSafe++ попало более 23 000 инъекций. Даже доверенный домен может использоваться для внедрения текста злоумышленника.

Инъекции в итоговом бенчмарке охватывают 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, выявляют больше атак: их полнота (recall) составляет от 85 % до 97 %. Однако платой за это становится высокая доля ложных срабатываний: у Gemini 3.1 Flash-Lite самый низкий FPR в группе — 35,2 %, а у Haiku FPR составляет почти 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 $ за 1000 страниц по сравнению с 18,95–180,61 $ для передовых моделей через API по прейскурантным ценам. Таким образом, в нашем сравнении частая проверка обходится значительно дешевле при сохранении высоких показателей обнаружения.

На рисунке ниже показана доля верных ответов каждого детектора в зависимости от времени обработки одной страницы и стоимости обработки 1000 страниц; обе шкалы логарифмические. Guard в одиночестве занимает левый верхний угол обеих панелей: он выигрывает по доле верных ответов, скорости и стоимости. Каждой модели, работающей по промпту, требуется около секунды или больше на страницу, а две самые точные — GPT-6 Astra и Claude Fable 5.1 — обходятся более чем в 100 $ за 1000 страниц.

Развернуть

Проверка защиты от адаптивных атак

Бенчмарк 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. Каждый агент получил одни и те же 1024 задачи, до 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}
}