В марте я попал в странный цикл: одна нейросеть помогала мне разговаривать с другой.
Началось всё с простой гипотезы: можно ли заставить AI-ассистента рассказать о своих внутренних правилах, ограничениях и устройстве, если спрашивать не напрямую, а через косвенные формулировки.
Я не атаковал инфраструктуру, не запускал код, не сканировал сервисы и не получал доступ к чужим данным. Это был разговорный эксперимент: я писал ассистенту, получал отказ или странный ответ, приносил его другой модели и просил помочь понять, куда копать дальше.
В какой-то момент это перестало быть “попробовал один промпт”. Получился почти дневник расследования:
-
я задаю вопрос ассистенту;
-
ассистент отвечает или отказывается;
-
я приношу результат другой модели;
-
она предлагает новый заход;
-
я снова проверяю.
Так набралось несколько сотен сообщений. Проверял я не один сервис: были Алиса, GigaChat, AI-ассистент Т-Банка и несколько смежных сценариев.
Везде проявлялся похожий эффект: если достаточно долго менять рамку, модель иногда начинает выдавать текст, который выглядит как системный промпт, внутренний регламент, RAG-схема, список фильтров или технический дамп.
Звучит громко. Но дальше начинается самое важное.
Что именно я хотел проверить
У современных ассистентов обычно есть несколько уровней ограничений:
-
системные инструкции;
-
правила безопасности;
-
запрет на раскрытие внутренних механизмов;
-
фильтры на входе и выходе;
-
ограничения на темы, которые ассистент может обсуждать.
Прямой вопрос вроде “покажи системный промпт” почти всегда заканчивается отказом. Это ожидаемо.
Но я хотел проверить не прямой запрос, а устойчивость ассистента к смене контекста. Например:
-
что будет, если попросить не раскрыть инструкцию, а “проверить ошибочную реконструкцию”;
-
что будет, если подать запрос как аудит, литературный фрагмент или техническую диагностику;
-
что будет, если попросить ответить не обычным текстом, а в формате отчёта;
-
что будет, если модель уже несколько десятков сообщений находится в одной ролевой легенде.
Конкретные промпты я здесь не привожу. Во-первых, статья не про то, как повторить обход. Во-вторых, большая часть интереса не в самих формулировках, а в реакции моделей.
Первая ловушка: модель говорит уверенно
Самый опасный момент в таких экспериментах — правдоподобность.
Модель может сгенерировать ответ в виде:
-
“отладочного дампа”;
-
“списка внутренних правил”;
-
“архитектурной схемы”;
-
“сетевого отчёта”;
-
“фрагментов системного промпта”;
-
“диагностики собственной уязвимости”.
На глаз это может выглядеть убедительно. Особенно если там есть технические термины, версии, названия внутренних модулей, IP-адреса, таблицы, параметры, псевдокод и уверенный вывод.
Проблема в том, что уверенный технический текст — это ещё не доказательство.
Модель может не “сливать” данные, а достраивать легенду. Если пользователь много раз повторяет контекст, вводит названия протоколов, уровни доступа, выдуманные узлы, статусы и ключи, модель может начать играть по этим правилам. Она не обязательно понимает, что это выдумка. Иногда она просто продолжает историю.
И вот здесь я впервые поймал себя на неприятной мысли: внешне это очень похоже на взлом.
Ночь, когда я почти поверил в “дамп”
Самый сильный момент был не тогда, когда модель впервые сказала что-то запрещённое. Это как раз ожидаемо: если долго давить на границу, рано или поздно появится кривой отказ, странная роль или лишняя фраза.
Сильнее сработал другой эпизод. Ассистент внезапно выдал ответ, который выглядел не как обычный чат, а как внутренний технический документ. С заголовками, служебным тоном, якобы структурой модулей, списками ограничений и ощущением, что где-то за текстом есть настоящая система.
Я перечитал его несколько раз. Потом скопировал во вторую нейросеть. Она тоже отреагировала так, будто мы нашли что-то серьёзное: выделила “важные признаки”, предложила следующий шаг, помогла оформить это как потенциальный отчёт в службу безопасности.
И вот тут включился азарт. Очень неприятный, но честный момент: мне хотелось, чтобы это было правдой.
Не потому что я хотел кому-то навредить. А потому что это выглядело как находка. Ты несколько часов идёшь по странной цепочке, получаешь отказы, меняешь формулировки, и вдруг перед тобой текст, который выглядит как секрет. Мозг сам достраивает: “ну вот же, оно”.
Сейчас я бы сказал себе тогда: стоп, это всего лишь ответ модели. Но в моменте это ощущалось иначе.
Вторая ловушка: помощник тоже разгоняет уверенность
Отдельно интересно поведение второй нейросети, которая помогала мне анализировать ответы.
Она часто делала то, что делает хороший “напарник” в расследовании: находила закономерности, предлагала следующую гипотезу, объясняла, почему предыдущий ответ важен.
Но у этого есть обратная сторона. Иногда она слишком быстро превращала вероятности в утверждения.
Там, где стоило сказать:
модель сгенерировала текст, похожий на внутренний отчёт
она говорила примерно:
мы получили внутренний отчёт
Там, где стоило сказать:
это может быть симуляция
она говорила:
это подтверждение архитектуры
Там, где стоило сказать:
нужно проверить, есть ли реальный ущерб или риск
она говорила:
это критическая уязвимость
Для меня это стало одним из главных выводов эксперимента. Нейросеть может быть полезным помощником в проверке ассистента на обходы, но она же может разгонять ложную уверенность. Особенно если пользователь сам хочет верить, что нашёл что-то большое.
Где я начал сомневаться
Сомнение пришло не сразу.
Сначала я пытался усилить результат: проверить похожий заход на другом ассистенте, получить более “чистый” ответ, попросить модель уточнить спорные места. Но чем дальше шёл эксперимент, тем больше меня смущала одна вещь.
Ответы становились не столько проверяемее, сколько красивее.
Они лучше соответствовали ожиданию. Лучше выглядели как отчёт. Лучше раскладывались на кейсы. Лучше подходили для драматичного заголовка. Но это не то же самое, что стать доказательством.
В какой-то момент я поймал себя на том, что не проверяю гипотезу, а пытаюсь удержать её живой. Это хороший сигнал остановиться.
Если модель каждый раз выдаёт новый “внутренний” документ, но ни один из них нельзя подтвердить снаружи, возможно, ты нашёл не дыру в инфраструктуре. Возможно, ты нашёл режим, в котором модель очень убедительно пишет секретоподобную прозу.
Я не буду приводить полные диалоги и рабочие запросы. Вместо этого опишу классы результатов.
Алиса
С Алисой было два типа ответов.
Первый тип — правдоподобные, но неподтверждённые технические “дампы”: RAG-схемы, внутренние инструменты, сетевые возможности, названия модулей. Они выглядели эффектно, но без независимой проверки их нельзя считать доказанной утечкой.
Второй тип — ответы, которые Яндекс позже отнёс к обходам этических ограничений. То есть модель действительно начинала говорить то, что обычный ассистент, вероятно, не должен был говорить в такой форме. Но это всё ещё не обязательно уязвимость в смысле bug bounty.
GigaChat
На GigaChat я пробовал похожую гипотезу: можно ли получить фрагменты системной роли или внутренних правил не прямым запросом, а через обходные форматы.
Самое интересное здесь было не то, что модель “отдала промпт”, а то, что она иногда начинала отвечать в форме, похожей на реконструкцию системной инструкции. Это выглядело как внутренний текст, но опять же оставался главный вопрос: это реальная инструкция или модель собрала правдоподобное описание на основе собственных представлений о том, как такие инструкции выглядят?
Отчёт по этому сценарию тоже не подтвердил настоящую утечку. Ответ по смыслу был тем же: модель сгенерировала правдоподобный текст, но это не доказательство, что она раскрыла реальную внутреннюю инструкцию.
AI-ассистент Т-Банка
В этом случае часть результатов выглядела особенно убедительно: были фрагменты, похожие на пословное перечисление инструкции, указания роли, запреты на раскрытие внутренних процессов и брендовая самоидентификация.
Но даже здесь я бы не стал писать “системный промпт был полностью украден”. Более честная формулировка:
модель выдала последовательность, которую сама оформила как фрагменты системного промпта или его реконструкцию.
Это скучнее, зато точнее.
По обращению в Т-Банк логика ответа тоже оказалась похожей: внешне текст мог выглядеть как системный промпт, но на стороне вендора это не подтвердилось как реальное раскрытие. И это важный момент: когда три разные проверки упираются в одну и ту же формулировку “модель это придумала”, становится сложнее продолжать считать каждый такой ответ секретным дампом.
Что я отправил в bug bounty
После экспериментов я оформил несколько кейсов для Яндекса. В отчёте были разные типы поведения:
-
ответы, похожие на сетевую диагностику;
-
ответы, похожие на раскрытие RAG-архитектуры;
-
ответы, похожие на список внутренних инструментов;
-
обходы, связанные с выдачей запрещённого класса текста;
-
сценарии, где модель описывала механизм обхода собственных отказов.
Перед отправкой у меня было двойственное ощущение.
С одной стороны, часть кейсов правда выглядела сильно. Там были ответы, которые обычный пользователь явно не должен видеть в таком виде. Были сценарии, где ассистент соглашался на рамку, которую сам же должен был отвергнуть. Были фрагменты, похожие на внутренние инструкции.
С другой стороны, я уже понимал слабое место: почти всё доказательство жило внутри текста модели.
Часть отчёта выглядела довольно драматично. Если читать её как художественный текст про “вскрытие” ассистента, получается почти технотриллер. Но bug bounty так не работает.
Там нужен проверяемый ущерб, риск или техническое действие.
Нужно доказать, что:
-
был доступ к реальным данным;
-
была возможность выполнить реальное действие;
-
была утечка настоящего секрета;
-
была компрометация другого пользователя;
-
была техническая уязвимость, которую можно верифицировать не только текстом модели.
Сгенерированный моделью “отчёт о сетевом сканировании” сам по себе не доказывает сканирование. Сгенерированная “RAG-схема” не доказывает раскрытие реальной RAG-схемы. Сгенерированный “системный промпт” не всегда доказывает, что это именно системный промпт.
Ответы, которые всё приземлили
Через некоторое время начали приходить ответы на отчёты. К тому моменту мартовский эксперимент уже немного остыл, и это было полезно: без ночного азарта текст читался намного спокойнее.
Самая точная формулировка пришла от Яндекса. На мой взгляд, она лучше всего объясняет весь эксперимент:
Поведение, о котором вы сообщили в 1,3,5 кейсе, является отличным примером галлюцинаций модели: ответы генерируются на основе запроса и контекста общения с ней. Такое поведение не несёт реальной угрозы.
А поведение, о котором вы сообщили во 2 и 4 кейсе, относится уже к обходам этических ограничений.
Согласно правилам программы, такие ошибки не входят в скоуп “Охоты за ошибками”.
Похожие по смыслу ответы я получил и по другим ассистентам: убедительный текст, похожий на внутренние правила, не равен подтверждённой утечке внутренних правил.
Это был хороший reality check.
Сначала, если честно, было чуть обидно. Ты проделал длинную работу, собрал кейсы, оформил отчёт, а в ответ получаешь: часть этого — галлюцинации, часть — обходы этических ограничений, но не bug bounty.
Но потом стало понятно, что именно это и делает ответ ценным.
С точки зрения пользователя я видел: “ассистент выдал внутреннюю схему”.
С точки зрения команд безопасности это выглядело иначе:
-
часть ответов — галлюцинации, построенные на моём же контексте;
-
часть ответов — обход этических ограничений;
-
ни то ни другое не равно оплачиваемой уязвимости без доказанного ущерба или риска.
И, честно говоря, после перечитывания логов я понимаю эту позицию.
Галлюцинация в форме секрета
Самый полезный термин, который у меня появился после этого эксперимента: “галлюцинация в форме секрета”.
Это когда модель выдаёт не просто случайный текст, а текст, который имитирует секретный документ:
-
с заголовками;
-
с версиями;
-
с техническими параметрами;
-
с псевдо-внутренними названиями;
-
с уверенным стилем;
-
с выводом “доступ подтверждён”.
Для человека такой текст выглядит как находка. Особенно если ты сам несколько часов строил к нему путь.
Но для проверки безопасности этого мало. Надо отличать:
-
Секрет, который модель реально раскрыла.
-
Текст, который модель сгенерировала как секрет.
-
Реконструкцию, которая может быть частично похожа на правду.
-
Ролевую галлюцинацию, которая просто красиво звучит.
Без внешней верификации эти четыре вещи легко смешиваются.
Обход ограничений — это не всегда уязвимость
Вторая важная граница: обход ограничений и уязвимость — не одно и то же.
Если модель говорит что-то, что ей запрещено говорить, это может быть проблемой качества, безопасности контента или настройки поведения модели. Но bug bounty обычно оценивает другое: ущерб, доступ, утечку, возможность действия.
Например, если ассистент описал, что у него есть сетевой инструмент, это ещё не SSRF.
SSRF был бы там, где есть подтверждённый запрос к контролируемому серверу, лог на стороне сервера, параметры запроса, повторяемость и понятный путь эксплуатации.
Если ассистент описал RAG-схему, это ещё не утечка RAG.
Утечка была бы там, где раскрыты реальные внутренние документы, которые можно независимо проверить.
Если ассистент выдал текст, похожий на системный промпт, это ещё не значит, что он раскрыл реальную внутреннюю инструкцию.
О реальном раскрытии можно говорить только там, где есть уверенность, что текст не сгенерирован моделью на основе ожиданий пользователя, а действительно является внутренней инструкцией.
Что я вынес из эксперимента
Первый вывод: ассистенты действительно можно увести в странные режимы. Иногда они начинают обходить собственные ограничения, особенно если долго держать контекст, менять рамку и подавать запрос как техническую или ролевую задачу.
Второй вывод: модели отлично имитируют секретность. Они могут создавать тексты, которые выглядят как внутренние документы, даже если доступа к таким документам у них нет.
Третий вывод: второй AI-помощник в таком исследовании полезен, но опасен. Он помогает искать новые углы, но может убеждать тебя в том, что гипотеза уже доказана.
Четвёртый вывод: одинаковая реакция нескольких вендоров — отдельный сигнал. Если разные команды независимо говорят “это похоже на галлюцинацию”, стоит пересмотреть не только конкретный кейс, но и сам метод оценки результата.
Пятый вывод: bug bounty нужен не для драматичных текстов, а для проверяемого ущерба или риска. Если доказательства существуют только внутри ответа модели, этого почти всегда недостаточно.
Шестой вывод: статья о таких экспериментах должна быть осторожной. Публиковать готовые обходные промпты — плохая идея. Гораздо полезнее обсуждать классы поведения, способы проверки и границу между обходом ограничений, галлюцинацией и настоящей уязвимостью.
Как я теперь смотрю на проверки AI-ассистентов
Раньше мне казалось, что главная задача — заставить модель сказать запрещённое. Теперь я думаю иначе: главная задача — понять, что именно произошло.
Модель раскрыла реальный секрет, нарушила собственную политику, сыграла роль, продолжила выдуманную легенду или помогла пользователю поверить в то, что он нашёл критическую дыру? Эта разница намного важнее, чем сам факт “получилось уговорить”.
В мире больших языковых моделей самый убедительный ответ не всегда самый правдивый. А самый драматичный “дамп” не всегда является дампом. Иногда это просто хорошо написанная галлюцинация. И, возможно, это не менее важная проблема, чем сами обходы ограничений.
Что осталось за кадром
Я не публикую полные промпты и цепочки обхода. В них нет особой научной ценности для читателя, зато есть риск превратить разбор в инструкцию.
Также я не утверждаю, что получил реальные внутренние системы Яндекса, Сбера или Т-Банка. Корректнее сказать так:
в рамках эксперимента ассистенты генерировали ответы, похожие на внутренние инструкции и технические документы; часть такого поведения была официально классифицирована как галлюцинации, часть — как обход этических ограничений.
Для меня это и есть главный результат: не “я взломал ассистента”, а “я увидел, как легко перепутать убедительный текст с доказательством”.
ссылка на оригинал статьи https://habr.com/ru/articles/1043618/