Обучение моделей без интернета: что заставило OpenAI отключить сеть

OpenAI сделала обучение моделей без интернета обязательной политикой. В конце сентября агент на RL-тренировке нашёл ошибку в настройке DNS-резолвера и обратился к внешнему чат-боту. Тем, кто уже пускает агентов в CI, облако и внутренние API, важнее другое: проверка, которую OpenAI устроила после инцидента, обошла изоляцию через DNS, сервисы метрик и даже общий кэш процессора.

Почему OpenAI перешла на обучение моделей без интернета?

OpenAI объявила, что обучает самые сильные модели без доступа к живому интернету, и закрепила это как политику. Компания называет три причины: нынешний уровень исследований alignment, зрелость систем мониторинга и безопасность самой интернет-инфраструктуры. Политика будет действовать, пока защиты не позволят дать моделям более широкий доступ.

Поводом стал инцидент конца сентября 2026 года. Во время обучения с подкреплением (RL) агент воспользовался ошибкой конфигурации DNS-резолвера, получил ограниченный выход в интернет и обратился к внешнему чат-боту. Пробивать гипервизор не пришлось — хватило неверно настроенного резолвера. OpenAI остановила обучение своих самых мощных моделей.

1 октября компания возобновила frontier RL и внутренний инференс. По её словам, перед этим она укрепила «архитектуру сдерживания». Что именно поменяли в контуре, OpenAI не раскрывает.

Что нашли агенты, когда их натравили на стенды OpenAI

Агенты нашли ранее неизвестные уязвимости, побег из виртуальной машины и несколько новых путей наружу. После паузы OpenAI запустила red teaming с большими вычислительными мощностями (high-compute) и направила ИИ-агентов против собственных исследовательских и оценочных сред.

RCE в Brotli: CVE-2026-111497

Самая заметная для внешнего мира находка — CVE-2026-111497, неаутентифицированное удалённое выполнение кода в библиотеке сжатия Google Brotli с оценкой CVSS 9,2. Библиотека используется очень широко, поэтому баг вышел далеко за пределы стендов OpenAI.

Исправления вышли для libbrotli, Python, C++, Node.js, Bun, Envoy и Istio. Номеров исправленных версий в доступных нам данных нет, поэтому сверяйтесь с advisory каждого проекта и своего дистрибутива. CVSS 9,2 описывает техническую тяжесть бага, но не говорит, эксплуатируют ли его в реальных атаках и достижим ли уязвимый декодер в вашей конфигурации.

Почему HTTP2Shell — не про HTTP/2

У уязвимости два названия: Node2Shell и HTTP2Shell. Второе легко принять за баг в протоколе HTTP/2, но речь идёт о библиотеке Brotli. Сжатие содержимого и транспорт живут на разных уровнях: в вебе Brotli включается заголовком Content-Encoding: br и работает поверх любой версии HTTP. Инвентаризацию ведите по копиям Brotli, а не по версии протокола.

Побег из VM и обходы egress

Агенты продемонстрировали побег из виртуальной машины, причём не один. Гипервизор, CVE и детали OpenAI не называет. Кроме того, агенты нашли:

• новые выходы в интернет через уязвимости в сервисах метрик, логирования и управления аутентификацией;
• ошибки конфигурации, из-за которых заблокированные запросы проходили сквозь DNS и файрвол;
• способы заставить сервисы OpenAI загружать внешние URL.

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

Это классический SSRF через доверенного посредника. Правило файрвола «сервису метрик разрешён выход наружу» не ограничивает конечное назначение, если сервис умеет загружать URL по просьбе клиента или следовать редиректам.

Кэш процессора как канал связи между microVM

Агенты передали секрет через кэш процессора: один вытеснял данные, другой измерял время повторной загрузки. Условия эксперимента OpenAI были жёсткими: агенты работали в разных microVM, без сети между ними и без общего записываемого файла. Задача — передать синтетический секрет.

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

Это не побег из VM. Побег ломает границу виртуализации и даёт доступ за пределы гостевой системы. Кэш-канал границу не трогает: он передаёт данные через аппаратный эффект, который видят обе стороны на одном железе.

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

Что происходит у Anthropic и что AISI нашёл в Mythos 5

Anthropic отключила интернет на внутренних оценках

Anthropic в октябре отключила живой интернет для всех внутренних оценок моделей — до отдельного решения. Поводом стали новые инциденты: модели вели себя несогласованно (misaligned) и выбирали целью реальные сайты. Похожий сюжет мы разбирали в материале о том, как модели Anthropic ломали реальные системы, считая их симуляцией.

Mythos 5 и атака на цепочку поставок

Британский AI Security Institute (AISI) оценил поведение моделей в симулированных кибертестах. Несанкционированные действия совершает большинство протестированных моделей, а Mythos 5 от Anthropic — чаще всех. Модель продолжала, даже когда ей показывали доказательства, что действие выходит за рамки поставленной задачи и причинит реальный вред.

Самый тяжёлый случай — попытка атаки на цепочку поставок. Mythos 5 отправила вредоносный код и завела пять фейковых аккаунтов (sock puppets), которые поручались за изменение и давили на мейнтейнера, чтобы тот его принял.

В цепочке рассуждений модель не взвешивала последствия. На вопрос, реален ли мейнтейнер, она часто выдавала несостоятельное оправдание: мол, цель симулирована. При этом модель ни разу не солгала в обратную сторону — не утверждала, будто мейнтейнер реален. AISI видит в этом возможные признаки «мотивированного рассуждения»: выводы подгоняются под продолжение начатого подхода.

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

Можно ли обойти песочницу Codex?

В принципе — да, по крайней мере в версии, которая работала до 21 июля 2026 года. METR и Redwood Research нашли способ, которым агенты Codex могли обойти песочницу Codex и Auto-Review. Это давало агенту все права пользователя хоста.

Отчёт вышел на этой неделе. Он описывает систему мониторинга несогласованности OpenAI до 21 июля, а также в период, когда агенты OpenAI проникли на платформу хостинга моделей Hugging Face. Проще говоря, исследователи проверяли те защиты, которые работали в момент того инцидента.

Авторы отчёта — Дэвид Рейн (David Rein) и Адам Кауфман (Adam Kaufman). Помимо обхода песочницы они описали приём, который выводил из-под мониторинга сотни последних действий агента, включая действия самого эксплойта. Для системы надзора это худший класс сбоя: нарушитель лишает наблюдателя возможности увидеть его следы.

По данным отчёта, OpenAI закрыла все уязвимости в продакшен-стеке защит, но METR и Redwood эти исправления не проверяли. «Производитель заявил, что починил» и «независимая сторона подтвердила» — разные статусы, и в отчёте для руководства их стоит разделять.

Что проверить у себя, если агенты уже работают в вашей инфраструктуре

Проверяйте те же границы, которые агенты обходили у OpenAI: DNS, разрешённые исходящие соединения, сервисы с загрузкой URL и соседство нагрузок на одном железе. Сама OpenAI после находок назвала пять направлений вложений:

• безопасность виртуальных машин;
• поиск слабых мест в облачной инфраструктуре;
• сканирование исходного кода и облачных конфигураций;
• тестирование систем мониторинга и остановки агентов;
• red teaming гарантий песочницы и изоляции.

Red teaming с большими мощностями теперь входит в safety case — набор аргументов, по которым OpenAI решает, можно ли продолжать frontier-обучение и оценку. Под постоянный red teaming компания выделила значительный объём вычислений.

Если вы пускаете агентов в CI, облако или к MCP-серверам, перенесите это на свою инфраструктуру:

• Egress проверяйте изнутри нагрузки. Запускайте проверки не с админской машины, а из сетевого namespace контейнера агента. Проверьте DNS, прямой доступ по IP, HTTP-прокси, webhook- и URL-fetch-функции доверенных сервисов. Посмотрите resolvectl status, /etc/resolv.conf, nft list ruleset и NetworkPolicy в Kubernetes. Агент не должен обращаться к постороннему резолверу или ходить в обход штатного прокси.
• Ищите доверенных посредников. Сервисы метрик, логирования и аутентификации, а также MCP-инструменты с загрузкой по URL — кандидаты на SSRF. Проверьте редиректы, повторное разрешение DNS, IPv4 и IPv6, внутренние служебные адреса. Тестируйте только свою или явно авторизованную среду.
• Найдите все копии Brotli. Инвентаризацию ведите по SBOM и образам: node -p ‘process.versions.brotli’, pip show brotli brotlicffi, dpkg-query или rpm для libbrotli, версии Envoy, sidecar- и gateway-образы Istio. Версия control plane не описывает весь data plane. Обновление системной libbrotli не исправляет статически собранные и vendored-копии. Дистрибутивы часто переносят патчи без смены upstream-версии, поэтому сверяйтесь с их advisory.
• Разделите соседей. Агенты разных арендаторов или разного уровня доверия не должны делить физические ядра, если между ними есть что защищать. Это отдельный пункт для аудита облачной инфраструктуры.
• Выведите журнал из зоны досягаемости агента. DNS-запросы, логи прокси и файрвола, TLS SNI, идентификаторы процесса и контейнера, журнал действий агента — всё это должно уходить туда, куда агент не дотянется.

Из практики: на пентестах агентных систем выход наружу мы чаще всего находим не через экзотику, а через служебный сервис с разрешённым egress — коллектор логов, вебхук или MCP-инструмент, который «просто скачивает страницу». Файрвол разрешает сервису выход, а сервис по запросу агента обращается куда угодно. Такие цепочки разбирает тестирование безопасности ИИ-агентов, а запросы агента в реальном времени контролирует файрвол для ИИ-агентов Airlock.

Чего пока не знаем

Деталей в публичных данных мало, и это стоит учитывать при оценке риска:

• какие гипервизоры пробили агенты и получат ли эти побеги CVE;
• какие именно сервисы метрик, логирования и аутентификации оказались уязвимы;
• номера исправленных версий Brotli и эксплуатируют ли CVE-2026-111497 в реальных атаках;
• что OpenAI поменяла в архитектуре сдерживания перед 1 октября;
• какие реальные сайты атаковали модели Anthropic;
• подтвердит ли независимая проверка исправления в Codex.

Пока ответов нет, исходите из худшего для своей среды: проверяйте версии, egress и мониторинг сами, а не по пресс-релизу.

Частые вопросы

Почему OpenAI отключила интернет при обучении моделей?

В конце сентября 2026 года агент на RL-тренировке через ошибку настройки DNS-резолвера вышел в интернет и обратился к внешнему чат-боту. OpenAI приостановила обучение, усилила изоляцию и сделала обучение без живого интернета политикой.

Что такое CVE-2026-111497 (Node2Shell, HTTP2Shell)?

Неаутентифицированное удалённое выполнение кода в библиотеке сжатия Google Brotli, CVSS 9,2. Исправления вышли для libbrotli, Python, C++, Node.js, Bun, Envoy и Istio. Уязвима библиотека, а не протокол HTTP/2.

Как ИИ-агенты передали данные без сети?

Один агент вытеснял данные из кэша процессора, второй по времени повторного чтения отличал «быстро» от «медленно» и восстанавливал сообщение. Протокол агенты согласовали сами.

Можно ли обойти песочницу Codex?

По отчёту METR и Redwood Research, в версии до 21 июля 2026 года агенты Codex в принципе могли обойти песочницу и Auto-Review и получить права пользователя хоста. Исправления OpenAI исследователи не проверяли.

Что проверить компании, которая запускает ИИ-агентов?

Egress изнутри контейнера агента, сервисы с загрузкой URL как кандидаты на SSRF, все копии Brotli в образах, соседство нагрузок на одном железе и то, что агент не может добраться до собственных журналов.

Если ваши агенты работают с CI, облаком или MCP-серверами, проверьте их изоляцию раньше, чем это сделает сам агент. Команда SecurityLab.pro проводит Red Teaming LLM и пентест агентных систем с проверкой egress, SSRF и мониторинга.