Насколько безопасна AI-песочница для выполнения кода?

AI-песочница для выполнения кода настолько же безопасна, насколько безопасна её граница изоляции — и эта граница лишь часть ответа. Лучше спросить: что именно изолирует песочница и что всё ещё может выйти за её пределы? Большинство песочниц хорошо справляются с одними вещами (выполнение кода на уровне процессов, произвольная запись в файловую систему хоста) и оставляют другие открытыми по умолчанию (исходящий сетевой трафик, установка пакетов, секреты в переменных окружения). Понимание этих пробелов — вот как вы оцениваете, подходит ли песочница вашей модели рисков. Для ознакомления с тем, что такое AI-агентная песочница и как основные концепции — изоляция, исходящий трафик, создание снимков, microVM — сочетаются друг с другом, см. руководство по определению, прежде чем углубляться в детали безопасности.

Что значит «безопасный» для песочницы выполнения кода

Безопасность в песочнице выполнения кода — это не бинарное свойство. Это набор средств контроля, каждое из которых решает определённую категорию рисков. Когда кто-то спрашивает «безопасна ли эта песочница?», обычно он задаёт несколько разных вопросов одновременно:

• Изоляция хоста: Может ли код, выполняемый внутри песочницы, вырваться на хост-систему?
• Изоляция клиентов: Может ли код одного пользователя повлиять на сеанс другого?
• Контроль исходящего трафика: Может ли код внутри песочницы выходить в интернет, обращаться к внутренним сервисам или конечным точкам метаданных?
• Область действия секретов: Доступны ли учётные данные большему количеству частей песочницы, чем необходимо?
• Риск цепочки поставок: Может ли установка пакетов привести к появлению неожиданного или вредоносного кода?
• Аудируемость: Можно ли восстановить, что именно делал агент постфактум?

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

Сравнение уровней изоляции

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

Изоляция процессов

Изоляция процессов использует примитивы уровня ОС — пространства имён Linux, cgroups, фильтры seccomp и профили AppArmor или SELinux — для ограничения доступа процесса. Песочница работает как процесс на хостовой ОС, разделяя ядро хоста.

Что предотвращает: Доступ к файловой системе хоста в целом, другим процессам вне песочницы и системным вызовам, явно заблокированным политикой seccomp.

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

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

Изоляция контейнеров (Docker/пространства имён)

Изоляция контейнеров расширяет изоляцию процессов более структурированной моделью образов, сетевыми пространствами имён и монтированием томов. Большинство реализаций песочниц на базе Docker запускают код внутри контейнера с минимальным образом и ограниченным профилем seccomp.

Что предотвращает: Прямой доступ к файловой системе хоста, большинство сетевых подключений к соседним контейнерам (при правильной конфигурации), лёгкий доступ к процессам хоста.

Что не предотвращает: Эксплойты уровня ядра всё ещё применимы — контейнеры разделяют ядро хоста. Неправильно настроенные монтирования томов, слишком широкие профили seccomp, режим --privileged и открытые сокеты Docker могут свести на нет предполагаемую границу.

Когда уместно: Многие производственные развёртывания эффективно используют контейнеры для выполнения AI-кода, когда профиль seccomp строгий, образ минимальный, исходящий трафик ограничен и не предоставляется привилегированный доступ. Модель риска отличается от microVM, но управляема при тщательной настройке.

Изоляция microVM (Firecracker/gVisor)

Изоляция microVM запускает каждую песочницу в лёгкой виртуальной машине с собственным гостевым ядром, изолированным от хоста границей гипервизора KVM. Firecracker — самая распространённая реализация; gVisor (с собственным ядром в пространстве пользователя) предлагает другой компромисс.

Что предотвращает: Эксплойты гостевого ядра не распространяются на ядро хоста или другие гостевые системы. Поверхность атаки хоста сводится к VMM (монитору виртуальных машин), который спроектирован как минимальный.

Что не предотвращает: Уязвимости в самом VMM (редкие, но возможные). Сетевой трафик, управление пакетами и секретами всё ещё находятся за пределами границ ВМ — изоляция microVM не решает эти вопросы.

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

Модель изоляции	Ядро хоста общее	Разделение клиентов	Накладные расходы на запуск	Риск побега с хоста
Процесс	Да	Слабая	Наименьшие	Наибольший
Контейнер	Да	Умеренная	Низкие	Средний (зависит от конфигурации)
MicroVM	Нет	Сильная	Умеренные	Низкий

Что всё ещё может выйти за каждую границу

Модель изоляции касается выполнения кода во время выполнения. Она не решает автоматически вопрос о том, что попадает в песочницу или покидает её по другим путям.

Исходящая сеть: Все три модели изоляции оставляют управление исходящим сетевым доступом на усмотрение политики конфигурации. Открытый по умолчанию исходящий трафик означает, что код внутри песочницы может выходить в публичный интернет, обращаться к конечным точкам метаданных облака (169.254.169.254 на AWS и GCP), внутренним сервисам в той же сети и любым внешним API. Это путь для эксфильтрации данных, получения секретов и канал управления независимо от модели изоляции.

Установка пакетов: apt install, pip install или npm install загружают и выполняют код из внешнего реестра. Если песочница разрешает установку пакетов и имеет открытый исходящий трафик, атака с коллизией имён пакетов, сквоттингом или путаницей зависимостей может привести к внедрению вредоносного кода, который выполняется со всеми правами песочницы. Граница изоляции сдерживает радиус поражения, но не предотвращает установку.

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

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

Исходящий трафик и сетевые средства контроля

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

Конечные точки метаданных облака: На облачной инфраструктуре 169.254.169.254 (и его аналог для IPv6) предоставляет метаданные экземпляра, включая учётные данные IAM. Код внутри песочницы с открытым исходящим трафиком может получить доступ к этой конечной точке и извлечь учётные данные для базового хоста.

Эксфильтрация на основе DNS: Даже если HTTP заблокирован, исходящие DNS-запросы могут использоваться для эксфильтрации данных путём их кодирования в доменных запросах. Блокировка DNS требует фильтрации на уровне резолвера, а не просто блокировки TCP/UDP 53 для внешних серверов.

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

Средства контроля для оценки:

Средство контроля	Что предотвращает	Что проверить
Исходящий трафик по умолчанию запрещён	Исходящие подключения к не указанным в списке адресатам	Блокирует ли он также DNS, а не только TCP/UDP?
Исходящий трафик на основе белого списка	Подключения к неодобренным доменам	Настраивается ли белый список для клиента?
Блокировка конечной точки метаданных	Получение облачных учётных данных через 169.254.169.254	Блокируются ли также метаданные IPv6?
Исходящий прокси	Логирование и проверка всего исходящего трафика	Доступен ли журнал прокси?
Фильтрация DNS	Эксфильтрация через DNS и разрешение внутренних имён	Какой резолвер используется внутри песочницы?

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

Обработка секретов

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

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

Время жизни: Краткосрочные учётные данные значительно безопаснее долгоживущих. Если учётные данные утекают внутри песочницы, короткий TTL ограничивает окно воздействия. Многие облачные системы IAM поддерживают краткосрочные токены, срок действия которых истекает через минуты или часы.

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

Редактирование: Секреты должны быть отредактированы из stdout, stderr, полезной нагрузки ответа инструмента, контекста, видимого модели, и журналов аудита. Агент, который выводит своё окружение, вызывает env или передаёт токен в неудачный вызов API, может раскрыть учётные данные в журналы, которые затем хранятся или видны операторам.

Ограничения ресурсов и риск отказа в обслуживании

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

Средства контроля ресурсов для проверки:

• Ограничения CPU: Регулирование или жёсткие лимиты на сеанс предотвращают монополизацию ресурсов хоста одним сеансом.
• Ограничения памяти: Политики завершения при OOM должны завершать сеанс песочницы, а не процесс хоста.
• Дисковые квоты: Ограничения на запись для каждого сеанса предотвращают заполнение общего хранилища.
• Тайм-аут выполнения: Сеансы, превышающие лимит по времени, должны корректно завершаться, а не оставаться работающими.
• Ограничения сетевой скорости: Ограничения исходящей пропускной способности могут сдерживать эксфильтрацию, даже если политика исходящего трафика разрешает адресата.
• Ограничения на одновременные процессы: Агенты, которые агрессивно создают форки или фоновые процессы, могут исчерпать слоты таблицы процессов.

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

Видимость аудита

Средства контроля изоляции уменьшают радиус поражения, когда что-то идёт не так. Журналы аудита — это то, как вы узнаёте, что что-то пошло не так, и восстанавливаете произошедшее.

Для AI-песочниц агентов, в частности, полезное покрытие аудита включает:

• Выполнение процесса: Каждая запущенная команда с полным списком аргументов, UID и родительским процессом. Без списков аргументов curl и python в журнале не имеют смысла.
• Доступ к файловой системе: Чтение и запись в чувствительные пути. Записи и удаления имеют более высокий приоритет, чем чтения для большинства моделей угроз.
• Исходящая сеть: Адресаты, протоколы, DNS-запросы и объём переданных данных. Логирование DNS-запросов часто отсутствует, но важно.
• Установка пакетов: Менеджер пакетов, имя пакета, версия, исходный реестр и хеш.
• Жизненный цикл сеанса: События создания, приостановки, возобновления, завершения и очистки с кодами причин.
• События ограничения ресурсов: Завершение по OOM, регулирование CPU, завершение по тайм-ауту.

Механизм сбора так же важен, как и покрытие. Журналы, созданные внутри процесса песочницы, могут быть подавлены или изменены достаточно привилегированным агентом. Сбор на уровне ядра (через auditd, eBPF или инструментарий гипервизора) генерируется ниже уровня приложения, где у агента нет прав на запись.

Вопросы к любому провайдеру или проекту песочницы

Используйте этот контрольный список при оценке управляемого сервиса песочниц или фреймворка песочниц с открытым исходным кодом. Для сравнения ответов крупных провайдеров на эти вопросы см. Лучшие AI-песочницы для агентов в 2026 или Руководство по оценке E2B и Daytona.

Изоляция

• Получает ли каждый сеанс агента собственную изолированную среду или сеансы группируются в общих средах выполнения?
• Какая модель изоляции используется: процесс, контейнер или microVM?
• Разделяется ли гостевой ядро с хостом?

Сеть и исходящий трафик

• Исходящий трафик открыт по умолчанию или запрещён?
• Можно ли настроить политику исходящего трафика для каждого клиента или сеанса?
• Заблокирована ли конечная точка метаданных облака (169.254.169.254)?
• Как обрабатывается DNS внутри песочницы?

Установка пакетов

• Разрешена ли установка пакетов по умолчанию?
• Можно ли ограничить установки только одобренными реестрами?
• Регистрируются ли события установки с источником и хешем?

Секреты

• Как учётные данные внедряются в песочницу?
• Можно ли ограничить учётные данные конкретным инструментом или задачей, которая в них нуждается?
• Редактируются ли секреты из журналов и выходных данных, видимых модели?

Ограничения ресурсов

• Применяются ли ограничения на CPU, память, диск и тайм-аут?
• Что происходит при достижении лимита — регулирование, завершение или оповещение?

Журналы аудита

• Генерируются ли журналы на уровне ядра/гипервизора или внутри процесса песочницы?
• Какие категории событий регистрируются по умолчанию?
• Можно ли экспортировать журналы во внешнюю SIEM или систему агрегации?
• Какова политика хранения журналов?

Мультитенантность

• Изолированы ли рабочие нагрузки от разных клиентов друг от друга?
• Есть ли общие кеши, образы или монтирования, которые создают каналы между клиентами?

Где подходит Novita Agent Sandbox

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

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

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

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

Ограничения и что не устраняет ни одна песочница

Ни одна песочница не устраняет все риски. Понимание того, что остаётся за пределами границы, так же важно, как и понимание того, что обеспечивает граница.

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

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

Уязвимости нулевого дня: Все модели изоляции имеют известные и неизвестные уязвимости. Изоляция microVM обеспечивает самую сильную границу в текущем производственном использовании, но уязвимости VMM существуют. Защита в глубину — сочетание нескольких средств контроля, а не доверие одной границе — является более надёжной позицией, чем любая отдельная модель изоляции.

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

Регуляторные риски и риски соответствия: Средства контроля изоляции решают технические риски. Регуляторные требования (GDPR, HIPAA, SOC 2, ISO 27001) касаются обработки данных, хранения, документации и требований к аудиту, которые выходят за пределы того, что песочница обеспечивает на уровне инфраструктуры.

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

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

Насколько безопасна среда выполнения AI-кода в песочнице по сравнению с выполнением кода на сервере?

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

Означает ли изоляция microVM, что песочница полностью безопасна?

Нет. Изоляция microVM (Firecracker, на основе KVM) обеспечивает сильную границу хоста, которой нет у контейнеров с общим ядром. Но она не контролирует исходящий трафик, секреты, установку пакетов или покрытие аудита. MicroVM с открытым исходящим трафиком и без сбора журналов не является «полностью безопасной», даже если уровень изоляции сильный.

Может ли сгенерированный AI код вырваться из песочницы?

Это зависит от модели изоляции и конфигурации. Побеги из контейнеров требуют эксплуатации ядра или неправильной конфигурации; побеги из microVM требуют эксплуатации VMM. И то, и другое возможно, но редко. Более практичные риски — это эксфильтрация данных через разрешённые сетевые пути, чтение секретов из окружения или установка вредоносных пакетов через неограниченные менеджеры пакетов.

Каков самый большой риск безопасности в большинстве AI-песочниц для кода?

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

Стоит ли использовать управляемую песочницу или создать свою собственную?

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

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

Традиционная безопасность выполнения кода предполагает, что вы примерно знаете, какой код будет выполняться. AI-агенты меняют это: одна подсказка может заставить сеанс устанавливать пакеты, записывать файлы, выполнять команды оболочки, вызывать внешние API и порождать подпроцессы без явного одобрения разработчика для каждого шага. Это делает покрытие аудита более важным (вы не можете предвидеть каждое действие), контроль исходящего трафика более важным (агент может достичь адресатов, которых вы не ожидали), и ограничение области секретов более важным (агенту доступно всё в его окружении).

Каковы лучшие практики для изоляции AI-агентов в производстве?

Практический контрольный список изоляции для производственных развёртываний агентов: используйте изоляцию класса microVM (Firecracker или эквивалент), а не только контейнеры для недоверенного или предоставленного пользователем кода; выделяйте одну изолированную среду на задачу или сеанс пользователя — никогда не делите песочницу между несвязанными рабочими нагрузками; запретите исходящий трафик по умолчанию с явным белым списком для необходимых адресатов; внедряйте только те учётные данные, которые требуются для текущей задачи, используя краткосрочные токены; собирайте журналы аудита на уровне ядра или гипервизора, а не внутри процесса песочницы; применяйте ограничения CPU, памяти, диска и времени на сеанс; и агрессивно завершайте сеансы — уничтожайте эфемерные песочницы сразу после завершения задачи. Защита в глубину по всем этим средствам контроля обеспечивает значительно лучшую безопасность, чем любая отдельная сильная граница.

Что должны оценивать команды безопасности при проверке AI-песочниц для агентов для корпоративного развёртывания?

Корпоративная проверка безопасности должна охватывать шесть областей: (1) Изоляция — microVM или контейнер? Полностью ли изолирован каждый сеанс на уровнях файловой системы, процессов и сети? (2) Исходящий трафик — открыт по умолчанию или запрещён? Можно ли настроить политику исходящего трафика для клиента? Заблокирована ли конечная точка метаданных облака (169.254.169.254)? (3) Секреты — как внедряются учётные данные? Ограничены ли они для каждой задачи с помощью краткосрочных токенов? Удаляются ли они при завершении сеанса? (4) Аудит — генерируются ли журналы ниже уровня процесса песочницы (уровень ядра/гипервизора)? Можно ли экспортировать журналы в SIEM? (5) Размещение данных — доступно ли BYOC или VPC-развёртывание, чтобы рабочие нагрузки оставались в вашем облачном аккаунте? (6) Позиция соответствия — какие сертификаты есть у провайдера и какова их модель разделения ответственности? Для команд с регуляторными требованиями завершите этот обзор до производственного развёртывания, а не после.

Как работает изоляция ядра в AI-песочнице для агентов?

Изоляция ядра означает, что код агента выполняется в среде с собственным ядром, отделённым от ядра хоста границей аппаратной виртуализации (KVM). В песочницах на базе Firecracker каждый сеанс загружает минимальное гостевой ядро внутри microVM. Процессы внутри песочницы взаимодействуют с гостевым ядром; ядро хоста не видно и не доступно изнутри. Уязвимость, эксплуатируемая в гостевом ядре, не распространяется автоматически на хост, потому что граница KVM находится между ними. Это ключевое преимущество безопасности перед изоляцией на основе контейнеров, где все контейнеры разделяют ядро хоста, и эксплойт ядра затрагивает их все одновременно.

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

• Firecracker для AI-песочниц агентов: преимущества, ограничения и вопросы оценки
• Журналы аудита для AI-песочниц агентов: что нужно командам безопасности
• Песочница для сгенерированного AI кода: требования для производственных приложений