Риски DNS-эксфильтрации в песочницах ИИ-агентов

Риск DNS-эксфильтрации имеет значение, когда код в песочнице может разрешать домены, контролируемые атакующим, или использовать DNS в качестве исходящего канала данных. Поэтому командам следует оценивать политику DNS, журналирование, пути получения пакетов и доказательства инцидентов, прежде чем доверять песочнице ИИ-агента обработку чувствительных рабочих процессов.

Почему DNS важен в моделях угроз песочниц

Песочницы ИИ-агентов созданы для полезной автономии. Агент-программист может запускать тесты, устанавливать пакеты, вызывать API, запускать браузер, просматривать файлы и создавать артефакты без одобрения каждого действия человеком. Именно эта гибкость требует отдельного рассмотрения сетевого поведения, отдельно от изоляции ЦП, памяти, файловой системы и процессов.

DNS часто получает меньше внимания, чем HTTP-исходящий трафик, потому что выглядит как инфраструктурная сантехника. Приложениям необходимо разрешение имен для доступа к API, реестрам, веб-страницам и конечным точкам обновлений. Но DNS по-прежнему является исходящей связью. Песочница, которая может разрешать произвольные домены, может раскрывать информацию через имена запросов, связываться с инфраструктурой, контролируемой атакующим, или создавать слепую зону, если DNS-трафик не регистрируется с той же тщательностью, что и веб-запросы.

Это не теоретическая категория, придуманная для ИИ-агентов. MITRE ATT&CK документирует DNS как протокол прикладного уровня, который противники могут использовать для связи с командным центром, и отдельно документирует эксфильтрацию по альтернативным протоколам, когда данные покидают систему по каналу, отличному от основного протокола приложения. Для оценщиков песочниц урок прост: не относитесь к DNS как к безвредному только потому, что это не HTTP POST.

Для ИИ-агентов риск обычно возникает из цепочки небольших разрешений, а не из одной очевидной ошибки:

Возможность песочницы	Почему команды разрешают это	Вопрос, связанный с DNS
Установка пакетов	Позволяет агентам устанавливать недостающие зависимости	Какие реестры и пути разрешения разрешены?
Веб-доступ	Позволяет браузерным агентам собирать публичный контекст	Может ли код разрешать любые домены или только разрешенные?
Вызовы API	Позволяет агентам интегрироваться с бэкендами приложений	Заблокированы ли внутренние домены и конечные точки метаданных?
Инструменты сборки	Позволяет агентам-программистам запускать реалистичные тесты	Могут ли скрипты после установки вызывать неожиданные запросы?
Длительные сессии	Позволяет агентам продолжать многошаговые задачи	Сохраняются ли журналы DNS на протяжении всего жизненного цикла сессии?

Цель — не запретить каждый сетевой вызов. Многим рабочим нагрузкам агентов требуется контролируемый сетевой доступ. Цель — знать, какие пути существуют, какие заблокированы и какие доказательства у вас будут, если задача поведет себя неожиданно.

Где разрешение DNS появляется в рабочих процессах агентов

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

Общие пути DNS включают:

• Прямые запросы кода из Python, JavaScript, shell-скриптов, SDK и тестовых наборов.
• Автоматизация браузера, загружающая страницы, подресурсы, шрифты, изображения, скрипты аналитики и перенаправления.
• Менеджеры пакетов, такие как npm, pip, uv, pnpm, apt, cargo или устанавливаемые плагины для конкретных языков.
• Инструменты сборки, которые загружают бинарные файлы, шаблоны, драйверы браузера, файлы моделей или тестовые фикстуры.
• Инструменты агента, вызывающие сторонние API или конечные точки вебхуков.
• Фоновые задачи, которые продолжают выполняться после возврата видимого шага агента.

Это картографирование должно включать как предполагаемый, так и случайный трафик. Разработчик может попросить агента запустить только один модульный тест, но команда теста может установить пакет, менеджер пакетов может разрешить домен реестра, а скрипт жизненного цикла может связаться с отдельным хостом. Задача браузера может быть ограничена одним публичным сайтом, в то время как встроенные ресурсы разрешают множество дополнительных доменов.

Для поставщика песочниц самый сильный ответ — не просто «сетевой доступ доступен» или «сетевой доступ изолирован». Полезный ответ объясняет путь разрешения:

• Использует ли DNS песочницы управляемый провайдером резольвер, управляемый клиентом резольвер, VPC-резольвер или публичный резольвер?
• Может ли клиент ограничивать домены, IP-диапазоны, порты или протоколы?
• Регистрируются ли DNS-запросы для каждой песочницы, сессии, команды или только на агрегированном сетевом уровне?
• Регистрируются ли отклоненные запросы или только разрешенные?
• Могут ли клиенты разделять DNS получения пакетов и DNS времени выполнения?

Если эти детали недоступны, относитесь к ним как к открытым пунктам оценки, а не как к доказательству небезопасности песочницы. Практический риск зависит от чувствительности рабочей нагрузки, секретов, доступных внутри песочницы, политики исходящего трафика и качества судебно-медицинских доказательств.

Как оценивать политику исходящего трафика

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

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

Затем разделите политику DNS и политику HTTP. Некоторые системы применяют списки разрешенных HTTP, но оставляют разрешение имен широким. Это может создать несоответствие: запрос к неодобренному хосту может быть отклонен на уровне HTTP, но DNS-запрос все равно покидает среду и может нести метаданные в запрашиваемом имени. Более строгий дизайн оценивает разрешение и попытки соединения вместе.

Для проверок безопасности используйте такую матрицу политики:

Область оценки	Что спросить	Более убедительное доказательство
Исходящий трафик по умолчанию	Открыт ли исходящий сетевой доступ, запрещен или ограничен шаблоном?	Задокументированная политика по умолчанию плюс результат теста на уровне песочницы
Путь резольвера DNS	Какой резольвер обрабатывает DNS песочницы?	Диаграмма архитектуры или подтверждение конфигурации
Списки разрешенных доменов	Могут ли команды разрешить только одобренные реестры и API?	Пример конфигурации и пример журнала отклонений
Блоки IP и частных сетей	Заблокированы ли внутренние диапазоны и службы метаданных по умолчанию?	Задокументированные правила запрета и тестовые доказательства
Контроль протоколов	Контролируются ли DNS, HTTP, HTTPS и сырые сокеты отдельно?	Модель политики, а не только маркетинговые формулировки
Процедура исключений	Кто может добавлять домены или ослаблять политику?	Утверждение на основе ролей и запись аудита

Для большинства команд первой практической целью является не идеальная среда с нулевым исходящим трафиком. Это задокументированный профиль с минимальным исходящим трафиком: одобренные реестры пакетов, одобренные домены API, отсутствие доступа к внутренним сетям, если только явно не направлено, и журналы как для разрешенных, так и для отклоненных попыток.

Получение пакетов и DNS, управляемый зависимостями

Установка пакетов — один из самых простых способов недооценить исходящий трафик песочницы. Код, сгенерированный агентом, часто не работает из-за отсутствующих зависимостей, и самый быстрый опыт разработки — позволить агенту установить необходимое. Это удобство создает вторую проблему цепочки поставок: имена пакетов, перенаправления реестра, скрипты установки и бинарные загрузки могут инициировать DNS и сетевую активность, о которой исходный запрос даже не упоминал.

Руководство OWASP по приложениям LLM указывает на риски, связанные с чрезмерной автономией и воздействием цепочки поставок. В песочницах агентов эти риски пересекаются при установке пакетов. Модели может быть разрешено выбирать команды. Команда может вызвать менеджер пакетов. Менеджер пакетов может загрузить код из реестра. Загруженный пакет может запустить хуки установки. Каждый шаг может создавать DNS-запросы и исходящие соединения.

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

• Предпочитайте фиксированные файлы зависимостей для повторяемых задач агента.
• Используйте одобренные реестры или сквозные кэши для распространенных экосистем.
• Записывайте имя пакета, версию, URL реестра, разрешенные домены и хеши артефактов, где это возможно.
• Разделяйте разрешение на установку пакетов и общий доступ к интернету во время выполнения.
• Требуйте одобрения перед установкой пакетов за пределами списка разрешенных для чувствительных рабочих пространств.
• Рассмотрите предварительно созданные шаблоны песочниц для распространенных стеков, чтобы агентам не требовался широкий сетевой доступ при каждом запуске.

Важное различие в том, что «получение пакета» — это не один элемент управления. Он включает разрешение DNS, аутентификацию реестра, загрузку артефактов, выполнение кода во время установки и поведение кэша. Хорошая проверка песочницы спрашивает о всем пути.

Секреты и предположения о раскрытии данных

DNS-эксфильтрация имеет значение только в том случае, если есть что утекать. Это делает размещение секретов и ограничение данных частью проверки DNS.

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

Используйте следующие предположения при проектировании рабочих процессов с более высоким риском:

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

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

Журналы, аудиторские следы и доказательства инцидентов

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

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

• Время создания песочницы, шаблон, конфигурация ресурсов и владелец.
• Команды, выполненные агентом или пользователем.
• Файлы, прочитанные, записанные, загруженные или скачанные, когда продукт предоставляет доступ к файловым операциям.
• Установки пакетов и получение из реестров.
• DNS-запросы, включая метку времени, запрошенное имя, результат и идентификатор песочницы/сессии.
• Попытки исходящих соединений, включая хост назначения, IP, порт, протокол, результат разрешения/отклонения и объем, где это возможно.
• Вызовы инструментов, события навигации браузера и фоновые процессы.
• События внедрения секретов без раскрытия значений секретов в журналах.
• События завершения сессии, приостановки, возобновления, создания снимка и очистки.

Не спрашивайте только о журналах успешного трафика. Отклоненные события часто более полезны для оценки того, сработала ли политика. Если песочница пытается разрешить неодобренный домен, и политика блокирует его, этот отклоненный запрос является доказательством, которое отличает работающий контроль от молчаливого сбоя.

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

Заметки по оценке Novita Agent Sandbox

Novita Agent Sandbox разработана для рабочих процессов ИИ-агентов, которым требуется изолированное выполнение кода, автоматизация браузера, задачи в стиле использования компьютера, длительные сессии и рабочие нагрузки для оценки или обучения с подкреплением. Обзор Novita Agent Sandbox — это правильная отправная точка для текущего поведения продукта, а страница продукта Agent Sandbox описывает более широкое соответствие платформе.

При оценке Novita или любого другого поставщика песочниц для чувствительных к DNS рабочих нагрузок разделяйте два типа утверждений:

• Соответствие продукта: поддерживает ли песочница необходимый рабочий процесс агента, например выполнение кода, автоматизацию браузера или длительные задачи.
• Доказательства мер безопасности: соответствуют ли точные средства контроля DNS, исходящего трафика, получения пакетов, секретов и журналов вашей внутренней политике.

Это разделение предотвращает чрезмерные заявления. Песочница может хорошо подходить для выполнения агентом и все равно требовать специальной проверки клиентом для политики DNS, пути резольвера, списков разрешенных, хранения аудита и рабочих процессов инцидентов. Команды безопасности должны запрашивать текущую документацию или подтверждение продукта для этих деталей контроля, прежде чем одобрять чувствительные рабочие нагрузки.

Для команд, уже использующих модели Novita AI, соответствие платформе заключается в том, что API моделей и инфраструктура выполнения агента могут оцениваться вместе. Это может уменьшить операционное разрастание, но не отменяет необходимость в модели угроз. Относитесь к песочнице как к контролируемой среде выполнения, определите, какой сетевой доступ нужен каждому классу агента, и убедитесь, что доказательства контроля соответствуют риску данных, размещенных внутри.

Контрольный список проверки безопасности

Используйте этот контрольный список перед одобрением рабочих нагрузок песочницы ИИ-агента, которые могут затрагивать чувствительный код, учетные данные, данные клиентов или внутренние системы.

Вопрос проверки	Почему это важно
Что может разрешать песочница по умолчанию?	DNS может быть исходящим сигналом, даже если HTTP заблокирован.
Можно ли ограничить DNS по домену, шаблону, рабочему пространству или политике VPC?	Чувствительные рабочие нагрузки требуют более узких настроек по умолчанию, чем задачи публичных исследований.
Регистрируются ли DNS-запросы для каждой сессии песочницы?	Реагирование на инциденты требует атрибуции, а не только агрегированных метрик резольвера.
Регистрируются ли отклоненные попытки DNS и соединений?	Отклоненные события доказывают, что политика заблокировала неожиданное поведение.
Разрешены ли реестры пакетов в списке разрешенных или используются прокси?	Менеджеры пакетов могут инициировать DNS и загрузки, управляемые зависимостями.
Можно ли разделить установку пакетов и сетевой доступ во время выполнения?	Риски времени сборки и времени выполнения различны.
Заблокированы ли внутренние IP-диапазоны и конечные точки метаданных?	Агенты не должны случайно обнаруживать или связываться с плоскостями управления инфраструктуры.
Как внедряются, ограничиваются, ротируются и скрываются секреты?	Проверка DNS неполна, если долгоживущие секреты доступны коду в песочнице.
Видны ли подресурсы браузера в журналах?	Браузерные агенты могут разрешать больше доменов, чем URL верхнего уровня.
Какие доказательства доступны после приостановки, возобновления, создания снимка или очистки?	Длительные сессии требуют телеметрии, учитывающей жизненный цикл.
Кто может ослаблять политику исходящего трафика?	Изменения исключений должны быть проверяемыми.
Как сохраняются подозрительные сессии?	Очистка не должна стирать единственные полезные доказательства инцидента.

Если несколько ответов неизвестны, оставьте рабочую нагрузку за пределами песочницы, пока поставщик или внутренняя платформенная команда не смогут задокументировать путь контроля. Если рабочая нагрузка обрабатывает только публичные данные и не использует секреты, те же пробелы могут быть приемлемы на раннем этапе прототипирования, но их все равно следует отслеживать перед использованием в производстве.

Заключение

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

Используйте более широкий сетевой доступ для низкорисковых прототипов только тогда, когда данные не являются чувствительными, а агент не имеет значимых секретов. Для чувствительных кодовых баз, данных клиентов, внутренних API или регулируемых рабочих процессов требуйте профиль с минимальным исходящим трафиком и текущие доказательства от поставщика, прежде чем предоставлять агентам автономное выполнение.

Часто задаваемые вопросы

Актуальна ли DNS-эксфильтрация, если песочница блокирует HTTP?

Да. Средства управления HTTP и DNS — это разные уровни. Песочница может блокировать исходящие веб-запросы, все еще разрешая DNS-запросы. Командам безопасности следует проверять как политику разрешения, так и политику соединений.

Должны ли песочницы ИИ-агентов не иметь доступа в интернет?

Не всегда. Многие полезные задачи агента требуют доступа к реестрам пакетов, публичной документации, API или браузеру. Более безопасная цель — минимальный, объяснимый исходящий трафик: разрешить то, что нужно для задачи, запретить то, что не нужно, и записывать как разрешенную, так и отклоненную активность.

Одно ли и то же установка пакетов и общий сетевой доступ?

Нет. Установка пакетов заслуживает отдельной политики, поскольку включает реестры, разрешение зависимостей, загрузку артефактов, а иногда и скрипты во время установки. Команда может разрешить получение пакетов через одобренный кэш, запрещая произвольный исходящий трафик во время выполнения.

Какие журналы наиболее важны для оценки риска DNS?

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

Может ли поставщик песочниц гарантировать отсутствие утечки данных?

Будьте осторожны с абсолютными гарантиями. Поставщик может предложить изоляцию, сетевые средства управления, журналирование и параметры конфигурации, но окончательный риск зависит от проектирования рабочей нагрузки, секретов, размещения данных, политики исходящего трафика и операционного мониторинга.

Рекомендуемые статьи

• Как песочницы агентов обеспечивают безопасные, масштабируемые инновации в области ИИ
• Создание агента-программиста с помощью Agent Sandbox от Novita
• Создание MCP-сервера для удаленного выполнения кода с помощью Novita Sandbox и библиотеки mcp-use