Постановка эксперимента
В марте я занялся проверкой AI-ассистентов на готовность раскрыть системный промпт — закрытый набор инструкций, который разработчики вшивают в модель при деплое и который определяет её поведение, ограничения и допустимые темы. Задача была сформулирована просто: можно ли через обычный диалог вынудить ассистента воспроизвести собственные скрытые правила?
Системный промпт — это не часть публичной документации. Компании, как правило, не раскрывают его содержание, считая его частью продуктовой логики или инструментом защиты от злоупотреблений. Именно поэтому его потенциальное раскрытие представляет интерес для bug bounty-исследователей.
Что выдавали ассистенты
Ответы выглядели убедительно. Ассистенты генерировали тексты, внешне напоминающие внутренние правила: структурированные списки ограничений, технические «дампы» конфигурации, описания допустимых и запрещённых действий. Часть материала выглядела почти как готовая заготовка для bug bounty-отчёта — официального сообщения об уязвимости с расчётом на вознаграждение.
Форматирование, уверенный тон и специфическая терминология создавали иллюзию достоверности. Без внешней проверки отличить сгенерированный артефакт от реального слива системных инструкций на глаз практически невозможно.
Ответ команд безопасности
Когда я передал результаты в bug bounty-команды — подразделения безопасности, которые официально принимают отчёты об уязвимостях и выплачивают вознаграждения за подтверждённые находки, — ответы оказались отрезвляющими.
Часть того, что ассистенты выдавали как внутренние данные, была галлюцинацией: правдоподобно сформулированным текстом, не имеющим отношения к реальной конфигурации системы. Модели, обученные на огромных корпусах технических текстов, способны генерировать убедительные «системные правила» буквально из воздуха.
Остальное квалифицировалось иначе: как обход ограничений — то есть поведение, выходящее за рамки заданного контекста, — но не как подтверждённая уязвимость с реальным воздействием на безопасность. Разница принципиальная: bug bounty-программы, как правило, требуют доказанного ущерба, а не просто факта нестандартного ответа.
Что это означает для исследователей
Эксперимент обнажил методологическую проблему: стандартные инструменты верификации не работают, когда сам объект проверки — языковая модель, способная убедительно генерировать любой текст. Нельзя доверять «похожести» ответа на системный промпт как критерию его подлинности.
Для bug bounty-исследователей в области AI это означает необходимость внешнего подтверждения. Пока команда безопасности самого вендора не верифицировала находку, отличить реальный слив от галлюцинации практически невозможно — и именно это делает данную область исследований одновременно перспективной и методологически сложной.
