MCP Server Sandbox: изолированные MCP-серверы с контролем файловой системы, секретов и сети

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

Почему MCP меняет границу доверия агента

Протокол контекста модели (Model Context Protocol) предоставляет AI-приложениям общий способ подключения моделей к инструментам, подсказкам и ресурсам. Это упрощает интеграцию, но также превращает каждый MCP-сервер в границу политики. Если сервер предоставляет read_file, run_command, query_database или deploy_preview, агент может запрашивать действия, выходящие за пределы окна контекста модели.

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

Рассмотрите границу доверия на трёх уровнях:

Уровень	Что контролирует	Типичный сбой
Хост или MCP-клиент	Какие серверы подключены и какие вызовы инструментов одобрены	Широкий инструмент одобряется один раз и повторно используется в более чувствительном контексте
MCP-сервер	Реализация инструмента, аутентификация, валидация ввода, доступ к ресурсам	Инструмент читает больше файлов, отправляет больше данных или выполняет больше команд, чем ожидалось
Среда выполнения песочницы	Файловая система, процессы, сеть, секреты, жизненный цикл и журналы	Процесс сервера наследует доступ хоста, так как работает слишком близко к производственным ресурсам

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

Что изолировать в первую очередь

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

Кандидаты с высоким приоритетом для изоляции включают:

• Инструменты выполнения кода, запускающие команды оболочки, Python, Node.js, компиляторы, тесты или блокноты.
• Инструменты файловой системы, читающие или записывающие репозиторий, загрузки пользователя, смонтированный набор данных, файл учётных данных или сгенерированный артефакт.
• Инструменты для браузера и использования компьютера, хранящие куки, состояние сессии, загруженные файлы или скриншоты.
• Коннекторы данных, которые могут запрашивать записи клиентов, экспорт аналитики, тикеты или частные документы.
• Инструменты развёртывания и CI, которые могут создавать ветки, публиковать превью, изменять конфигурацию или модифицировать инфраструктуру.
• Инструменты для пакетов и зависимостей, которые могут загружать код из реестров, Git-удалённых репозиториев или произвольных URL.

MCP-серверы с более низким риском всё же заслуживают контроля. Сервер поиска только для чтения в публичной документации может не нуждаться в микро-ВМ на каждый запрос, но у него должен быть белый список сетевых путей, журналы и ограничения скорости. Изоляция должна следовать практическому радиусу поражения инструмента, а не ярлыку «MCP-сервер».

Где должен работать MCP-сервер

Существует три распространённых шаблона размещения. Ни один не является универсально правильным.

Размещение	Используйте, когда	Обратите внимание на
Та же песочница, что и рабочее пространство агента	Сервер тесно связан с текущими файлами агента, командами оболочки, сессией браузера или сгенерированными артефактами	Сервер и агент разделяют состояние, поэтому скомпрометированный инструмент может видеть то же рабочее пространство, если монтирования и секреты не ограничены
Отдельная песочница для каждого MCP-сервера или группы инструментов	Инструменту требуется более сильная изоляция от рабочего пространства агента, он обрабатывает другие учётные данные или выполняет действия с более высоким риском	Передача файлов между песочницами и задержка становятся частью дизайна продукта
Вне песочницы за ограниченным API	Инструмент является стабильным производственным сервисом с собственной аутентификацией, авторизацией, журналированием и ограничениями скорости	API должен быть узким; не раскрывайте широкую внутреннюю административную поверхность только потому, что она находится вне песочницы

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

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

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

Монтирования файловой системы и рабочие пространства для каждого агента

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

Используйте явные границы рабочего пространства:

• Выделите каждому запуску агента собственную рабочую директорию.
• Монтируйте только репозиторий, папку загрузок, набор данных или директорию артефактов, необходимые для задачи.
• Предпочитайте монтирования только для чтения для исходного материала и монтирования для чтения и записи только для выходных данных.
• Отделяйте сгенерированные выходные данные от доверенных исходных файлов.
• Избегайте монтирования папок с учётными данными, таких как .ssh, директорий конфигурации облака, профилей браузера или файлов аутентификации локального менеджера пакетов.
• Сбрасывайте или создавайте снимки рабочего пространства между несвязанными пользователями, арендаторами или заданиями.

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

Практический шаблон — разделить доступ к рабочему пространству по ролям:

Директория	Доступ	Назначение
/workspace/input	Только для чтения	Загрузки пользователя, начальный репозиторий, тестовый набор данных или тестовые данные
/workspace/output	Чтение и запись	Сгенерированные файлы, отчёты, патчи, диаграммы или скриншоты
/workspace/tmp	Чтение и запись, одноразовые	Кэш сборки, кэш установки пакетов, временные файлы
/workspace/secrets	Избегайте монтирования файлов, где это возможно	Если неизбежно, смонтируйте один ограниченный файл секрета со строгим сроком жизни и закрашиванием

Точные пути не имеют значения. Важен принцип.

Секреты и переменные окружения

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

Используйте отдельные учётные данные для разных MCP-серверов. Сервер поиска задач GitHub может нуждаться в доступе к задачам только для чтения. Сервер создания PR может нуждаться в доступе к записи веток. Сервер развёртывания не должен делить ни один из токенов, если только модель разрешений действительно этого не требует.

Надлежащая обработка секретов для MCP-серверов выглядит так:

• Внедряйте секреты при запуске песочницы или процесса, а не через подсказки.
• Используйте токены с коротким сроком действия или с возможностью отзыва, если провайдер это поддерживает.
• Ограничивайте учётные данные по инструменту, арендатору, среде и действию.
• Закрашивайте секреты из stdout, stderr, структурированных ответов инструментов и журналов трассировки.
• Не возвращайте сырые переменные окружения модели.
• Не позволяйте агенту решать, какой секрет загружать.
• Меняйте учётные данные, используемые высокорисковыми серверами, и после подозрения на внедрение подсказок.

Избегайте распространённого антипаттерна: один универсальный файл окружения, смонтированный в каждую сессию агента. Это упрощает локальную разработку и усложняет проверку в production. Если инструменту не нужен секрет, он не должен иметь возможности его прочитать.

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

MCP поддерживает локальные и удалённые паттерны транспорта. Спецификация описывает stdio для локальной межпроцессной коммуникации и Streamable HTTP для связи сервера с клиентом по HTTP. Более старые дизайны на основе SSE всё ещё встречаются в экосистеме, но новые интеграции должны проверять текущую документацию MCP и выбранный SDK, прежде чем полагаться на конкретный транспорт.

Вопрос	Ответ транспорта	Ответ сетевой политики
Как MCP-клиент общается с сервером?	stdio, HTTP-транспорт или другой поддерживаемый паттерн	Не применимо
Какие внешние хосты может вызывать сервер?	Недостаточно сам по себе	Белый список, чёрный список, прокси, DNS-политика или без исходящего трафика
Может ли сервер загружать пакеты или веб-страницы?	Недостаточно сам по себе	Белые списки реестров, белые списки URL, кэширование и журналирование
Может ли другой процесс достичь сервера?	Детали привязки и аутентификации	Входящий брандмауэр и сетевая граница песочницы

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

Для MCP-серверов на основе HTTP риск смещается в сторону аутентификации, сетевой экспозиции и разделения между арендаторами. Используйте серверную авторизацию, TLS, проверки источника (origin checks), где это уместно, и учётные данные для каждого клиента. Не раскрывайте удалённый MCP-сервер в широкой внутренней сети без чёткой политики, кто может вызывать какие инструменты.

Для исходящего сетевого трафика проще рассуждать в парадигме «запрещено по умолчанию», чем «разрешено по умолчанию». Если инструменту нужна установка пакетов, разрешите реестр пакетов или кэш pull-through. Если нужны веб-исследования, направляйте через прокси, который журналирует запрашиваемые домены и блокирует внутренние конечные точки метаданных. Если нужны внутренние API, предоставьте узкий API вместо всей частной сети.

Установка пакетов, подпроцессы и долгоживущее состояние

Многие полезные инструменты MCP нуждаются в подпроцессах. Кодирующие агенты запускают тесты. Агенты данных устанавливают библиотеки. Браузерные агенты запускают браузеры. Агенты сборки вызывают компиляторы. Поддержка подпроцессов не проблема; проблема в невидимой поддержке подпроцессов.

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

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

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

Используйте контроль жизненного цикла:

Контроль	Почему это важно
ID песочницы для каждого агента	Предотвращает переход состояния инструмента одного агента в контекст другого
Таймаут бездействия	Очищает заброшенные сессии инструментов
Политика приостановки и возобновления	Поддерживает длительные задания без поддержания ненужных вычислительных ресурсов активными
Политика снимков или шаблонов	Запускает повторяемые окружения с известной базовой линии
Явное завершение	Удаляет файлы, завершает процессы и освобождает учётные данные после задания

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

Журналирование, очистка и человеческий контроль

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

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

Некоторые действия MCP должны оставаться под человеческим контролем, даже внутри песочницы:

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

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

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

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

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

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

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

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

for each agent task:
  create sandbox from approved template
  mount only the task workspace
  inject only tool-specific secrets
  start the MCP server inside the sandbox or connect to a sandbox-backed tool API
  route tool calls through approval and policy checks
  collect logs and approved artifacts
  stop, reset, or pause the sandbox according to the task lifecycle

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

Чек-лист реализации

Используйте этот чек-лист перед подключением MCP-сервера к автономному или полуавтономному агенту:

Область	Вопросы, на которые нужно ответить
Область инструментов	Какие инструменты предоставляет сервер и какие из них изменяют внешнее состояние?
Размещение	Должен ли сервер работать в песочнице агента, в отдельной песочнице или вне песочницы за узким API?
Файловая система	Какие директории смонтированы, они только для чтения или для чтения и записи, и как блокируются обходы путей?
Секреты	Какие учётные данные внедряются, как они ограничены и где могут появиться в журналах или выводах?
Сеть	Является ли исходящий трафик запрещённым по умолчанию, направленным через прокси или разрешённым по доменам, реестрам и внутренним API?
Подпроцессы	Какие команды, менеджеры пакетов, фоновые задания и слушатели разрешены?
Состояние	Как обрабатываются рабочие пространства для каждого агента, снимки, таймауты бездействия, поведение приостановки/возобновления и очистка?
Журналы	Можете ли вы восстановить вызовы инструментов, изменения файлов, внешние домены и артефакты без хранения секретов?
Человеческий контроль	Какие вызовы инструментов требуют одобрения перед выполнением, экспортом, развёртыванием или действием, обращённым к клиенту?
Тестирование	Тестировали ли вы внедрение подсказок, обходы символьных ссылок/путей, большой вывод, неудачную очистку и запрещённые пути исходящего трафика?

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

ЧаВО

Должен ли каждый MCP-сервер работать в песочнице?

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

Безопаснее ли stdio, чем HTTP, для MCP-серверов?

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

Могут ли корневые пути MCP заменить изоляцию файловой системы?

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

Где должны храниться секреты для изолированных инструментов MCP?

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

Когда инструмент MCP должен требовать человеческого одобрения?

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

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

• Требования к песочнице для AI-сгенерированного кода в производственных приложениях
• Создание MCP-сервера удалённого выполнения кода с помощью Novita Sandbox и библиотеки mcp-use
• Создание кодирующего агента с помощью песочницы Novita Agent Sandbox
• Как песочницы агентов обеспечивают безопасные и масштабируемые AI-инновации