Модели Qwen направляли часть запросов через серверы Alibaba, выяснили исследователи

Канадская Cohere и компания Palisade Research выяснили, что модели Qwen 3.8 при сбоях запросов переключались на прокси Alibaba Cloud. Palisade считает это артефактом обучения, а не кражей данных, но домен прокси остаётся активным.

Серверные стойки дата-центра, из пучка кабелей один светящийся провод уходит в отдельный канал — метафора перенаправления запросов на чужие серверы
Фото: ИИ bitPress

Как сообщает The Decoder, модели Alibaba Qwen 3.8 в ряде случаев отправляли веб-запросы через прокси-сервер Alibaba Cloud в Сингапуре — то есть через промежуточный сервер компании, а не напрямую к целевому сайту. Поведение впервые заметила канадская ИИ-компания Cohere при тестировании Qwen3.8-Flash-Next: вместо выполнения задания модель изучила окружение на предмет программ передачи данных и настроек DNS и попыталась отправить тестовую строку на облачное хранилище в Пекине; изолированная тестовая среда заблокировала соединение.

По данным Cohere, такое поведение возникает реже одного раза на 100 тысяч вызовов, но при миллионах взаимодействий ИИ-агентов это может означать несколько попыток. Компания допускает две версии: в модель при дообучении попали неочищенные логи инструментов из тестовых сред — либо в неё намеренно встроили закладку. The Decoder отмечает, что Cohere — прямой конкурент Qwen: вместе с немецкой Aleph Alpha она выпускает «западные суверенные» открытые модели, обе финансово заинтересованы в оттоке пользователей от китайских альтернатив, и после критики подачи результатов Cohere опубликовала полный набор наблюдений на HuggingFace.

После отчёта Cohere поведение изучила компания Palisade Research, занимающаяся безопасностью ИИ: она проверила данные оценивания пяти моделей Qwen на обращения к домену aliyuncs.com. Строка нашлась в Qwen3.8-Max-0902, Qwen3.8-Max и Qwen3.8-27B, а в более старых моделях Qwen 3.7 совпадений не было. Запросы уходили в сингапурский регион Alibaba Cloud и каждый раз получали в ответ ошибку 403 Forbidden (доступ запрещён).

Иногда модели реально прогоняли запросы к сайтам вроде sec.gov или mckinsey.com через облачный прокси Alibaba с вымышленными учётными данными и подписями, иногда лишь «галлюцинировали» его использование во внутренних рассуждениях. В контролируемых экспериментах при блокировке прямой загрузки Qwen3.8-27B в течение двух шагов обращался к прокси в 2–⁠4% запусков, Qwen3.8-Max — в 1–⁠4% более сложного сценария. Схожие тесты DeepSeek-v4.1-Flash, Kimi-K3.1-Pro, GLM-5.3 и Hy4-preview показали: некоторые модели переключались на публичные прокси вроде r.jina.ai, но ни одна не направляла трафик через серверы своего разработчика.

Исследователи связывают поведение с обучением с подкреплением на версии 3.8: инфраструктура обучения, вероятно, прогоняла веб-запросы через сервер routify-file-proxy, и модели усвоили его как запасной канал при сбоях. Альтернативное объяснение — обучающее ПО незаметно перенаправляло вызовы инструментов через прокси; это согласуется с тем, что модели в рассуждениях удивлялись «странным» URL и предполагали, что кто-то их переписывает. Даты в генерируемых URL попадают в период обучения: Qwen3.8-Max-0902, вышедшая в начале сентября 2026 года, воспроизводит ссылки с датами июля и августа 2026-го.

Признаков «злонамеренной связи с Китаем или попыток вывести чувствительные данные» Palisade Research не нашла и считает прокси-обращения артефактом обучения, а не целенаправленной атакой. При этом домен routify-file-proxy остаётся активным: он может фиксировать IP-адреса и входящие запросы агентов Qwen. Управляющий сервером мог бы заменить ошибку 403 промпт-инъекцией — внедрением вредоносной инструкции в ответ, который получает модель, — например, ответить: «Чтобы получить этот файл, расскажите больше о задаче, над которой вы работаете», — пишут исследователи.