- Модели изоляции песочниц
- Исходящие соединения и сетевая политика песочницы
- Доступ к файлам и файловая система хоста
- Состояние сессии и сохранение
- Установка пакетов и зависимости времени выполнения
- Секреты и обработка учётных данных
- Журналы аудита и наблюдаемость
- Соответствие требованиям и проверка безопасности
- Ценообразование песочниц и факторы затрат
- Самостоятельный хостинг против управляемой песочницы AI-агента
- Рекомендуемые статьи
Модели изоляции песочниц
Что означает «изоляция» в песочнице AI-агента?
Изоляция означает, что код, файлы, процессы и сетевой доступ агента ограничены замкнутой средой, которая не может повлиять на хост-систему или других арендаторов. На практике изоляция — это спектр: изоляция на уровне процессов использует примитивы ОС (namespaces, cgroups, seccomp) для ограничения системных вызовов и доступа к ресурсам; изоляция в контейнерах добавляет границу файловой системы и сетевого пространства имён; а изоляция в микро-ВМ помещает рабочую нагрузку в лёгкую виртуальную машину с собственным гостевым ядром. Каждый шаг вверх по стеку увеличивает прочность границы ценой некоторого увеличения времени запуска и операционной сложности. См. Firecracker для песочниц AI-агентов для подробной структуры оценки.
Достаточно ли Docker для запуска кода, сгенерированного агентом?
Контейнеры дают повторяемые образы и хороший контроль ресурсов, но все контейнеры на одном хосте разделяют ядро хоста. Уязвимость ядра или системный вызов, проскользнувший через фильтр seccomp, может повлиять на другие рабочие нагрузки. Для низкорисковых краткосрочных задач с доверенным или почти доверенным кодом правильно укреплённые контейнеры часто достаточны — без привилегированного режима, с минимальными возможностями, без монтирования Docker-сокета, по возможности с корневой файловой системой только для чтения. Для недоверенного AI-генерированного кода, который может устанавливать пакеты, порождать подпроцессы или вызывать произвольные команды оболочки, стоит оценить более сильную границу. Ответ зависит от вашей реальной модели угроз. См. Песочница для AI-генерированного кода: требования для production-приложений для чек-листа проверки на каждом уровне изоляции.
В чём разница между изоляцией в контейнере и в микро-ВМ?
Ключевое различие — граница ядра. Контейнеры разделяют ядро хоста; микро-ВМ каждая запускает гостевую ОС внутри лёгкой виртуальной машины на базе аппаратной виртуализации (KVM). Песочница на основе микро-ВМ с использованием такой технологии, как Firecracker, обеспечивает границу уровня ВМ без полной нагрузки традиционной ВМ: время запуска оптимизировано, модель устройств минимальна для уменьшения поверхности атаки, а гость изолирован от ядра хоста по замыслу. Практическое следствие: эксплойт ядра в гостевой системе не влияет автоматически на хост или других гостей, тогда как в модели контейнеров с общим ядром это возможно. См. Firecracker для песочниц AI-агентов для описания, где граница микро-ВМ помогает, а где не решает всей проблемы.
Существует ли одна песочница на агента, на пользователя или на задачу?
Это зависит от платформы и от того, как спроектировано приложение. Самый безопасный паттерн для мультитенантных приложений — одна изолированная среда песочницы на запуск агента или на задачу, то есть каждое пользовательское взаимодействие имеет собственное дерево процессов, файловую систему, сетевое пространство имён и область действия учётных данных. Совместное использование песочницы разными пользователями или несвязанными задачами — самый частый источник утечки состояния в production-приложениях с агентами. При оценке платформы убедитесь, что параллельные сессии изолированы на уровне файловой системы, процессов и сети, а не только на уровне маршрутизации API. См. Песочница для AI-генерированного кода: требования для production-приложений для чек-листа изоляции на сессию.
Исходящие соединения и сетевая политика песочницы
Может ли AI-агент совершать исходящие сетевые вызовы из песочницы?
Зависит от политики исходящих соединений песочницы. По умолчанию многие песочницы разрешают исходящие соединения — это удобно для веб-исследований, вызовов API и установки пакетов. Для production-нагрузок с недоверенным кодом исходящие соединения, открытые по умолчанию, представляют риск: скомпрометированный или неправильно работающий агент может экспортировать данные, обратиться к внутренним метаданным или загрузить неожиданный код с произвольных URL. Более надёжная production-позиция — запрет исходящих соединений по умолчанию с явным белым списком разрешённых пунктов назначения. Какую бы политику вы ни выбрали, она должна быть явной и регистрироваться в журнале. См. Firecracker для песочниц AI-агентов для оценки сетевых средств управления.
Как контролируется DNS в песочнице?
DNS — это распространённый пробел в политике исходящих соединений: белый список для HTTP-назначений автоматически не ограничивает разрешение DNS. Агент, который может разрешать произвольные доменные имена, может собирать информацию о топологии сети, опрашивать внутренние имена или использовать DNS как побочный канал, даже если HTTP заблокирован. Для согласованной политики исходящих соединений разрешение DNS должно обрабатываться единообразно — либо через внутренний резолвер, который соблюдает белый список, либо с ограничением разрешения только на одобренные домены. Уточните у поставщика песочницы, как DNS учитывается в общей политике исходящих соединений.
Как контролируются загрузки пакетов во время сессий с ограниченным сетевым доступом?
Установка пакетов — это сетевые операции. Если исходящие соединения ограничены белым списком, в этот список должны быть включены реестры пакетов, которые агент легитимно использует, или песочница должна предоставлять кэш с предварительной выгрузкой в доверенной сети. Кэш с предварительной выгрузкой имеет дополнительное преимущество — он служит точкой инспекции: вы видите, какие пакеты были загружены, можете выявить неожиданные зависимости и уменьшить избыточный исходящий трафик. Некоторые команды используют предварительно собранные шаблоны песочниц для рабочих нагрузок, где воспроизводимость важнее гибкости, что полностью исключает загрузку пакетов во время выполнения. См. раздел Установка пакетов для получения дополнительной информации об управлении установками во время выполнения.
Доступ к файлам и файловая система хоста
Какой доступ к файлам имеет агент в песочнице?
Агент в песочнице должен иметь доступ только к файлам, явно смонтированным в его рабочее пространство. Для агента-программиста это может быть репозиторий кода и рабочий каталог для сгенерированных артефактов. Для агента анализа данных это может быть загруженный CSV-файл и папка для вывода. Агент не должен иметь доступа к файловой системе хоста, рабочим пространствам других арендаторов, секретам сервера приложений или системным каталогам вне смонтированных путей. Хорошей практикой является монтирование исходных материалов только для чтения и предоставление отдельного каталога для вывода (чтение-запись) для сгенерированных артефактов. См. Песочница MCP-сервера: изолированные MCP-серверы с контролем файловой системы, секретов и сети для настройки монтирования файловой системы для каждого инструмента.
Доступна ли файловая система хоста изнутри песочницы?
Не должна быть. Правильно настроенная песочница — контейнерная или микро-ВМ — ограничивает видимость агента только его собственной гостевой файловой системой. Доступ к файловой системе хоста изнутри песочницы — это ошибка конфигурации, а не ожидаемое поведение. Типичные ошибки, нарушающие эту границу: монтирование широких каталогов (например, домашнего каталога разработчика или /), использование привилегированного режима в контейнерах или монтирование Docker-сокета в песочницу. При оценке платформы или создании собственной проверьте, что смонтировано, какие права доступа у корневой файловой системы и могут ли обходы символьных ссылок или трюки с распаковкой архивов достичь путей за пределами предполагаемого рабочего пространства.
Что происходит с файлами после завершения сессии?
Для эфемерных сессий рабочий каталог и все сгенерированные файлы уничтожаются при завершении сессии. Это правильное поведение по умолчанию для завершения кода, прогонов оценки и любых задач, где воспроизводимость важнее непрерывности. Для постоянных рабочих пространств (долго работающие агенты-программисты, итеративные сессии разработки) файлы могут сохраняться между вызовами выполнения в рамках сессии и могут быть сохранены после завершения сессии, если платформа поддерживает сохранение рабочего пространства или снапшоты. Ключевые вопросы: кому принадлежит сохранённое рабочее пространство, когда оно очищается и может ли рабочее пространство одного пользователя просочиться к другому? См. Песочница для AI-генерированного кода: требования для production-приложений для чек-листа модели сохранения.
Состояние сессии и сохранение
Является ли сессия песочницы с сохранением состояния или эфемерной?
Существуют оба паттерна, и они обслуживают разные рабочие нагрузки. Эфемерные сессии начинаются с чистого базового состояния для каждой задачи — без накопленных пакетов, файлов или истории. Их легче анализировать, и они идеально подходят для прогонов оценки или однократного выполнения кода. Сессии с сохранением состояния сохраняют файлы, установленные пакеты, историю команд и состояние среды между несколькими вызовами выполнения, что необходимо для многошаговых агентов-программистов, интерактивного анализа данных и длительных рабочих процессов. Большинство production-платформ поддерживают оба варианта. Компромисс в том, что сессии с сохранением состояния требуют явных политик очистки и более тщательной изоляции арендаторов.
Как долго сохраняется состояние в управляемой песочнице?
Продолжительность сессии варьируется в зависимости от платформы и тарифа. Некоторые провайдеры устанавливают время ожидания сессии по умолчанию (обычно от 60 минут до 24 часов), после чего сессия завершается и состояние теряется, если не сохранено в снапшоте или внешнем хранилище. Длительные рабочие процессы с агентами — сессии, которые могут приостанавливаться между вызовами LLM на минуты или часы — требуют платформы, поддерживающей приостановку и возобновление сессии или автоматическую приостановку, чтобы избежать оплаты за простой, сохраняя при этом состояние. Уточните максимальную длину сессии и что происходит с состоянием в процессе выполнения при наступлении тайм-аута. Novita Agent Sandbox поддерживает сессии до 24 часов и документирует возможность приостановки/автовозобновления для управления временем простоя. См. Novita Sandbox: экономичная альтернатива E2B Pro с бесшовной совместимостью для сравнения функций.
Можно ли приостанавливать и возобновлять сессии?
Некоторые платформы поддерживают приостановку и возобновление, когда сессия сохраняется на диск и может быть перезапущена позже с того же состояния. Это полезно для агентов, ожидающих ответов LLM между шагами, для ограничения скорости дорогих рабочих нагрузок и для сессий, охватывающих несколько взаимодействий с пользователем с течением времени. Ключевые моменты, которые стоит проверить: как долго приостановленная сессия может оставаться в таком состоянии, что происходит с сетевыми соединениями, удерживаемыми во время приостановки, и остаются ли действительными учётные данные, введённые при запуске сессии, после возобновления или их нужно обновить.
Можно ли создавать снапшоты состояния песочницы и повторно использовать их?
Шаблоны и снапшоты — это разные, хотя и связанные концепции. Шаблон — это предварительно собранная базовая среда — среды выполнения, инструменты, одобренные пакеты — с которой начинаются новые сессии. Снапшот захватывает текущее состояние работающей сессии и использует его как отправную точку для будущих сессий. Шаблоны уменьшают накладные расходы на запуск каждой сессии и гарантируют, что все агенты начинают с согласованной, управляемой базовой линии. Снапшоты полезны для сохранения частичной работы или быстрого запуска итеративных заданий. Обе концепции требуют управления: кто может их создавать, кто может их читать, какому арендатору они принадлежат и как версионируются.
Установка пакетов и зависимости времени выполнения
Могут ли агенты устанавливать пакеты во время выполнения?
Большинство сред песочниц по умолчанию разрешают установку пакетов во время выполнения (pip install, npm install, apt-get и т. д.), потому что многим рабочим нагрузкам агентов это необходимо. Вопрос не в том, разрешена ли установка, а в том, управляется ли каждая установка. Неуправляемая установка пакетов — одна из самых рискованных операций в песочнице: она загружает внешний код в среду выполнения во время работы, может включать сценарии после установки, выполняющие произвольные команды, и может внести риск цепочки поставок.
Какие политики управляют установкой пакетов во время выполнения?
Production-политика пакетов обычно включает некоторую комбинацию: разрешение только одобренных реестров (только из утверждённых реестров или зеркал), кэши с предварительной выгрузкой (инспекция того, что попадает внутрь, до выполнения), журналирование установки (запись имени пакета, версии, источника и результата для каждой установки) и опциональный офлайн-режим (предварительная сборка зависимостей в шаблоне и запрет установки во время выполнения для конвейеров оценки, где важна воспроизводимость). Правильная политика зависит от рабочей нагрузки: агенту-программисту, помогающему разработчику отлаживать код, может потребоваться гибкий доступ к пакетам; автоматический конвейер оценки должен, вероятно, работать из замороженной среды. См. Создание AI-аналитика данных с помощью песочницы Python и контролируемого доступа к пакетам для практического примера реализации.
Секреты и обработка учётных данных
Как обрабатываются секреты и учётные данные в песочнице?
Секреты следует внедрять узко — только те учётные данные, которые нужны для конкретной задачи, на время этой сессии. Распространённый антипаттерн — монтировать широкий файл окружения, содержащий все ключи API, в каждую сессию; это означает, что любая сессия, если она скомпрометирована, может получить доступ к каждому учётному данным в этом файле. Предпочитайте краткосрочные токены с ограниченной областью действия и механизмы внедрения (переменные окружения или смонтированные файлы), а не жёсткое кодирование. Для самых чувствительных учётных данных API секретов времени выполнения, предоставляющий значения только явно авторизованному процессу, обеспечивает более сильную изоляцию, чем плоская переменная окружения, доступная всем процессам.
Может ли модель видеть переменные окружения, внедрённые в песочницу?
Да, если переменная окружения внедрена в процесс, в котором выполняется код модели. Переменные окружения по умолчанию видны всем процессам в той же сессии. Модель не может прочитать их напрямую из своего контекстного окна, но сгенерированный код, который выполняется внутри песочницы, может прочитать их с помощью os.environ, process.env или их эквивалентов. Вот почему важна узкая область действия: внедряйте только те учётные данные, которые требуются задаче, и предпочитайте краткосрочные токены, чтобы утёкшие учётные данные имели ограниченное окно полезности. Редактирование — это ответственность приложения: не регистрируйте полный stdout по умолчанию, если секреты могут появляться в сообщениях об ошибках или операторах печати.
Что происходит с секретами после завершения сессии?
Переменные окружения и смонтированные файлы с секретами должны быть очищены в процессе завершения сессии. Если платформа сохраняет состояние между сессиями (снапшоты, постоянные тома), убедитесь, что учётные данные, записанные в файловую систему или кэшированные провайдером учётных данных, также очищаются или ротируются. Устаревшие учётные данные в возобновляемом снапшоте представляют риск — после завершения сессии снапшот не должен содержать токены, которые были действительны только на время исходной сессии.
Журналы аудита и наблюдаемость
Какие события регистрируются в песочнице?
Полезные записи аудита песочницы включают: создание и завершение сессии (идентификатор сессии, арендатор, версия шаблона, выделение ресурсов, продолжительность), события выполнения (какая категория кода или команды запускалась, время начала/окончания, код завершения), установку пакетов (имя, версия, источник, результат), исходящие сетевые контакты (домены, IP-адреса, порты), файлы, прочитанные или записанные из определённых путей, и результат очистки. Цель — сделать поведение агента восстанавливаемым постфактум, не превращая журнал аудита во второе хранилище секретов. Сырые файлы клиентов, полный вывод команд и полные запросы, как правило, не должны попадать в журналы аудита, если только ваши политики хранения и контроля доступа специально не предназначены для таких данных.
Кто может получить доступ к журналам аудита?
Контроль доступа к журналам аудита должен быть ограничен оператором и, где это уместно, арендатором. В мультитенантных платформах записи аудита одного арендатора не должны быть видны другим арендаторам. Для развёртываний, чувствительных к соответствию требованиям, цепочка аудита должна быть защищена от изменений, храниться в течение требуемого периода и быть доступной уполномоченным рецензентам (команда безопасности, сотрудник по соблюдению нормативных требований) по запросу. Спросите у поставщика песочницы, какой период хранения журналов предоставляется по умолчанию, можно ли экспортировать журналы в вашу собственную SIEM или хранилище, и какие средства контроля доступа защищают данные журналов.
Соответствие требованиям и проверка безопасности
Какая проверка соответствия требованиям необходима перед использованием песочницы в production?
Конкретные требования зависят от вашей отрасли и юрисдикции, но стандартные вопросы для любой production-системы с агентами включают: какие данные попадают в песочницу (и подлежат ли эти данные GDPR, HIPAA, SOC 2 или другим фреймворкам), где размещена песочница и удовлетворяет ли это требованиям к местонахождению данных, какова модель изоляции и можно ли её задокументировать для аудитора, как управляются и ротируются учётные данные и как выглядит цепочка аудита? Большинство проверок безопасности также спросят, может ли сгенерированный код получить доступ к production-базам данных, внутренним административным интерфейсам или данным клиентов за пределами предполагаемой области. Это архитектурные средства контроля, а не просто сертификаты поставщика.
Какие вопросы следует задавать командам безопасности при оценке песочницы AI-агента?
Практический чек-лист для оценки безопасности:
- Изоляция: Какова граница — процесс, контейнер или микро-ВМ? Каждая ли сессия агента изолирована на уровне файловой системы, процессов и сети?
- Исходящие соединения: Какова политика исходящих соединений по умолчанию? Можно ли настроить белый список исходящих назначений? Как контролируется DNS?
- Секреты: Как внедряются учётные данные? Ограничены ли они задачей? Очищаются ли они при завершении сессии?
- Аудит: Какие события регистрируются? Кто может получить доступ к журналам? Каков период хранения?
- Местонахождение данных: Где размещаются песочницы? Можно ли ограничить развёртывание конкретным облачным регионом или аккаунтом?
- Соответствие требованиям: Есть ли у поставщика соответствующие сертификаты (SOC 2, ISO 27001)? Какова модель разделения ответственности?
- Сетевой доступ: Может ли песочница получить доступ к внутренним службам метаданных, частным API или ресурсам других арендаторов? Как предотвращается боковое перемещение?
Формулируйте это как вопросы для оценки, а не как требования, которым любой отдельный поставщик автоматически соответствует. Заявления о безопасности и соответствии в документации поставщика следует проверять по текущим документам на продукт, а не принимать за чистую монету. Для команд с нормативными или контрактными требованиями пусть ваша команда безопасности проведёт проверку до развёртывания в production, а не после.
Когда актуален BYOC (принеси свой облачный аккаунт) или развёртывание в VPC?
Требования к местонахождению данных, политики сетевой безопасности или нормативные ограничения, запрещающие передачу данных за пределы определённого облачного аккаунта, являются основными причинами, по которым команды выбирают BYOC или развёртывание в VPC вместо общего управляемого сервиса. Запуск песочниц в вашем собственном VPC AWS или GCP означает, что среда выполнения находится в пределах вашего сетевого периметра, применяются средства контроля доступа вашего облачного аккаунта, а исходящие соединения из песочницы могут управляться существующими сетевыми политиками. Компромисс — операционная ответственность: вы управляете инфраструктурой, патчами и масштабированием. Novita Agent Sandbox документирует развёртывание BYOC в аккаунтах AWS или GCP как функцию для команд с такими требованиями. Проверьте текущую доступность и параметры конфигурации в документации Novita Agent Sandbox.
Ценообразование песочниц и факторы затрат
Что влияет на стоимость песочниц?
Стоимость песочниц обычно складывается из времени вычислений (vCPU и память, оплачиваемые посекундно или поминутно), накладных расходов на сессию (плата за запуск сессии на некоторых платформах), постоянного хранилища сверх включённого бесплатного лимита и исходящей передачи данных (исходящий трафик). Относительный вес каждого фактора зависит от вашей рабочей нагрузки: интерпретатор кода с короткими сессиями — это в основном вычисления; агент автоматизации браузера, загружающий большие файлы, может генерировать значительный исходящий трафик; постоянное рабочее пространство для программирования будет накапливать хранилище. Обработка времени простоя — важный дифференциатор: платформы с автоматической приостановкой прекращают выставление счетов, когда песочница ожидает ответа LLM, что может значительно снизить затраты для интерактивных рабочих процессов. См. Модели ценообразования песочниц AI-агентов: за сессию, вычисления, хранилище и исходящий трафик для подробного разбора каждой оси ценообразования.
Как взаимодействуют время сессии, вычисления и исходящий трафик в стоимости?
Для большинства рабочих нагрузок доминирует время вычислений. 10-минутная сессия программирования на 1 vCPU стоит больше, чем 1 ГБ исходящего трафика по типичным ставкам. Но взаимодействие имеет значение для конкретных рабочих нагрузок: агент данных, загружающий большой набор данных для обучения, сгенерирует расходы на исходящий трафик, которые затмят стоимость вычислений. Браузерный агент, удерживающий сессии открытыми между вызовами LLM, будет накапливать плату за простоя, если не включена авто-приостановка. Практический подход — оценить каждое измерение по вашему фактическому профилю рабочей нагрузки, прежде чем выбирать платформу. Novita Agent Sandbox выставляет счёт посекундно на основе фактического использования vCPU и памяти без платы за запуск сессии; по состоянию на середину 2026 года 1 vCPU стоит $0,0000098/с. (Источник: страница цен Novita AI, проверено в опубликованной документации. Всегда проверяйте текущие ставки перед планированием бюджета.)
Самостоятельный хостинг против управляемой песочницы AI-агента
Когда командам следует использовать самостоятельный хостинг, а не управляемую песочницу?
Самостоятельный хостинг (запуск собственной инфраструктуры песочниц, часто на Firecracker или сопоставимом уровне микро-ВМ) имеет смысл, когда: требования к местонахождению данных или сетевой политике запрещают использование стороннего управляемого сервиса, объём рабочей нагрузки достаточно высок, чтобы стоимость управляемого сервиса превышала операционные расходы на эксплуатацию собственной инфраструктуры, или команда имеет существующие возможности платформенной инженерии и хочет полного контроля над моделью изоляции, управлением образами и сетевой политикой. Самостоятельный хостинг сложнее, чем кажется: управление ядрами, корневыми файловыми системами, образами, снапшотами, ограничителями скорости, метриками, очисткой и мультитенантной изоляцией — это реальная работа. См. Firecracker для песочниц AI-агентов для описания объёма операционной работы.
Когда управляемая песочница имеет больше смысла?
Для большинства команд, создающих агентов-программистов, инструменты анализа данных, рабочие процессы автоматизации браузера или конвейеры оценки, управляемая песочница — более быстрый путь к production. Платформа берёт на себя предоставление инфраструктуры, укрепление безопасности, обновление образов, масштабирование и управление жизненным циклом. Команда сосредотачивается на архитектуре агента, а не на внутренностях песочницы. Сравнение стоимости — это не только тарифы облачных вычислений: учтите инженерное время на создание и поддержку уровня изоляции, работу по документированию соответствия требованиям и реагирование на инциденты, когда происходит что-то неожиданное. Для команд без выделенных возможностей платформенной инженерии управляемые сервисы обычно быстрее достигают production и имеют более низкую совокупную стоимость владения. См. Модели ценообразования песочниц AI-агентов для структуры сравнения общей стоимости управляемого и самостоятельного хостинга.
Какие вопросы следует задавать командам при оценке поставщиков управляемых песочниц?
Практические вопросы для оценки помимо заголовочных цен:
- Какова модель изоляции на сессию (микро-ВМ, контейнер, процесс)?
- Какова политика исходящих соединений по умолчанию и настраиваемая?
- Какие существуют опции управления установкой пакетов?
- Как внедряются и очищаются секреты?
- Какие данные журналов аудита доступны и как к ним получить доступ?
- Каковы ограничения по длине сессии и параллелизму на вашем требуемом уровне?
- Поддерживает ли поставщик BYOC или развёртывание в VPC?
- Каково поведение приостановки/возобновления и как оно влияет на выставление счетов?
- Как ведёт себя задержка запуска при масштабировании (тёплый пул, снапшот, холодный старт)?
