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

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

1) История инцидента

Авторы работы Stealing Reasoning Traces from Proprietary LLM APIs взяли зашифрованный блок рассуждений, который возвращает сильная модель, и подали его в запрос к более слабой модели того же провайдера. Слабая модель переписывала этот блок почти дословно, а старшую модель никто не атаковал напрямую.

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

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

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

2) Что пошло не так в защите

Главная ошибка — попытка отделить «видимый ответ» от «невидимого мышления» так, будто это два разных мира. На деле скрытая трасса осталась частью рабочей сессии и по-прежнему путешествует между запросами. Если такой блок можно передать дальше и заставить модель его раскрыть, это уже не защита, а слабая упаковка.

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

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

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

3) Уроки для читателя

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

Второй урок касается команд и фрилансеров. Не складывайте сырые логи ИИ в открытые репозитории и общие папки без проверки. То, что удобно для отладки, часто удобно и для утечки.

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

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

4) Практические выводы и чек-лист

Что делать прямо сейчас, если вы работаете с ИИ-инструментами, агентами или логами:

  • Проверьте, где у вас хранятся агентские логи, диалоги и трассы рассуждений.
  • Уберите из общих папок все записи, где могут быть ключи API, токены, пароли и внутренние URL.
  • Не публикуйте сырые логи в открытых репозиториях без ручной чистки.
  • Отдельно храните материалы для отладки и материалы для отчета или демонстрации.
  • Ограничьте доступ к логам по принципу минимально необходимого.
  • Настройте регулярный поиск секретов в репозиториях и журналах.
  • Не считайте краткое саммари полным отражением того, что модель «подумала».
  • Если вы используете инструмент для приватной работы в поездках, подключайте его только как часть общей защиты данных, а не вместо очистки логов и контроля доступа.
  • Проверьте, не утекают ли в отчеты и дампы внутренние адреса, имена пользователей и служебные идентификаторы.
  • Обновите внутренние правила: все, что выходит из ИИ-системы, может содержать чувствительные фрагменты.

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

Поделиться: