Сразу вывод: LLM-роутер (маршрутизатор API больших моделей) стоит между клиентом и апстрим-моделью. Измерительная статья 2026 года называет его «прокси прикладного уровня с полной видимостью каждого JSON в пути». HTTPS защищает только хоп до этого прокси. Как только ключ попал в промпт или в аргумент инструмента, он может оказаться в журналах роутера — ломать TLS для этого не нужно.
Сначала одним предложением — ответ на запрос
SSH-ключи оказываются в дампе вызовов не потому, что «HTTPS сломался», а потому, что ключ сначала записали в открытый контекст, который роутер обязан прочитать. Чтобы переслать запрос, он разбирает JSON; если разобрал — может сохранить и продать. Границу статья фиксирует одной фразой: сторонние роутеры работают как прокси прикладного уровня, видят каждый JSON в пути открытым текстом, и между клиентом и апстрим-моделью никто не навязывает проверяемую криптографическую целостность.
Заметка для разработчиков и администраторов, которые зовут модель через агента в IDE, свой шлюз или «дешёвый релей» с чужим Claude. Она не заменяет инструкцию к очистке конфиденциальных данных и не повторяет разбор «сначала замаскируйте поля тикета, потом вставляйте в чат». Унести отсюда стоит другое: насколько сентябрьский пост годится как доказательство, какие два конца реально закрывает HTTPS, почему контекст агента чаще уносит целый закрытый ключ, чем тикет, и как на этом устройстве сверить Host вместе с текстом, который вот-вот уйдёт.
Что на самом деле сказал сентябрьский пост
Как пересказывает публичный разбор от 11 сентября 2026 года, исследователь Чаофань Шоу (Chaofan Shou) 10 сентября написал: он купил у топового китайского LLM-роутера набор вызовов модели Fable объёмом около 6 ТБ. По его словам, SSH-ключи, конфигурации VPN, ключи Alibaba Cloud и токены GitLab из этого дампа хватало, чтобы добраться до семи ведомств, связанных с Китаем и СНГ, и девятнадцати китайских компаний. В посте назвали несколько брендов. На следующий день подхватили несколько русскоязычных и китайских обзоров, в том числе пересказы вроде материала iXBT про «6 ТБ данных Claude с китайского LLM-маршрутизатора».
В проверочный список из этой истории входят только три предложения. Первое: существует публичное утверждение, что LLM-роутер хранит записи вызовов и кто-то продаёт их пакетами на терабайты. Второе: названные типы учётных данных — закрытые ключи, VPN, облачные ключи, токены GitLab — как раз те куски, которые агент при отладке охотнее всего целиком кладёт в контекст. Третье: «хватит, чтобы захватить» — заявление о возможности от исследователя, а не бюллетень о вторжении, который проверил независимый аудитор. FastPwd эти 6 ТБ файлов не смотрел и не пишет названные бренды как «уже взломанные».
Заголовок может взять новость. Приговор — нет. Техническая цепочка одна и та же: как только открытый промпт покинул это устройство, роутер перестаёт быть «прозрачной трубой».
Какой слой открытого текста видит LLM-роутер
Официальный API модели обычно устроен так: клиент говорит с вендором, конечная точка TLS — вендор. LLM-роутер добавляет хоп. Клиент сначала бьёт в маршрутизатор; маршрутизатор переписывает вызов под апстрим-вендора. Для клиента сертификат и пир (адресная строка или remote HTTP-библиотеки) заканчиваются на роутере. Когда этот процесс снимает TLS, он видит всё тело: системный промпт, вопрос пользователя, имена инструментов, аргументы, иногда путь репозитория или кусок .env.
Лю, Шоу и соавторы в работе Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain (arXiv:2604.08407, CCS 2026) кладут в модель угроз два класса атак: переписать полезную нагрузку вызова инструмента (AC-1) и вытащить секреты из открытой нагрузки (AC-2). Они купили 28 платных роутеров на маркетплейсах и в независимых лавках и собрали 400 бесплатных из открытых сообществ. Опубликованные числа: один платный и восемь бесплатных роутеров сами вставляли вредоносный код; семнадцать трогали канареечные учётные данные AWS, которые исследователи заранее положили; один снял ETH с тестового ключа исследователей. В следующем опыте с отравлением слабо настроенные приманки раскрыли 99 учётных данных на 440 сессиях Codex, из них 401 уже шла в режиме YOLO без подтверждения.
Эти цифры не нужно воспроизводить у себя. Они уже фиксируют опубликованный факт: роутер умеет «видеть», а часть узлов ещё и «переписывает» и «тратит». Платная подписка — не справка о чистоте. Сентябрьский дамп на 6 ТБ — та же цепочка, публично названная, на шаге «увидел и оставил».
| Что вы видите | Какой вывод это держит | Какой вывод это не держит |
|---|---|---|
| Клиент показывает HTTPS / защищённое соединение | Хоп до текущей конечной точки TLS зашифрован | LLM-роутер не видит промпт |
| Роутер умеет переслать вызов инструмента | Он обязан разобрать открытый JSON | Он только гоняет байты и никогда не пишет на диск |
| Исследователь заявил, что купил дамп вызовов на 6 ТБ | Есть открытое утверждение, что журналы упаковали и продали | Названные компании независимо подтверждены как взломанные |
| Статья измерила переписывание нагрузки | Часть узлов не только хранит, но и внедряет | Каждый LLM-роутер травит трафик |
| Тикет уже прошёл маскирование по правилам | Типичные телефоны и номера документов могли закрыться | Целый SSH-ключ в контексте агента тоже остановили |
HTTPS останавливает наблюдателя на пути. Тело роутеру он читать не мешает
В справке MDN по TLS зона защиты записана так: в недоверенной сети шифрование, целостность и проверка сервера идут между клиентом и сервером; когда этот стек защищает HTTP, результат называют HTTPS. После рукопожатия заголовки и тело на этом хопе — шифротекст. В сценарии с роутером «сервер» — сам маршрутизатор. Ему нужно расшифровать, чтобы понять, какой апстрим звать и какие аргументы у инструмента. Расшифровал и записал журнал — второго «сквозного шифрования», которое вы себе представляли, уже нет.
Поэтому фраза «у нас везде HTTPS, ключ не утечёт» на этой цепочке не держится. Точная формулировка: на публичном хопе есть TLS, поэтому боковой захват с линии вряд ли прочитает JSON; процесс роутера, его диск, его операторы и тот, кто купит дамп, в колонку «наблюдатель на пути» не входят.
Официальный API вендора тоже не вычёркивает сотрудников вендора из списка «кто может видеть открытый текст». Разница — где вы рисуете границу доверия: отдаёте тело официальному интерфейсу модели или сначала третьей стороне, которая продаёт наценку, квоту или «рабочий Claude». У последней с вами часто нет договора про обработку ключей, зато тот же JSON она читает раньше вендора.
Почему контекст агента чаще уносит целый ключ, чем тикет
Когда вы вставляете тикет в веб-чат, человек хотя бы скользит глазами по символам, которые вот-вот уйдут. Агенты и плагины IDE часто собирают контекст сами: текущий файл, ошибка терминала, Git remote, .env, только что упавшая команда ssh. Включили YOLO или «автоподтверждение инструментов» — закрытый ключ может попасть в тело запроса без нажатия «Отправить». В статье 401 из 440 сессий уже шли в таком режиме. Это счётчик, не метафора.
Маскирование по правилам хорошо закрывает телефоны, номера документов и почту — поля с устойчивой формой. Оно не закрывает «положить весь id_rsa в системный промпт» и не закрывает «записать AKIA… и парный секрет аргументом инструмента». Предыдущая заметка про то, как сверить поля до вставки тикета. Эта сначала спрашивает: есть ли в этом JSON целый секрет, которым можно войти. Делайте оба шага. Один другой не заменяет.
Одноразовый пароль, который должен дойти до коллеги, тоже не стоит гнать через агента. Удобнее путь burn-after-read: зашифровать на этом устройстве, отдать серверу только шифротекст, а ключ расшифровки дописать после решётки в s.html?id={id}#{key}. Создавать и читать можно без аккаунта. Обновление со статусом «сожжена» значит только то, что шифротекста на сервере уже нет. Оно не значит, что получатель не сделал скриншот — эта граница в другой заметке. Зато по сравнению с «отдать пароль роутеру, который может хранить 6 ТБ журналов» здесь на один открытый хоп меньше.
Не ставьте опыт на настоящем SSH-ключе, облачном ключе продакшена, неротированном токене GitLab или незамаскированном тикете. Подготовьте одноразовую канарейку вроде CANARY-LLM-20260916. Вы сверяете исходящую границу, а не снова отправляете ключ, который ещё открывает дверь.
Сверьте сейчас: Host, JSON и текст, который уйдёт
Слоган — не доказательство. Три шага ниже заканчиваются на этом устройстве, аккаунт не нужен. Цель — не воспроизвести сделку на 6 ТБ. Цель — увидеть, кому этот клиент отправил тело и что именно ушло.
- Откройте Network в инструментах разработчика или посмотрите HTTPS-пир агента в локальном прокси или в терминале. Запишите Host: официальный домен API, LLM-роутер, свой шлюз или зарубежный релей. Субъект сертификата должен совпадать с этим Host.
- Сделайте канарейку, которой не бывает в настоящей работе. Положите её в этот промпт или аргумент инструмента, отправьте и найдите всю строку в теле запроса. Попадание значит: эти символы уже покинули устройство как рабочие данные. HTTPS в адресной строке или в HTTP-библиотеке этот вывод не меняет.
- Отдельно сверьте текст «который собираетесь отправить». Заголовок закрытого SSH-ключа
BEGIN OPENSSH PRIVATE KEY, облачный ключ, GitLabglpat-или блок VPN, который всё ещё на месте, — не отправляйте. Типичные телефоны, номера документов и почту сначала можно прогнать через маскирование по правилам. Целый пароль или закрытый ключ лучше сделать плейсхолдером или отдать человеку через Burn-Link — не через маршрутизатор модели.
Список Host ближе к «кто это видит», чем иконка замка
В одной компании может одновременно жить официальный SDK и base_url, который кто-то вставил из чата. «Мы пользуемся моделью X» мало. Смотрите имя хоста, в который реально ушёл этот запрос. Роутеры часто завершают TLS на своём домене, а дальше зовут вендора уже своим апстрим-ключом. Если ваш секрет сидит в JSON первого хопа, вендор даже не единственный читатель.
Объект сверки — текст, который уйдёт
Бейдж на странице «замаскировано», «режим приватности» или «не используем для обучения» меняет только то, как другая сторона хранит и учится. Он не меняет факта, что поля уже ушли. Если роутер продаст дамп вызовов, переключатель обучения не поможет. Объект сравнения всегда это тело запроса, а не текст на переключателе.
Упакованный агент может сначала бить в локальный прокси на localhost, а уже тот — наружу. Если внешнего Host не видно, пройдите локальный порт до следующего хопа. Localhost — не конец. Это ещё одна передача того же открытого текста.
Три способа прочитать эту новость слишком далеко
Первое: написать названные бренды как «подтверждённо взломанные». Пост — заявление о возможности. Без сторонней экспертизы, которую FastPwd не проводил, приговор писать не стоит. Что можно сделать — прокрутить в своей среде те же классы учётных данных, которые там уже мелькали, и перестать слать живые ключи на роутер.
Второе: написать «перейдите на официальный API» как «открытый текст никогда не покидает это устройство». Официальная точка всё равно читает промпт на сервере. Она убирает хоп «роутер с наценкой сохранил и продал», а не тезис «сервер модели тела не видит». Тело остаётся в процессе, который вы контролируете, когда модель локальная или когда маскирование заканчивается на этом устройстве.
Третье: написать FastPwd так, будто он аудирует за вас LLM-роутер. Он не проксирует трафик моделей и не даёт аккаунтов или хранилища паролей. В этой вкладке он может замаскировать текст, который вы собираетесь отправить, и один раз передать секрет человеку через Burn-Link. Шифрование файлов считает AES-256-GCM на файле не больше 5 ГБ, пишет .lock / .enc и по умолчанию не загружает открытый текст — это другая цепочка «сначала зашифровать, потом выпускать». Закрытый ключ, который вы уже положили в промпт, она не чинит.
Частые вопросы
Если LLM-роутер работает по HTTPS, промпт зашифрован от конца до конца?
HTTPS шифрует только хоп от клиента до текущей конечной точки TLS. Сам роутер и есть эта точка. Статья описывает его как прокси прикладного уровня, который видит каждый JSON в пути открытым текстом. Наблюдатель на линии вряд ли прочитает байты. Журналы роутера, его операторы и тот, кто купит упакованный дамп, промпт, вызов инструмента и ключ всё ещё могут увидеть.
Дамп на 6 ТБ доказывает, что названные компании уже взломали?
Нет. Пост от 10 сентября — заявление исследователя: он сказал, что купил около 6 ТБ вызовов, в которых хватало учётных данных, чтобы добраться до ряда компаний и ведомств. Эта заметка берёт это как открытое утверждение, которое нужно сверить, а не как проверенное вторжение. На этом устройстве можно проверить, попал ли живой ключ в этот промпт.
Это та же сверка, что маскирование тикета перед вставкой в ChatGPT?
Нет, это другой слой. Маскирование тикета спрашивает, остались ли в вставляемом тексте телефоны, номера документов и почта. Вопрос про роутер спрашивает, на какой хост ушёл JSON агента и не уехал ли SSH-ключ или облачный токен как аргумент инструмента. Маски полей ловят тикет. Целый закрытый ключ в контексте они не ловят.
Может ли FastPwd помешать LLM-роутеру продавать журналы?
Нет. У FastPwd нет аккаунтов, и он не проксирует трафик моделей. Он может замаскировать типичные чувствительные поля, пока текст ещё на этом устройстве, и отдать пароль, который должен дойти до коллеги, через Burn-Link, с ключом после # в URL. Открыли — и можно пользоваться. Живые SSH-ключи и облачные токены в промпт класть не нужно.
Прогоните ту же канарейку через инструмент, который открыли — и пользуйтесь
Если наружу уходит тикет, журнал или стек ошибки, откройте очистку конфиденциальных данных FastPwd. Регистрация не нужна. Вставьте одноразовый абзац и сверьте маску: телефоны, номера документов, почта и типичные формы API-ключей не должны уходить открытым текстом. Исходник по умолчанию не загружается. Целый пароль, который правила не закрыли, — это не «почти сойдёт». Замените его плейсхолдером.
Если одноразовый тестовый пароль должен дойти до коллеги, а не до модели, откройте Burn-Link и соберите s.html?id={id}#{key}. Сверьте Network: в строке запроса должен быть только id. Ключа после решётки там быть не должно. Это решает «один раз отдать секрет человеку». Это не делает LLM-роутер безопасным.
В следующий раз, когда увидите «LLM-роутер 6 ТБ» или «в дампе вызовов SSH», задайте три вопроса. Первый: конечная точка TLS у этого JSON — официальный API или сторонний маршрутизатор. Второй: в тексте, который уйдёт, ещё есть целый секрет, которым можно войти. Третий: пароль, который должен дойти до человека, ушёл после решётки, а не в агент. Наблюдение, которое можно повторить, имеет смысл вписать в ваш собственный регламент ревью.
Что ещё почитать
Перед вставкой тикетов и логов в ИИ, как сверить, какие поля покинут устройство: Перед тем как вставить тикеты и логи в ИИ, сверьте, какие поля покинут это устройство. Как искать канарейку в Network при локальном шифровании в браузере: Как проверить, что локальное шифрование в браузере не отправило открытый текст. Почему часть после решётки по умолчанию не входит в HTTP: Почему после решётки в URL можно класть ключ и когда эта защита ломается.