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

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

Что произошло

На Хабре разобрали структуру подписи, которую Claude прикладывает к блоку thinking. Автор прошёл путь от base64-строки до protobuf-контейнера и показал: снаружи подпись выглядит как единый зашифрованный объект, но внутри у неё есть вполне читаемый заголовок.

Главный вывод простой. Сам текст рассуждения зашифрован, а вот имя модели, тип блока и идентификатор организации лежат в подписи открытым текстом. В одном из свежих форматов туда же добавили ещё одно поле, и это уже повод смотреть на историю таких блоков не как на «шум», а как на источник чувствительных сведений.

Как это устроено

Схема у блока довольно приземлённая. Сначала идёт base64, затем — protobuf, внутри которого есть внешний конверт, вложенный заголовок, 12-байтные служебные поля и шифротекст с MAC.

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

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

Кого это затрагивает и чем грозит

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

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

Отдельный риск — утечки через цепочки поставки данных. Если кто-то передаёт журналы на разбор, хранит их в облачном репозитории или подмешивает в датасет для внутреннего обучения, метаданные из подписи тоже уезжают дальше. На этом фоне любой разбор формата полезен так же, как и анализ сетевых инцидентов вроде StormEncryptor атакует через дыру в N-central и шифрует сети: сначала кажется, что проблема узкая, а потом выясняется, что последствия шире одного продукта.

Что делать сейчас

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

Для компаний важнее всего три вещи: ограничить срок хранения логов, вырезать лишние метаданные перед передачей наружу и не смешивать рабочие сессии с тестовыми. Если нужен дополнительный слой защиты при подключении из чужой сети, [подключение для работы из поездок]https://freedome.space может пригодиться как часть обычной гигиены безопасности, а не как волшебная таблетка.

Чек-лист

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