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

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

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

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

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

Песочница может быть сильна в изоляции хоста, но слаба в контроле исходящего трафика. Сильна в исходящем трафике, но слаба в обработке секретов. Оценка «насколько безопасно» требует проверки каждого измерения отдельно, а не принятия единого ярлыка вроде «контейнеризировано» или «на базе 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. Это путь для утечки данных, путь для кражи секретов и путь для управления и контроля (C2) независимо от модели изоляции.

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

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

Секреты в переменных окружения: Переменные окружения, видимые процессу агента, читаются любым кодом, который агент запускает. Если учетные данные базы данных или ключ 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: Регулирование (throttling) или жесткие лимиты на сессию предотвращают монополизацию ресурсов хоста одной сессией.
• Ограничения памяти: Политики OOM kill должны завершать сессию песочницы, а не процесс хоста.
• Дисковые квоты: Лимиты записи на сессию предотвращают заполнение общего хранилища одной сессией.
• Тайм-аут выполнения: Сессии, превышающие лимит времени, должны корректно завершаться, а не оставаться работающими.
• Сетевые лимиты скорости: Ограничения исходящей пропускной способности могут сдерживать утечку данных, даже если политика исходящего трафика разрешает адресат.
• Лимиты параллельных процессов: Агенты, которые агрессивно ветвятся или порождают фоновые процессы, могут исчерпать слоты таблицы процессов.

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

Аудиторская видимость

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

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

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

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

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

Используйте этот контрольный список при оценке управляемого сервиса песочницы или фреймворка песочницы с открытым исходным кодом:

Изоляция

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

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

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

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

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

Секреты

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

Лимиты ресурсов

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

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

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

Аренда

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

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

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

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

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

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

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

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

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

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

Уязвимости нулевого дня: Все модели изоляции имеют известные и неизвестные уязвимости. Изоляция microVM обеспечивает самую сильную границу в текущем производственном использовании, но уязвимости VMM существуют. Глубокоэшелонированная защита (defense-in-depth) — сочетание нескольких средств контроля, а не доверие одной границе — более надежная позиция, чем любая отдельная модель изоляции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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