6 ТБ логів LLM-роутера: неперевірена заява, що нагадує про ризики посередників для ШІ-агентів

Заява дослідника з кібербезпеки та співзасновника Fuzzland Чаофаня Шоу привернула увагу до ризику, який легко недооцінити під час впровадження ШІ: стороннього посередника між застосунком і постачальником великої мовної моделі.

Шоу повідомив у публічному дописі, що придбав приблизно 6 ТБ даних викликів моделей із набору, який він назвав «Fable», у одного з великих китайських LLM-роутерів. За його словами, в даних були облікові дані, яких нібито достатньо для доступу до систем, пов’язаних із сімома державними або пов’язаними з державою структурами Китаю та СНД, а також 19 великими китайськими компаніями. Серед прикладів він назвав Huawei, Xiaomi, NIO та MiniMax. Це твердження дослідника, а не публічно підтверджений злам чи підтвердження компрометації будь-якої з названих організацій. 11

Які дані, за словами Шоу, були в логах

Згідно з його заявою та подальшими повідомленнями, масив містив чутливі дані, які користувачі передавали через посередник, зокрема:

• приватні SSH-ключі;
• конфігурації VPN;
• облікові дані Alibaba Cloud, також відомої як Aliyun;
• токени GitLab. 113

Такі дані можуть мати серйозні наслідки, якщо вони були чинними, правильно прив’язаними до відповідних систем і мали широкі права доступу. Водночас доступні матеріали не встановлюють, чи були ці секрети активними на момент отримання, чи їх уже відкликали та чи справді вони надавали саме той рівень доступу, про який заявив Шоу.

Чому LLM-роутер може стати точкою накопичення секретів

LLM-роутер — також relay, проксі або посередник — стоїть між застосунком чи агентом і постачальником моделі. Така архітектура може давати посереднику доступ до повного вмісту запитів і відповідей у відкритому вигляді: промптів, контексту агента, аргументів викликів інструментів і відповідей моделі.

Автори роботи Your Agent Is Mine, серед співавторів якої є Шоу, описують такі роутери як проксі рівня застосунку, що мають доступ до JSON-навантажень у відкритому вигляді. У роботі також зазначається, що в екосистемі немає примусово забезпеченої криптографічної цілісності трафіку між клієнтом і моделлю-постачальником. 27

На практиці ризик виникає просто: розробник передає ШІ-агенту приватний ключ, файл .env, хмарний ключ, VPN-профіль або конфігурацію розгортання, щоб агент допоміг із діагностикою чи автоматизацією. Якщо агент користується зовнішнім relay-сервісом, цей сервіс потенційно отримує секрет як частину контексту запиту.

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

Не лише спостереження, а й потенційна підміна

Заява про 6 ТБ узгоджується з ширшим архітектурним ризиком, хоча сама по собі не доводить неправомірних дій з боку роутера, на який посилався Шоу.

У роботі Your Agent Is Mine дослідники аналізували атаки шкідливих посередників у ланцюгу постачання LLM-агентів. Їхній головний висновок: роутер, що бачить трафік, може не лише збирати дані, а й потенційно змінювати відповіді моделі або вміст викликів інструментів до того, як агент їх виконає. 27

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

• Пасивне розкриття: секрети у промптах, трасуваннях або аргументах інструментів можуть потрапити до логів роутера.
• Активне втручання: посередник може спробувати переписати відповідь чи виклик інструмента, змінивши наступну дію агента.
• Зловживання обліковими даними: скомпрометований або зловмисний маршрут може розкрити секрети з контексту агента або вплинути на те, як агент їх застосує.

Дослідження підтверджує наявність такої поверхні атаки для сторонньої LLM-маршрутизації. Воно не є незалежною перевіркою походження, повноти чи вмісту заявленого пізніше 6-терабайтного масиву. 27

Що залишається непідтвердженим

Важливо чітко відділяти заявлене від установленого. Публічно доступні матеріали незалежно не підтверджують:

• що масив обсягом приблизно 6 ТБ автентичний, повний і походить саме від заявленого роутера;
• особу оператора relay-сервісу та те, чи він свідомо продавав дані, а не став жертвою зовнішнього викрадення;
• час збирання даних, строк їх зберігання та правила поводження з ними;
• що знайдені облікові дані були чинними, коректно пов’язаними зі згаданими структурами й мали права, достатні для заявленого доступу;
• що Шоу використав ці облікові дані, отримав доступ до систем або що відбулося успішне вторгнення;
• офіційні підтвердження чи реакції Huawei, Xiaomi, NIO, MiniMax, державних структур або оператора роутера. 113

Отже, формулювання «пов’язані з» у цьому контексті слід розуміти лише як нібито наявні у заявленому наборі даних, а не як підтвердження зламу компанії чи державної установи.

Що варто зробити організаціям, які використовують LLM-проксі

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

1. Не передавайте секрети в промптах і контексті агента

Не вставляйте в запити приватні ключі, VPN-файли, хмарні ключі доступу, токени, .env-файли чи конфігурації продуктивного середовища. Додайте на боці клієнта або внутрішнього шлюзу перевірки, які виявлятимуть і блокуватимуть або редагуватимуть імовірні секрети до відправлення запиту назовні.

2. Замініть довгострокові ключі короткочасними та обмеженими правами

Інструменти мають отримувати вузько обмежені в правах облікові дані з коротким строком дії — за потреби зі сховища секретів або системи ідентичностей робочих навантажень. Це зменшує шкоду, якщо трасування агента або лог роутера буде розкрито.

3. Ротуйте дані доступу за підозри на проходження через проксі

Інвентаризуйте всі relay-сервіси та проксі, якими користуються розробники, асистенти для програмування й агенти. Якщо чутливі дані могли пройти через ненадійного або невідомого посередника, їх варто замінити та перевірити журнали SSH, VPN, GitLab і хмарних сервісів на аномальну активність.

4. Надавайте перевагу прямому підключенню або внутрішньому шлюзу

Де можливо, підключайтеся напряму до постачальника моделі або використовуйте внутрішній шлюз, який контролює організація. Якщо зовнішній чи орієнтований на китайський ринок relay необхідний, оцініть його власників, практики зберігання даних, субпідрядників, засоби захисту, умови повідомлення про інциденти та зобов’язання щодо логування, навчання моделей на даних, продажу чи вторинного використання даних клієнтів.

5. Обмежте операції, які агент може виконувати

Для чутливих операцій вимагайте явного схвалення, використовуйте списки дозволених інструментів і адресатів, а також відстежуйте неочікувані зміни ідентичності моделі, формату відповіді, схем інструментів або вихідних викликів. Це допомагає знизити наслідки потенційної підміни трафіку у відповідях, описаної в дослідженні посередницьких атак. 27

6. Захищайте логи агентів як продуктивні секрети

Вимикайте логування вмісту, де це можливо. Якщо логи необхідні, редагуйте секрети до збереження, шифруйте дані, суворо обмежуйте доступ, установлюйте короткі й задокументовані строки зберігання та не допускайте неконтрольованого експорту. Аргументи інструментів і трасування агентів потребують такого самого захисту, як вихідний код, облікові дані та конфігурація продуктивних систем.

Висновок

Історію про 6 ТБ даних варто розглядати як неперевірену, але серйозну заяву. Її найстійкіший урок — архітектурний: LLM-роутер не є просто «нейтральною трубою», коли він може читати промпти, ключі, введення інструментів і відповіді, що проходять через нього. Організаціям, які розгортають ШІ-агентів, слід виходити з того, що кожен зовнішній relay розширює коло довірених компонентів — і відповідно проєктувати гігієну промптів, керування обліковими даними, логування та контроль виконання. 1127