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-серверов, которые могут изменять внешнее состояние, касаться конфиденциальных данных или выполнять код. Именно эти серверы с наибольшей вероятностью превратят обычную ошибку в промпте в более серьёзный инцидент.

Высокоприоритетные кандидаты для изоляции:

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

Менее рискованные MCP-серверы всё равно могут требовать контроля. Поисковый сервер по общедоступной документации только для чтения, возможно, не нуждается в микро-ВМ на каждый запрос, но он всё равно должен иметь разрешённый сетевой путь, логи и лимиты скорости. Изоляция должна следовать практическому радиусу поражения инструмента, а не ярлыку “MCP-сервер”.

Где должен запускаться MCP-сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошая обработка секретов для MCP-серверов выглядит так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Логирование, очистка и проверка человеком

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

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

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

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

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

Как подходит Novita Agent Sandbox

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

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

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

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

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

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

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

Контрольный список внедрения

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

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

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

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

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

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

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

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

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

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

Где следует хранить секреты для MCP-инструментов в песочнице?

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

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

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

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

• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation