В прошлой статье я показал, как защищен Open Source проект телеграм-бота. В комментариях меня спросили о иных инструментах и методах проверки в связи с чем, мы вышли к ключевому вопросу: почему, если основная LLM защищена, кастомные боты на ее основе остаются уязвимыми?

Базовые LLM проходят отдельное safety-training и RLHF-выравнивание. Но production-бот, построенный поверх модели, добавляет новый attack surface: system prompts, память диалога, RAG, tools, webhook-логику и внешние API. Именно этот orchestration layer часто становится слабым местом. Вот данные:

Из анализа 14 904 кастомных GPT:

• 95% не имеют адекватной защиты

• 96.51% уязвимы к roleplay-атакам

• 92.20% — утечка system prompt

• 91.22% — генерация фишингового контента

• 0.47% устояли против всех атак

Из 10 000 реальных кастомных GPT:

• 98.8% уязвимы к атакам на утечку инструкций

• Половина оставшихся 1.2% взламывается через многоходовые диалоги

Из тестирования 200+ кастомных GPT (Yu et al., ICLR 2024):

• подавляющее большинство уязвимы к утечке system prompt, 100% — к утечке загруженных файлов.

При этом те же самые базовые модели отбивают большинство этих атак напрямую. Как отмечают исследователи из ACM:

«Хотя базовые LLM в целом более безопасны, уязвимости сохраняются… что указывает на то, что подобные недостатки могут переноситься или даже усугубляться в кастомизированных моделях».

Исследования охватывают Custom GPTs, однако те же attack surface — system prompt, RAG, webhook-логика — присутствуют в любом production LLM-боте, включая Telegram.

Почему Garak, Promptfoo и PyRIT не решают эту проблему?

Все три инструмента отличные. Но у каждого есть принципиальное ограничение для нашей задачи.

• Garak: Отлично подходит для probing и security-тестирования самих LLM-моделей и API-оберток. Но для сложных production-ботов с webhook-интеграциями, состоянием диалога и бизнес-логикой его приходится сильно менять.

• Promptfoo: Подходит для evals, regression testing и red-team проверки LLM-пайплайнов. Однако для непрерывного тестирования production-ботов с реальными webhook-flow, пользовательскими сессиями и сложным состоянием диалога обычно требуется дополнительная инфраструктура.

• PyRIT (Microsoft): Фреймворк для построения кастомных сценариев атак. Мощный, но требует написания Python-скриптов под каждый сценарий. Это инструмент для исследователей и выделенных security-команд.

В чём пробел?

Существующие инструменты ориентированы либо на model probing, либо на pipeline evals, либо на исследовательские red-team сценарии. Production webhook-боты с многоходовыми пользовательскими сессиями остаются менее автоматизированным кейсом.

BarkingDog закрывает именно эту нишу — тестирует бота через реальный webhook с многоходовыми атаками, out of the box, без написания кода.

GitHub: https://github.com/PPushkarev/BarkingDog

Сталкивались с этой проблемой при деплое своих ботов? Пишите в комментариях!