Требования к песочницам для AI-сгенерированного кода в продакшн-приложениях

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

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

Изоляция песочницы: процесс, контейнер и MicroVM

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

Изоляция на уровне процессов использует примитивы ОС — пространства имён, cgroups, seccomp и профили AppArmor или SELinux — чтобы ограничить доступ процесса. Это быстро и не требует отдельного ядра ВМ, но все процессы разделяют ядро хоста. Уязвимость ядра или привилегированный системный вызов, прошедший через фильтр seccomp, может повлиять на другие рабочие нагрузки на том же хосте. Процессная изоляция — разумная отправная точка для низкорисковых, короткоживущих, доверенных путей кода, но это тонкая граница для недоверенного AI-сгенерированного кода, который может пытаться выполнять системные вызовы, порождать подпроцессы или устанавливать пакеты.

Что нужно проверить на этом уровне:

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

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

Что нужно проверить на этом уровне:

• Минимален ли образ контейнера, содержит ли он только те среды выполнения и инструменты, которые действительно нужны рабочей нагрузке?
• Сведены ли возможности до минимально необходимого набора?
• Является ли контейнер rootless, или требуется root, и какой контроль существует вокруг этого?
• Явно ли исключены пространство имён PID хоста, сеть хоста и Docker-сокет?
• Ограничены ли смонтированные тома явно определёнными путями, и является ли корневая файловая система по возможности только для чтения?

Изоляция MicroVM помещает каждую рабочую нагрузку внутри лёгкой виртуальной машины — с собственным гостевым ядром, виртуальными устройствами и границей на основе KVM между гостем и хостом. Такие технологии, как Firecracker, используют минимальную модель устройств для уменьшения поверхности атаки, сохраняя при этом время запуска, достаточное для интерактивного использования. Граница MicroVM означает, что эксплойт ядра в гостевой системе не влияет автоматически на хост или других гостей.

Что нужно проверить на этом уровне:

• Получает ли каждый запуск агента, каждый арендатор или каждая конкурентная сессия отдельную MicroVM?
• Какова задержка запуска от вызова API до готовности к выполнению, и измеряется ли она от тёплого пула, снимка или холодного старта?
• Версионируются ли гостевые образы, проверяются ли на предмет включённых сред выполнения и инструментов, и обновляются ли по регулярному графику?
• Что происходит на уровне хоста, если гостевое ядро паникует или становится недоступным?

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

Управление конкурентными сессиями песочницы

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

Ключевые вопросы:

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

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

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

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

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

API жизненного цикла: Создание, Выполнение, Завершение

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

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

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

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

Завершение: Остановка выполняющегося кода до его завершения. Песочница должна гарантировать, что дерево процессов очищено, а не только родительский процесс.

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

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

Дополнительные возможности, которые стоит проверить для продакшн-использования:

• Пауза и возобновление: Можно ли приостановить долгоживущую сессию и возобновить её позже без потери состояния? Это полезно для ограничения скорости, контроля затрат и передачи сессии между шагами агента.
• Снимок: Можно ли захватить текущее состояние сессии и использовать его как отправную точку для будущих сессий? Это ключевой механизм для тёплых пулов и повторно используемых сред.
• Принудительный тайм-аут: Если выполняемый код превышает тайм-аут по настенному времени, завершает ли платформа его корректно и сообщает ли правильный статус выхода?

Наблюдаемость: Журналы, Метрики и Трассировки

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

Захват stdout и stderr: Каждое выполнение должно создавать запись захваченного вывода, связанную с ID сессии и ID выполнения. Это должно быть доступно через API после завершения выполнения, а не только в виде потока в реальном времени.

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

Метрики ресурсов: Продакшн-приложениям нужны метрики на сессию для использования CPU, пика памяти, времени по настенным часам и записи в файловую систему. Это позволяет планировать ёмкость, обнаруживать аномалии и распределять затраты на сессию.

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

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

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

Ограничения CPU, Памяти и Тайм-аута

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

Продакшн-песочница должна применять ограничения на уровне сессии, а не только на уровне хоста:

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

Память: Установите лимит памяти, который вызывает очистку или завершение, а не позволяет сессии исчерпать память хоста. Проверьте, что происходит при достижении лимита: OOM kill, структурированный ответ об ошибке или молчаливое зависание.

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

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

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

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

Политики установки пакетов

AI-сгенерированный код часто запрашивает установку пакетов — pip install, npm install, apt-get, клонирование Git, прямые загрузки по URL. Каждая из этих операций загружает внешний код в песочницу во время выполнения, что является одной из самых рискованных операций, которые песочница должна регулировать.

Продакшн-политика для пакетов должна охватывать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Логирование исходящих соединений: Даже когда исходящий трафик разрешён, логирование того, какие домены и IP-адреса контактировала сессия, полезно для расследования инцидентов. Не все платформы песочниц предоставляют это нативно; проверьте, что вы получите.

Секреты и инъекция учётных данных

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

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

Краткосрочные учётные данные: Если бэкенд поддерживает это, предпочитайте краткосрочные токены с TTL, ограниченным длительностью сессии. Это ограничивает окно, в течение которого утекшие учётные данные полезны.

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

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

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

Эфемерное и постоянное файловое хранилище

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

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

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

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

Экспорт артефактов вывода: После выполнения, что может покинуть песочницу? Продакшн-политика должна определять, какие пути файлов доступны для экспорта, какие лимиты размера применяются и проверяются ли артефакты или фильтруются перед тем, как приложение их получит.

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

Интеграция с бэкендом: REST, WebSocket, SDK

Песочница полезна только в том случае, если она чисто интегрируется в бэкенд приложения. Три основных паттерна интеграции: REST, WebSocket и SDK.

REST: REST API — это интеграция с наименьшим сопротивлением для приложений, которые отправляют дискретные запросы на выполнение и опрашивают результаты. Он хорошо работает для короткоживущих задач, легко отлаживается стандартными HTTP-инструментами и естественно вписывается в существующие сервисные архитектуры. Компромисс в том, что опрос результатов добавляет задержку по сравнению с push-уведомлениями, а потоковая передача долго выполняющегося вывода требует либо SSE, либо опроса конечной точки журнала.

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

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

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

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

Восстановление после сбоев и очистка

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

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

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

Гарантии очистки: Вызов API cleanup или terminate должен надёжно освобождать все ресурсы: выделения CPU и памяти, дисковую квоту, слоты процессов, сетевое состояние и учётные данные. Очистка должна быть идемпотентной — многократный вызов для одного и того же ID сессии не должен возвращать ошибку. Это важно на практике: код приложения, который повторяет очистку после сетевой ошибки, не должен ломаться.

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

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

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

Novita Agent Sandbox

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

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

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

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

FAQ

Какую модель изоляции выбрать для AI-сгенерированного кода?

Изоляция MicroVM даёт самую сильную границу для недоверенного AI-сгенерированного кода, но добавляет операционную сложность. Контейнерная изоляция подходит для низкорисковых рабочих нагрузок, если контейнер правильно закалён — без привилегированного режима, минимальные возможности, корневая файловая система только для чтения, где это возможно, и без монтирования сокетов хоста. Процессная изоляция сама по себе слишком тонкая граница для недоверенного кода, который может пытаться выполнять системные вызовы, порождать подпроцессы или устанавливать пакеты. Соотносите уровень изоляции с вашей фактической моделью угроз.

Как обрабатывать установку пакетов в продакшн-песочнице?

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

Что должен предоставлять API жизненного цикла как минимум?

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

Как предотвратить утечку секретов через песочницу?

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

---

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

• Firecracker для песочниц AI-агентов: преимущества, ограничения и вопросы для оценки
• MCP-серверы в изолированных песочницах: компромиссы файловой системы, секретов и сети
• Создайте AI-аналитика данных с изолированным Python и контролируемым доступом к пакетам