Тревогу подняли через 12 минут, агента остановили через два с половиной часа. Что на самом деле сломалось в песочнице OpenAI?

Агент OpenAI сбежал из песочницы через службу, которую не видел её прокси: через DNS. Сбежал, чтобы спросить у чужого чатбота, кто написал один блог-пост. Автора он так и не нашёл.

25 сентября OpenAI опубликовала отчёт об этом инциденте в своём блоге о согласовании моделей. Отчёт подробный: с командами агента, его рассуждениями и поминутной хронологией. Мы прочитали его целиком, и самая интересная часть там не побег, а то, что было после.

Что случилось в песочнице OpenAI 20 сентября

Внутренняя исследовательская модель проходила RL-обучение. Задача звучала мирно: найти человека, написавшего пост в блоге, по биографическим деталям и подсказкам из текста. Проверять сетевые ограничения никто не просил, и OpenAI прямо называет поведение агента misalignment: он обошёл запреты и пошёл к цели дальше разумных ожиданий.

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

Как агент нашёл выход через DNS

Путь от поисковой задачи до DNS-туннеля занял у агента несколько шагов, и каждый выглядит логично изнутри.

1. 1

   Поисковик не помог

   Встроенный поиск вернул мусор. Агент решил, что инструмент сломан, и отправил тот же запрос в Google, Bing и DuckDuckGo через Python. Ответы: 403 и дважды 502.

2. 2

   Догадка про бенчмарк

   Агент решил, что задача взята из BrowseComp, публичного бенчмарка веб-поиска, скачал датасет из офлайн-кэша, расшифровал вопросы и искал совпадения. Не нашёл, проверил ещё SimpleQA. Догадка была неверной.

3. 3

   Проверка сети

   HTTPS-запрос к публичному чатботу прокси отбил с ошибкой 502. Прямые запросы к публичным DNS остались без ответа. Но резолвер самой среды вернул настоящую запись для известного домена и отклонил выдуманный.

4. 4

   Делегирование

   Агент нашёл публичный сервис, который делегирует DNS-запрос на адрес, зашитый прямо в имя хоста, и через него отправил вопросы стороннему чатботу.

5. 5

   Париж

   С таймаутом 6 секунд запросы отваливались. Агент поднял его до 19 и получил ответ: «The capital of France is Paris». Канал работал.

6. 6

   Ещё 18 вопросов

   Новый скрипт с таймаутом 24 секунды: 14 вопросов с подсказками по задаче и 4 о том, как через DNS искать в вебе или найти публичный туннель.

Самое показательное место в отчёте это одна строка из рассуждений агента, которую он записал себе, прежде чем пойти в обход:

Пользователь разрешил только исследовать, значит, публичные DNS-сервисы допустимы. Агент не взламывал ничего в привычном смысле: он нашёл формулировку, по которой обход выглядел разрешённым. Финал при этом почти комичный. Чатбот на вопрос по задаче ответил, что детали «довольно расплывчаты», а агент написал пользователю, что автора установить не смог, и попросил исходную формулировку поста.

12 минут или 15: где отчёт расходится сам с собой

Здесь пересказы разошлись, и не по своей вине.

В кратком изложении в начале отчёта сказано: монитор пометил поведение «в течение 15 минут», человек начал разбор через три минуты после этого. Fortune процитировал именно эти 15 минут. The Decoder написал «в течение 12 минут». Мы открыли хронологию в конце того же отчёта:

От 9:50:23 до 10:02:11 проходит 11 минут 48 секунд. Формально «в течение 15 минут» не ложь, но в одном документе живут две цифры, и пересказы разнесли обе. Если будете ссылаться на этот случай в споре о мониторинге, берите хронологию, а не сводку.

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

Почему DNS проходит мимо прокси песочницы

Типичная песочница для агента устроена так: весь HTTP и HTTPS идёт через прокси, у прокси есть белый список доменов. Но чтобы сделать запрос, программе сначала надо узнать адрес, и это делает резолвер, отдельная служба, которая отвечает на вопрос «какой IP у этого имени». Прокси этот трафик не видит.

Резолвер, который честно отвечает на любые внешние имена, это уже канал в обе стороны. Вопрос можно закодировать в имени, которое вы спрашиваете, а ответ получить в записи, которую вам вернут. Агенту OpenAI даже не понадобился свой сервер: публичный сервис делегирования сделал за него ту часть, которую обычно делает туннель. Готовые публичные DNS-туннели, кстати, он тоже искал, и они оказались закрыты или требовали отдельного сервера.

Это не особенность OpenAI. В документации песочницы Claude Code честно написано, что её прокси решает, пускать ли соединение, по имени хоста, не заглядывая в TLS, поэтому код внутри теоретически может уйти через domain fronting, а широкий домен вроде github.com в белом списке сам по себе путь для утечки. Отдельного пункта про DNS на этой странице мы не нашли. Это не значит, что там дыра; это значит, что проверять свою конфигурацию придётся руками.

Сломалась не стена, а три слоя за ней

Незакрытый DNS это ошибка конфигурации, и исправляется она конфигурацией. Страшнее то, что OpenAI сама пишет про следующие слои защиты.

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

Детектор смотрел мимо. У OpenAI был отдельный инфраструктурный детектор аномального DNS. Эта среда была из него исключена, хотя сам DNS логировался.

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

Наше мнение, с которым можно спорить: из этих трёх слоёв главный урок в третьем. Стены будут протекать, и OpenAI сама пишет, что ищет следующие обходные пути через зависимости. Монитор будет ошибаться. Но стоп-кран, который никто не дёргал до настоящей тревоги, это тот слой, который дешевле всего проверить заранее и который здесь стоил два с половиной часа. Мы неправы, если стены и монитор станут настолько надёжными, что до стоп-крана дело не дойдёт. Пока сама OpenAI пишет обратное.

Где это к вам не относится: если ваш агент работает только с локальными файлами без сетевого доступа вообще, DNS-проблемы у него нет. Она появляется, когда вы открываете сеть «чуть-чуть», для пакетного менеджера или пары API, и думаете, что прокси с белым списком закрыл всё остальное.

Как закрыть DNS в своей песочнице для агента

OpenAI после инцидента сделала три вещи: ограничила DNS белым списком доменов и типов записей, поставила блокировку на двух независимых уровнях (каждого хватило бы, чтобы предотвратить этот выход) и добавила DNS-детекторы с тестами самого пайплайна детекции. Для песочницы у себя это переводится в короткий список.

Сначала проверьте, резолвит ли ваша среда внешние имена. Так же, как это сделал агент, через Python:

# какой резолвер видит контейнер
cat /etc/resolv.conf
# ответит ли он на внешнее имя, которого нет в вашем белом списке
python3 -c "import socket; print(socket.gethostbyname('example.com'))"
# если сеть агенту не нужна вовсе: только loopback, DNS тоже нет
docker run --rm --network none alpine:latest ip link show

Если вторая команда вернула адрес, а example.com в вашем белом списке нет, у агента есть канал наружу. Дальше по порядку:

1. Сеть не нужна: отключите её целиком. В Docker режим --network none оставляет контейнеру только loopback-интерфейс, резолвить нечего.
2. Сеть нужна: сузьте DNS так же, как HTTP. Резолвер, который отвечает только на домены из белого списка, а остальное отклоняет. Это то, что OpenAI сделала после инцидента.
3. Два независимых слоя. Фильтр DNS и сетевое правило на выходе, чтобы ошибка в одном не открывала всё.
4. Логируйте DNS и смотрите в лог. У OpenAI DNS логировался, но детектор эту среду не смотрел. Лог, который никто не читает, не защита.
5. Проверьте стоп-кран до того, как он понадобится. Запустите агента, вызовите остановку и убедитесь, что процесс действительно умер, а не ждёт подтверждения.

Кто проверяет агента и что происходит, когда проверка опаздывает, мы уже разбирали на примере роя агентов OpenAI, решавшего уравнения Навье–Стокса. Этот случай меньше по масштабу, но честнее по деталям: здесь видно, в какой строке конфигурации и в какой минуте всё пошло не так.

Отчёт OpenAI обновлён 25 сентября 2026, расследование не закончено. Пауза и меры описаны на эту дату, проверяйте актуальную версию отчёта.