Запуск Claude Code или управляемых агентов в изолированной песочнице

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

Что необходимо изолировать

Агент кодирования — это не просто чат-бот, прикрепленный к репозиторию. Когда он может редактировать файлы и выполнять команды, он начинает напоминать младшего сборщика проектов с рассуждениями на основе языковой модели. Такой работник может запустить npm test, проверить сгенерированные файлы, запустить dev-сервер или попробовать установить пакет, потому что об этом сообщает сообщение об ошибке. Если рабочее пространство — ваш ноутбук, общий CI-раннер или долгоживущая VM, похожая на продакшн, радиус поражения слишком велик.

Цель изоляции — весь цикл работы агента:

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

Claude Code и другие управляемые продукты для агентов кодирования могут включать собственные системы разрешений. Документация Anthropic по Claude Code, например, описывает настройки разрешений для разрешенных и запрещенных инструментов, поведение при одобрении и рекомендации по изоляции для локального использования. Рассматривайте эти средства управления как один слой, а не всю границу. Более надежная конструкция также помещает агента в изолированную среду выполнения, а затем применяет разрешения инструментов внутри этой среды.

Эталонная архитектура

Практический рабочий процесс изолированного агента состоит из четырех уровней:

Уровень	Назначение	Типичный контроль
Контроллер агента	Определяет план задачи и вызовы инструментов	Разрешения модели/инструментов, режим одобрения, промпт задачи
Среда выполнения песочницы	Хостит рабочее пространство, где выполняются команды	Изолированная файловая система, ограничения процессов, управление жизненным циклом
Политический шлюз	Определяет, какие действия разрешены	Правила команд, правила сетевого исходящего трафика, политика пакетов, область секретов
Поверхность проверки	Позволяет людям проверять результаты	Различия, журналы, результаты тестов, артефакты, запросы на слияние

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

Концептуальный объект политики может выглядеть так:

workspace:
  mode: ephemeral
  repo_ref: pull-request-branch
  writable_paths:
    - /workspace/project
  readonly_paths:
    - /workspace/reference
commands:
  auto_allow:
    - git status
    - npm test
    - npm run lint
    - pytest
  require_approval:
    - npm install
    - pip install
    - docker build
    - git push
  deny:
    - rm -rf /
    - curl ... | sh
network:
  default: deny
  allow:
    - registry.npmjs.org
    - pypi.org
    - files.pythonhosted.org
secrets:
  expose:
    - READ_ONLY_PACKAGE_TOKEN
  deny:
    - PRODUCTION_DATABASE_URL
    - CLOUD_ADMIN_TOKEN
artifacts:
  capture:
    - git diff
    - test-results/
    - screenshots/
    - command-log.jsonl

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

Настройка рабочего пространства и репозитория

Начинайте каждый запуск агента с чистого рабочего пространства. Управляемый агент не должен наследовать историю команд разработчика, SSH-агент, dotfiles, облачный CLI-логин или неотслеживаемые локальные файлы, если для этого нет намеренной причины.

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

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

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

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

Разрешения файловой системы

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

• Доступа на чтение/запись к рабочему пространству репозитория.
• Доступа только для чтения к выбранному контексту задачи, фикстурам или документации.
• Временного каталога для выводов сборки и временных файлов.
• Отсутствия доступа к домашним каталогам хоста, несвязанным репозиториям, облачным учетным данным, профилям браузера или дампам производственных данных.

Разрешения на запись требуют особого внимания. Агент кодирования, который может редактировать репозиторий, также может редактировать скрипты, тесты, lock-файлы, конфигурацию CI и файлы развертывания. Это может быть именно то, что требуется для задачи, но это должно быть видно при проверке. Для чувствительных путей, таких как .github/workflows/, манифесты развертывания или конфигурация публикации пакетов, требуется либо более строгий шаг одобрения, либо окончательная проверка человеком.

Используйте белые списки файлов, когда задача узкая. Например, агенту документации может понадобиться только docs/ и каталог предварительного просмотра. Агенту обновления зависимостей могут понадобиться package.json, lock-файлы и тестовые снимки. Широкому рефакторингу нужен более широкий доступ, но проверка должна тогда ожидать большего различия и более полных тестов.

Политика выполнения команд

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

Хорошая политика оболочки имеет три корзины:

Корзина	Примеры	Почему это важно
Автоматически разрешено	git status, npm test, pytest, go test ./..., npm run lint	Сохраняет нормальные циклы редактирования-тестирования быстрыми
Требуется одобрение	установка пакетов, миграции, долгоживущие сервисы, внешние CLI, git push	Добавляет трение там, где меняются состояние, стоимость или сетевые риски
Запрещено	разрушительные команды хоста, дамп учетных данных, небезопасный конвейер оболочки, запись вне рабочего пространства	Блокирует действия, которые не должны делегироваться

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

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

Установка пакетов и сетевой исходящий трафик

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

Для руководств по реализации и производственных рабочих процессов начинайте с сетевой позиции “запрещено по умолчанию”, затем разрешите то, что нужно для задачи:

• Реестры пакетов, такие как npm или PyPI, предпочтительно через зеркало реестра или кеш.
• Исходные хосты, необходимые для репозитория и подмодулей.
• Домены документации, необходимые для задачи.
• Внутренние API только тогда, когда песочница имеет правильную классификацию данных.

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

Для установки пакетов записывайте:

• Команду менеджера пакетов.
• Хост реестра.
• Изменения lock-файла.
• Имена и версии загруженных пакетов, если доступно.
• Любые скрипты установки, которые выполнялись.
• Была ли установка одобрена человеком.

Это не делает произвольные пакеты безопасными. Это делает изменение проверяемым.

Границы секретов

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

Используйте следующие значения по умолчанию:

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

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

Журналы, артефакты и аудиторские следы

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

Записывайте как минимум:

• Промпт задачи или сводку инструкций.
• Базовый коммит и ветку.
• Прочитанные и записанные файлы, когда ваши инструменты могут это зафиксировать.
• Выполненные команды с временными метками, рабочей директорией, статусом выхода, stdout и stderr.
• Сводки по установке пакетов и сетевому доступу.
• Результаты тестов и сборки.
• Сгенерированные файлы, скриншоты, отчеты или ссылки на предварительный просмотр.
• Финальное различие.

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

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

Очистка и сброс

Очистка песочницы — это контроль безопасности и затрат, а не просто уборка. В конце запуска:

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

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

Как Novita Agent Sandbox вписывается в картину

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

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

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

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

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

Вопрос	На что обратить внимание
Какова граница изоляции?	Выделенное рабочее пространство, ограничения процессов, разделение файловой системы и четкая документация провайдера
Что агент может читать?	Доступ только к репозиторию по умолчанию, без домашнего каталога хоста, без несвязанных репозиториев
Что агент может писать?	Пути к исходному коду, доступные для записи, явно указаны; чувствительные пути к конфигурации требуют дополнительной проверки
Какие команды выполняются автоматически?	Команды тестирования и форматирования разрешены; команды, изменяющие состояние, требуют одобрения
Какой сетевой доступ существует?	Запрет по умолчанию или ограниченный исходящий трафик; реестры пакетов и домены документации намеренно разрешены
Как обрабатываются установки пакетов?	Изменения lock-файлов, хосты реестров и скрипты установки регистрируются
Какие секреты присутствуют?	Только учетные данные, ограниченные задачей, недолговечные, с минимальными привилегиями
Что происходит с журналами?	Команды, выводы, различия и артефакты переживают очистку песочницы
Как обеспечивается очистка?	Фоновые процессы, порты, токены и временные файлы закрываются или отзываются
Кто утверждает объединение или развертывание?	Человек-рецензент проверяет код, тесты, файлы, чувствительные к безопасности, и сгенерированные артефакты

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

FAQ

Можно ли запустить Claude Code в песочнице?

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

Достаточно ли контейнера для изоляции агента кодирования?

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

Следует ли разрешать агентам устанавливать пакеты?

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

Что должен проверить человек-рецензент перед объединением?

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

Встроена ли Novita Agent Sandbox официально в Claude Code?

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

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

• Building a Coding Agent with Novita’s Agent Sandbox
• Run Harbor Agent Evaluations on Novita Agent Sandbox
• How to Use Codex with Novita AI Models