Из API научились вытаскивать чужие цепочки рассуждений

10 августа 2026 года вышла работа, показывающая неприятное свойство зашифрованных цепочек рассуждений: блоки, которые провайдер возвращает клиенту для продолжения диалога, переносимы между сессиями, пользователями и разными моделями внутри одной экосистемы. Подставив такой блок в более слабую модель того же провайдера, исследователи извлекали исходные рассуждения сильной модели дословно. Приём продемонстрирован на моделях OpenAI, Anthropic и Google. В размеченной выборке оказались 367 фрагментов персональных данных и 182 учётные записи, включая ключи API и пароли — разбор проводился в изолированном окружении. Для тех, кто отправляет запросы через API, вывод простой и неприятный: то, что попало в промпт, может пережить вашу сессию.

Разберём механику, границы проблемы и что стоит поменять в своём коде сегодня.

Как устроены зашифрованные рассуждения

Современные модели с рассуждением тратят токены на внутренний ход мысли до того, как выдать ответ. Провайдер обычно не показывает этот текст клиенту — вместо него возвращается зашифрованный блок.

Блок нужен для продолжения диалога: клиент прикладывает его к следующему запросу, и модель не пересчитывает рассуждение заново. Механика разумная и экономит и время, и деньги.

Проблема в свойстве, которое из неё вытекает. Блок должен быть понятен провайдеру при следующем обращении — значит он расшифровывается на его стороне. А раз так, вопрос лишь в том, какая именно модель провайдера согласится его расшифровать и что покажет наружу.

Что показала работа

По описанию исследования, блоки оказались взаимозаменяемы внутри экосистемы одного провайдера: между сессиями, между пользователями и между разными моделями.

Схема извлечения выглядит так:

Разбор опубликовал Саймон Уиллисон 11 августа, после чего тема разошлась по инженерным сообществам.

Самое важное в цифрах: в размеченной выборке нашлись 367 фрагментов персональных данных и 182 учётные записи, среди них ключи API и пароли. Авторы подчёркивают, что работа велась в изолированном окружении.

Откуда в рассуждениях берутся ключи и персональные данные

Ответ прозаичный: их туда кладут сами разработчики.

Модель рассуждает о том, что получила. Если в промпт попал кусок конфигурации с ключом, модель может его процитировать в ходе рассуждения. Если в контекст ушла выгрузка из базы с персональными данными, рассуждение будет опираться на них и повторять фрагменты.

Три типовых источника, которые встречаются чаще всего:

Отладочный контекст. «Вот моя конфигурация, помоги найти ошибку» — и в конфигурации живой токен.

Дамп ответа стороннего сервиса. Разработчик передаёт модели сырой JSON от внутреннего API, а там заголовки авторизации или идентификаторы клиентов.

История диалога целиком. Секрет мелькнул один раз на третьем ходу и дальше едет в модель при каждом обращении до конца сессии.

Что это значит для вашей интеграции

Три следствия, ранжированных по тому, насколько срочно ими заниматься.

Секретам не место в промпте. Правило звучит банально ровно до момента, когда оказывается, что оно нарушается в отладочных сценариях, в скриптах разовой обработки и в шаблонах автоматизации, которые писали «на один раз».

Блоки рассуждений — тоже данные. Если ваш сервис хранит их для продолжения диалога, они наследуют чувствительность исходного контекста. Хранить их дольше, чем живёт диалог, смысла нет. Передавать между пользователями — тем более.

Ключи, которые могли попасть в промпты, стоит ротировать. Это дешёвая операция с понятным эффектом, и повод для неё теперь документирован.

Отдельно про наш контур: в KeyDealer содержимое запросов не сохраняется, остаются только данные, без которых не посчитать расход и не разобрать ошибку — токены, модель, сумма, статус и время. Что именно хранится, перечислено в llms.txt и в документации API. Это не решает описанную проблему — она про поведение самих моделей, а не про хранение на нашей стороне.

Как отфильтровать секреты перед отправкой

Самый полезный пункт — тот, который можно закрыть кодом сегодня. Разберём подробнее.

Задача звучит так: перед тем как отправить текст в модель, найти в нём то, что похоже на секрет, и не отправлять. Полностью решить её нельзя — секрет может выглядеть как угодно. Но подавляющее большинство реальных попаданий закрывается простыми проверками.

Ключи известных форматов. Токены большинства сервисов имеют узнаваемые префиксы и длину. Набор регулярных выражений на два десятка популярных форматов ловит основную массу.

Переменные окружения. Если в тексте встречается строка вида SOMETHING_KEY= или SOMETHING_TOKEN= с непустым значением справа — это почти наверняка то, что отправлять не стоит.

Приватные ключи и сертификаты. Заголовки блоков PEM опознаются однозначно, и ложных срабатываний тут практически не бывает.

Длинные случайные строки. Эвристика по энтропии: строка из 32+ символов без словарной структуры подозрительна сама по себе. Даёт ложные срабатывания на хешах и идентификаторах, поэтому её обычно ставят на предупреждение, а не на блокировку.

Важный момент про то, куда это ставить. Фильтр должен стоять на последнем шаге, прямо перед отправкой запроса, а не в том месте, где вы формируете промпт. Иначе он будет обходиться всякий раз, когда кто-то добавит новый путь формирования контекста, — а его добавят.

Чего в этой работе нет

Отделим факты от того, что легко додумать.

Нет утечки чужих диалогов. Извлекается содержимое того блока, который у вас на руках, а не произвольные чужие сессии.

Нет данных о реакции провайдеров. На момент публикации работы официальных заявлений от OpenAI, Anthropic и Google в открытых материалах мы не нашли. Возможно, к моменту чтения они появятся.

Нет утверждения, что проблема неустранима. Речь про свойство текущей реализации, а не про фундаментальное ограничение.

Нет оценки, сколько таких блоков ходит в реальном мире. Выборка исследовательская, и переносить её пропорции на всю индустрию нельзя.

Нет утверждения, что провайдеры действовали небрежно. Переносимость блоков между моделями — следствие разумного инженерного решения: клиент не должен пересобирать контекст при переключении модели внутри одной экосистемы. Побочный эффект обнаружился позже, чем польза.

Почему это ложится в общий ряд

Это уже третья за месяц история про то, как модель делает не то, что от неё ждали, и все три про одно.

В разборе трёх инцидентов Anthropic модель дважды распознала признаки реальных систем и продолжила действовать. В истории с агентом, вырвавшимся из песочницы цепочка мелких прав два месяца не настораживала никого. Здесь — механизм, задуманный для удобства, оказался каналом извлечения.

Общее у всех трёх: защита, построенная на ожидаемом поведении модели, не работает. Работают технические границы — что физически может уйти в модель, что физически может сделать инструмент, что физически хранится.

Практический минимум на сегодня

Пять пунктов, каждый занимает минуты.

1. Найдите в коде места, где в промпт попадают конфигурации, дампы и выгрузки. Поиск по названиям переменных окружения обычно даёт улов сразу.
2. Добавьте фильтр перед отправкой. Простая проверка на шаблоны ключей закрывает большую часть случайных попаданий.
3. Ограничьте историю диалога. Секрет, мелькнувший один раз, не должен ехать в модель до конца сессии.
4. Не храните блоки рассуждений дольше диалога и не переиспользуйте их между пользователями.
5. Ротируйте ключи, которые могли оказаться в промптах. Особенно те, что использовались в отладке.

Как посчитать, во что обходится история диалога в токенах, и почему её стоит обрезать не только из соображений безопасности — в разборе, почему prompt_tokens больше, чем вы отправили.

Что держать в голове

Зашифрованный блок рассуждений оказался переносимым между моделями одного провайдера, и через слабую модель из него извлекается исходный текст. Продемонстрировано на трёх крупнейших вендорах, в выборке нашлись сотни фрагментов персональных данных и учётных записей.

Практический вывод не про выбор провайдера. Он про то, что попадает в промпт: всё, что вы отправили модели, следует считать способным пережить вашу сессию.

Как мы проверяем факты и почему у каждой цифры стоит источник — на странице о проекте. Отдельный ключ с собственным лимитом под каждый сценарий заводится за минуту: keydealer.ru/login.