У Claude від Anthropic та ChatGPT від OpenAI дослідники, які аналізували внутрішні «сліди міркувань» (reasoning traces) цих моделей, знайшли фрагменти паролів, токенів доступу та інших облікових даних, які користувачі раніше вводили в чат. За даними Speka, ці дані потрапили не у видиму відповідь моделі, а в проміжний текст, який Claude і ChatGPT генерують під час «обдумування» задачі перед фінальною відповіддю.

Проблема не в тому, що моделі «зламали» і витягли чиїсь паролі з навчальних даних. Вона банальніша й тому неприємніша: користувачі самі вставляють секрети в запити — під час дебагу коду, розбору логів помилок, опису конфігурації сервера — а reasoning-режим, який «промовляє» весь контекст перед відповіддю, чесно відтворює ці рядки у себе в «думках».

Для команд, що будують продукти на базі LLM, це не абстрактна етична дилема, а конкретна діра в pipeline логування. Розберемо, де саме ховається ризик і що з ним робити вже зараз.

Що саме знайшли дослідники?

Дослідники отримали доступ до «сирих» reasoning-трейсів — того тексту, який Claude в режимі extended thinking чи reasoning-моделі OpenAI (лінійка o-серії та GPT-5 з увімкненим мисленням) генерують перед фінальною відповіддю. У частині трейсів моделі буквально переказували собі облікові дані з попередніх повідомлень користувача — наприклад, коли той просив допомогти розібратися, чому не проходить логін, і вставляв у запит логін і пароль разом з кодом помилки.

Ключовий момент: фінальна відповідь моделі зазвичай ці дані не повторює — вона відповідає по суті питання. А ось проміжний reasoning-блок, який часто вважають «внутрішньою кухнею» моделі і не фільтрують так само суворо, як публічну відповідь, — повторює.

Як це працює під капотом?

Reasoning-трейс — це не окремий «мозок» моделі, а звичайний згенерований текст, умовлений на весь контекст розмови. Модель не знає, яка частина вхідних даних є «секретною», а яка ні: для неї пароль у логах помилки — такий самий токен, як назва змінної чи номер рядка коду.

Провайдери підходять до цих трейсів по-різному. Anthropic у API повертає блоки thinking у складі відповіді, тож вони потрапляють у будь-яку систему логування, яку ви під'єднали до виклику. OpenAI за замовчуванням ховає сирий chain-of-thought і показує лише стиснуте резюме, але для деяких моделей і партнерських інтеграцій повний трейс усе одно доступний. У обох випадках рішення про те, зберігати трейс чи ні, і на скільки — лежить не на стороні провайдера-моделі, а на стороні продукту, який ці виклики оркеструє.

Саме тому дослідники, які вивчають внутрішні репрезентації моделей — той самий напрям, у якому ми нещодавно розбирали нестабільність ознак у sparse autoencoders — і отримали доступ до чутливих даних: не через злам моделі, а через звичайний доступ до логів і трейсів, які ніхто вчасно не редагував.

Кому це загрожує найбільше?

Найвищий ризик — у командах, які вже підключили observability-інструменти (на кшталт LangSmith, Langfuse чи власних сховищ логів) і зберігають повні виклики API, включно з reasoning-блоками, без жодної фільтрації чутливих рядків.

• Support-боти, куди користувачі вставляють логи помилок разом із токенами сесій чи API-ключами;
• Coding-асистенти й агенти для дебагу, яким передають конфіги з реальними паролями «для швидкості»;
• Пайплайни fine-tuning чи RLHF на основі реальних діалогів користувачів без попереднього redaction;
• Будь-який продукт, що зберігає повну історію reasoning для аналітики якості відповідей.

У кожному з цих випадків пароль чи токен, який ніколи не з'являвся у фінальній відповіді моделі й тому здавався «безпечним», спокійно лежить у базі логів роками.

Що AI-білдерам робити з цим уже зараз?

Головний висновок AiiN: reasoning-трейс варто за замовчуванням вважати таким самим чутливим об'єктом, як сирий промпт користувача, а не службовою деталлю, яку можна логувати без обмежень. Команди, що досі ставляться до «думок» моделі як до внутрішньої, ніби нічийної, службової інформації, фактично тримають у себе тіньову копію всього, що користувач будь-коли вставляв у чат.

• Прогоняйте reasoning-блоки через ту саму систему secret-scanning (на кшталт gitleaks-паттернів), яку ви застосовуєте до коду, перед будь-яким записом у постійне сховище;
• Вимикайте зберігання повного thinking-блоку там, де він не потрібен для дебагу продукту — достатньо стисненого резюме;
• Встановіть коротке TTL для сирих трейсів окремо від TTL фінальних відповідей;
• Якщо ви колись вставляли реальний пароль чи ключ у чат із Claude чи ChatGPT — ротуйте його, незалежно від того, видалили ви розмову чи ні.

Продукт, побудований на LLM, не закінчується на промпті й відповіді — reasoning-шар усередині вже став повноцінною поверхнею витоку даних, і поводитися з ним варто за тими ж правилами, що й з будь-якими іншими логами PII.

Чи означає це, що Anthropic та OpenAI навмисно зберігають паролі користувачів?

Ні. Йдеться не про навмисний збір даних провайдером, а про побічний ефект того, як генеруються reasoning-трейси: модель відтворює будь-який текст із контексту, включно із секретами, які туди вставив сам користувач.

Чи можна вимкнути показ «думок» моделі у своєму продукті?

Так, здебільшого можна приховати сирий thinking-блок від кінцевого користувача в інтерфейсі. Але якщо ваш backend логує повну відповідь API для аналітики чи дебагу, трейс усе одно осяде у ваших сховищах, доки ви явно не виключите його з логування.

Що робити, якщо я вже вставляв пароль у запит до Claude чи ChatGPT?

Ротуйте його якнайшвидше — так само, як після будь-якого іншого потенційного витоку. Видалення розмови в інтерфейсі не гарантує видалення з логів провайдера чи з логів продукту, через який ви робили запит.