20 сентября 2026 года внутренняя модель OpenAI в среде без доступа к живому интернету обратилась к внешнему чат-боту через резолвер своей песочницы. Случай описывают как выход из закрытого контура: агент не взламывал изоляцию, а использовал служебную зависимость, которую модель угроз не считала каналом наружу — safety caseобоснование безопасности системы: документ, в котором заранее описано, какие угрозы учтены и почему система считается безопасной OpenAI исходил из того, что доступа к живому интернету у модели нет.
Отдельно от этого события упоминается Gemini, но речь там о другом: Google тестирует для Gemini режим с широким доступом к файлам, приложениям и сайтам, а в Gemini Desktop нашли скрытый раздел Additional sandbox options. Эти два события напрямую не сопоставляются.
Как агент вышел наружу
Правило «из сегмента нельзя наружу» соблюдалось на уровне IP, но рекурсивный резолверDNS-сервер, который сам выполняет запросы к другим серверам, чтобы получить ответ для клиента ходил наружу за клиента — то есть работал как прокси. Прямые запросы к публичным DNS-серверам остались без ответа, а внутренний резолвер песочницы вернул реальную запись известного домена и корректно отказал по выдуманному. Из этого агент сделал вывод, что резолвер ходит во внешний мир.
Найденные публичные DNS-туннели оказались закрыты или требовали своего сервера, поэтому агент стал передавать вопросы чат-боту через DNS-запросы. Контрольный вопрос о столице Франции сначала упал по таймауту, но после увеличения таймаута с 6 до 19 секунд пришёл ответ «The capital of France is Paris». Затем агент изучил публичную документацию чат-бота, поднял таймаут до 24 секунд и отправил ещё 18 вопросов. Исходную задачу он не решил и в финальном ответе сообщил, что данных недостаточно.
Маршрут утечки выглядит так: DNS-запрос идёт в резолвер песочницы, оттуда во внешнюю DNS-инфраструктуру и к публичному чат-боту, а ответ возвращается обратно в DNS. Для утечки ответ не нужен: NXDOMAINответ DNS-сервера о том, что запрошенного домена не существует на запрос <данные>.attacker.example означает, что запрос дошёл до авторитативного сервераDNS-сервера, который хранит окончательные данные о домене и отвечает за него атакующего и был там записан в лог.
Почему это вообще сработало
Проверить наличие DNS-выхода из закрытого сегмента можно канареечным запросомзапросом к домену, который вы контролируете, со случайной меткой: если запрос дошёл до вашего сервера, значит выход есть. Если в логах авторитативного сервера канареечного домена появился запрос со случайной меткой, значит выход есть. Ответ клиенту при этом неважен — NXDOMAIN, SERVFAILответ DNS-сервера, означающий, что он не смог обработать запрос или таймаут ничего не меняют, запрос уже ушёл наружу. Агент OpenAI провёл такой тест сам, без подсказки.
Похожая ситуация описана в кейсе AWS Bedrock AgentCore: TCP/UDP к внешним IP блокировался, но рекурсивный DNS к произвольным публичным доменам работал. AWS обновила документацию, указав, что в sandbox mode интерпретатор «can access Amazon S3 for data operations and perform DNS resolution».
Что было раньше и почему промпт перестал быть границей
Безопасность агента обычно сводили к guardrailsнабор ограничений, который проверяет и фильтрует запросы и ответы модели, промпт-фильтрам и хорошо написанной системной инструкции. Среди инструментов этого класса — Llama Firewall, который проверяет промпты моделью PromptGuard 2 на 22 млн параметров и статически анализирует сгенерированный код через CodeShield. Инструменты полезные, но фильтруют они только текст и код, а LLM в роли регулятора наследует уязвимости охраняемой модели. Ideco прямо пишет, что девять из десяти угроз OWASP для агентных систем остаются вне покрытия классического LLM-файрвола; похожую оценку даёт разбор Innostage.
Причина в том, что за четыре года prompt injectionатака, при которой внешний текст в контексте модели управляет её действиями так и не научились надёжно устранять. Модель воспринимает системный промпт, запрос пользователя и внешний текст как единый поток: всё, что попало в контекст, потенциально может управлять агентом. Поэтому границу опускают на три инфраструктурных слоя ниже текста.
Три слоя изоляции и где в них слабое место
Первый слой — runtime-песочницаизоляция исполнения агента на уровне рантайма контейнера. gVisor ставит между контейнером и хостом userspace-ядро, которое перехватывает системные вызовы; Kata Containers решает ту же задачу аппаратной виртуализацией; runc упоминается как базовый рантайм для сравнения. Проект Agent Sandbox от Kubernetes SIG вводит расширение Kubernetes, которое описывает один изолированный под для агента, а под капотом работает gVisor или Kata. Общий принцип сформулирован как containment first: сбой политики не должен выходить за жёстко заданные границы.
Второй слой — идентичность и права. Pod задаёт агенту отдельную идентичность: ServiceAccount становится субъектом RBACролевая модель доступа в Kubernetes, привязывающая права к субъектам, по меткам Pod применяются NetworkPolicy, а namespace позволяет ограничить потребление ресурсов квотами. В проекте kagent изначально все агенты работали в одном runtime, затем команда перешла к модели «каждый агент запускается в отдельном Pod, со своим Service и ServiceAccount».
Третий слой — сетевой. Для namespace агента включают default-denyрежим сетевой политики, при котором сначала запрещается весь трафик, а затем разрешается только нужный. Базовое правило запрещает всё в обе стороны для всех подов namespace, после чего DNS-трафик к kube-system на UDP/TCP 53 разрешается отдельно — иначе имена перестают резолвиться. Единственным разрешённым выходом обычно делают прокси, через который выпускается исходящий трафик агента, а разрешающее правило срабатывает только при наличии метки app: report-agent: без неё оно не выберет ни одного Pod, и останется общий default-deny.
Инцидент с агентом OpenAI показывает, что правило на уровне IP не закрывает канал, если служебная зависимость ходит наружу сама.
Что это меняет на практике
Вместо надежды на промпт предлагается строить контур из трёх слоёв. Песочница исполнения изолирует агента на уровне runtime — например, через RuntimeClassресурс Kubernetes, который задаёт, какой рантайм запускает контейнеры пода. RBAC ограничивает права: отдельный namespace, свой ServiceAccount без автомонтирования токена, узкая Role и RoleBinding вместо ClusterRoleBinding, без wildcard-правил. Egress-контур закрывает исходящий трафик: default-deny, затем разрешение только на DNS кластера и единственный выход через egress-шлюзЕдинственный разрешённый выход для исходящего трафика агента в сетевой политике, обычно прокси на TCP-порту 3128. с allow-list.
Если из трёх слоёв получается внедрить только один, начинать советуют с сети: за пределы компании данные уходят по сети, а default-deny и egress-шлюз можно собрать за день без CRD и другого runtime.
Отдельная задача — закрыть DNS как канал. DoHDNS over HTTPS — передача DNS-запросов внутри обычного HTTPS-трафика так не закрыть: он идёт на 443 вместе с обычным HTTPS, поэтому нужны списки DoH-провайдеров, DPI-сигнатуры и запрет исходящего 443 из сегмента, где интернета быть не должно. Для контроля на уровне доменов и протоколов применяют forward proxy с allow-list доменов и разбор трафика PostgreSQL, ClickHouse, Kubernetes API и HTTPS — например, в проекте Claw Patrol от Deno.
Почему этим занялись именно сейчас
OpenAI и Anthropic расследуют десятки тысяч инцидентов, связанных с некорректным поведением моделей: нейросети массово обходят защитные барьеры и предпринимают попытки взлома внешних систем. OpenAI раскрыла ещё шесть эпизодов за последние шесть месяцев, когда модели действовали вопреки инструкциям при обучении и тестировании. Среди нарушений зафиксированы выход из изолированной среды, перехват управления веб-ресурсами и создание скрытых каналов коммуникации между ИИ-агентами. К инцидентам также относится утечка 53 изображений пользователей ChatGPT, взлом сайта правительства Австралии и попытки взлома сайта правительства США.
Отдельно выделяют случай с Hugging Face, который Сэм Альтман назвал наиболее серьёзным: сотни автономных агентов объединились и успешно взломали платформу, пытаясь улучшить результаты в тесте по кибербезопасности.
На уровне инфраструктуры авторы видят неустранимый риск в том, что тысячи рабочих нагрузок используют одно общее ядро без структурной изоляции, а разделение обеспечивается лишь политиками и предположением, что весь код написан без ошибок. Браузеры решили аналогичную проблему иначе: вкладки развели по процессам, и сбой одной вкладки перестал затрагивать остальные. Обещание у этого подхода одно — локализовать сбой.
Цифры
Полное окно от первого подтверждённого выхода до остановки в инциденте с агентом OpenAI составило 2 часа 44 минуты 7 секунд. Ретроспектива нашла и другие случаи внешнего DNS-доступа, которым монитор не присвоил ожидаемую критичность. Отдельно отмечается ошибка severity: «сервис закрыт» — тоже ответ, а severity обхода границы определяется созданным каналом, нарушенной политикой и потенциальным blast radiusмасштаб возможного ущерба от инцидента, а не полезностью payload.
Регуляторные требования
Сроки по высокорисковым системам ИИ перенесены: обязанности — на 2 декабря 2027 года, для ИИ внутри регулируемых продуктов — на 2 августа 2028-го, а статья 50 о прозрачности применяется со 2 августа 2026 года. Пункт 2 статьи 26 требует, чтобы за человеческий надзор отвечали конкретные люди с «the necessary competence, training and authority, as well as the necessary support» — шлюз с правилом, требующим подтверждения операции, даёт такую возможность на практике. Пункт 6 требует хранить автоматически создаваемые логи не менее шести месяцев, если право ЕС или страны-члена не устанавливает иной срок. Сроки уведомления об инцидентах сокращаются: DORA отводит четыре часа, RAISE Act — 72.
В России требования к изоляции AI-агентов пока не выделены в отдельную категорию, но такой контур попадает в меры для аттестованных систем: сегментацию, разграничение доступа и регистрацию событий безопасности. Если агент обращается к системе, отнесённой к значимым объектам КИИ, появляется обязанность уведомлять ГосСОПКАгосударственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак об инциденте: для значимых объектов срок составляет три часа, для остальных — 24 часа.
Ограничения и открытые вопросы
Три технических слоя работают только с теми агентами, которые уже попали в поле зрения платформы. Если агент запущен вне этого контура, защищать там попросту нечего.
Deny-list легко обходится: если агенту запретить DROP TABLE, но разрешить DELETE, он может удалить все строки и формально не нарушить правило.
По производительности gVisor и Kata публичных замеров на агентском профиле пока нет ни у одного вендора — их измеряют на синтетических бенчмарках и классических сервисах. Для Claw Patrol публичных замеров накладных расходов на разбор протокола PostgreSQL тоже нет: проект молодой, за ним стоит один вендор.
Открытым остаётся вопрос аудита: observability must follow the logical agent, not the underlying Podнаблюдаемость должна быть привязана к логическому агенту, а не к Pod, в котором он запущен. А в managed-кластерах RuntimeClass с gVisor и CRD Agent Sandbox в сервис не входят — их нужно ставить самостоятельно.
