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

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

Что должна изолировать песочница кодирующего агента

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

Проектируйте песочницу вокруг ресурсов, к которым может обращаться кодирующий агент:

Поверхность	Что контролировать	Почему это важно
Клонирование репозитория	Ветка, коммит SHA, область записи, подмодули, сгенерированные файлы	Предотвращает изменение агентом не той кодовой базы или сокрытие изменений вне пути проверки.
Файловая система	Корень рабочего пространства, смонтированные файлы, игнорируемые пути, выходные каталоги	Предотвращает широкий доступ к файлам хоста, учётным данным, кэшам и несвязанным проектам.
Выполнение команд оболочки	Разрешённые команды, рабочий каталог, тайм-аут, захват вывода, ворота одобрения	Даёт агенту достаточно мощности для сборки и тестирования, ограничивая высокорисковые действия.
Установка пакетов	Политика реестра, lock-файлы, фиксированные версии, стратегия кэширования, логи установки	Уменьшает неопределённость в цепочке поставок, когда агент запрашивает новые зависимости.
Сетевой доступ	Исходящий трафик по умолчанию, белые списки, поведение DNS, адресаты API, зеркала пакетов	Помогает предотвратить непреднамеренную передачу данных и делает внешние вызовы проверяемыми.
Секреты	Ограниченные учётные данные, короткоживущие токены, редактирование, отсутствие ключей продакшна по умолчанию	Не даёт агенту читать или раскрывать ненужные ему учётные данные.
Артефакты	Отчёты о тестах, результаты сборки, скриншоты, сгенерированные файлы, логи	Предоставляет проверяющим доказательства, не полагаясь только на сводку агента.
Жизненный цикл	Пауза, возобновление, снимок, сброс, очистка, политика хранения	Делает запуски агента повторяемыми и одноразовыми, а не долгоживущими загадочными машинами.

Используйте эту таблицу как контрольный список проектирования. Она применима независимо от того, построена ли ваша песочница на контейнерах, виртуальных машинах, microVM, управляемых облачных песочницах или внутреннем раннере. Точный уровень изоляции важен, но операционные контроли вокруг этого уровня тоже важны.

Эталонный рабочий процесс для запуска кода, сгенерированного агентом

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

1. Создайте новое рабочее пространство для задачи.
2. Клонируйте целевой репозиторий на конкретную ветку или коммит.
3. Дайте агенту узкую задачу, команду тестирования и область файлов.
4. Позвольте агенту просмотреть файлы и предложить план.
5. Автоматически выполняйте низкорисковые команды только для чтения.
6. Требуйте одобрения или проверки политики для рискованных команд.
7. Захватывайте каждую команду, код выхода, stdout, stderr, запись файла и сгенерированный артефакт.
8. Запускайте тесты, проверки типов, линтеры, сборки или целевые скрипты внутри песочницы.
9. Экспортируйте патч, дифф, результаты тестов и набор артефактов.
10. Сбрасывайте или уничтожайте рабочее пространство после проверки, если только снимок не был намеренно сохранён.

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

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

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

Такое разделение не позволяет модели быть одновременно и планировщиком, и конечной инстанцией для опасных операций.

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

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

Перед выполнением в оболочке определите классы команд:

Класс команды	Примеры	Политика по умолчанию
Проверка только для чтения	pwd, ls, git status, rg, cat package.json	Обычно разрешить и логировать.
Локальная верификация	npm test, pytest, go test, cargo test	Разрешить с тайм-аутом и захватом вывода.
Сборка или генерация	npm run build, кодогенерация, генерация документации	Разрешить, когда ожидаются выходные пути.
Изменение зависимостей	установка менеджером пакетов, обновление lock-файла	Требовать проверки политики или одобрения.
Сетевые команды	получение URL, вызов API, клонирование дополнительных репозиториев	Требовать политику назначения и логирование.
Разрушительные команды	удаление, принудительный сброс, очистка диска, широкий chmod/chown	Блокировать или требовать явного одобрения человека.
Доступ к секретам	чтение env-файлов, хранилищ учётных данных, конфигов развёртывания	Блокировать, если только задача не требует и не ограничена.

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

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

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

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

Используйте более строгую политику для работы с пакетами:

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

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

Как минимум, определите поведение по умолчанию:

Вопрос сети	Более безопасное значение по умолчанию
Может ли песочница выходить в интернет?	Нет, если только задача не требует этого.
Может ли она разрешать произвольные DNS-имена?	Ограничьте или логируйте DNS и хосты назначения.
Может ли она вызывать API продакшна?	По умолчанию используйте staging-эндпоинты или mock-сервисы.
Может ли она загружать зависимости пакетов?	Используйте одобренные реестры, зеркала и lock-файлы.
Может ли она загружать файлы или логи?	Блокируйте, если только назначение не ожидаемо и не проверено.

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

Диффы, артефакты и логи для проверки человеком

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

Для каждого запуска захватывайте:

• URL репозитория, ветку и коммит SHA, использованные для клонирования.
• Текст задачи или сводку issue.
• Прочитанные и записанные файлы.
• Каждую команду, рабочий каталог, время начала, время окончания, код выхода, stdout и stderr.
• Команды установки зависимостей и изменения lock-файла.
• Результаты тестов, линтера, проверки типов и сборки.
• Сгенерированные артефакты, такие как скриншоты, отчёты, покрытие, бинарники или превью URL.
• Итоговый дифф в стандартном формате патча или pull request.

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

Для производственных команд сделайте ворота проверки явными:

• Агент может предложить патч.
• Песочница может запустить верификацию.
• Система может открыть pull request.
• Человек или одобренная политика должны решить, сливать, развёртывать или предоставлять более широкие разрешения.

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

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

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

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

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

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

Разработчики, желающие получить практический пример, также могут прочитать руководство Novita по созданию MCP-сервера для удалённого выполнения кода с помощью Novita Sandbox. Для документации продукта начните с документации Novita Agent Sandbox и руководства по установке SDK и CLI.

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

Достаточно ли песочницы кодирующего агента, чтобы сделать сгенерированный код безопасным?

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

Должны ли кодирующие агенты иметь доступ в интернет?

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

Должны ли агенты получать производственные секреты?

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

Что следует проверить, прежде чем доверять патчу агента?

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

Когда следует сбрасывать песочницу?

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

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

• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• Novita Agent Runtime: AgentCore-Compatible AI Agent Infrastructure