Когда ИИ-агент редактирует проект, запускает команды или обращается к внешним сервисам, он получает технические возможности, которые могут быть шире конкретной задачи. Ошибочная команда, уязвимый плагин или вредоносная инструкция в репозитории способны привести к чтению посторонних файлов или изменению конфигурации. 7 октября 2026 года Microsoft объявила о доступности Microsoft Execution Containers (MXC) для общего использования на Windows 11 — слоя исполнения, который позволяет задать и принудительно ограничивать доступ агента к ресурсам.
Для поискового намерения здесь важны формулировки «Microsoft Execution Containers», «песочница для ИИ-агента», «безопасный запуск coding agent» и «ограничить доступ ИИ-агента к файлам и сети». Это тематический кластер запросов с близким практическим намерением; численные сравнения Wordstat или Google Trends в открытых данных для этой темы не подтверждены, поэтому частотность не указываем.
Microsoft Windows Developer Blog: Microsoft Execution Containers, 7 октября 2026 года
Официальный репозиторий MXC: SDK, политики и поддерживаемые механизмы изоляции
9to5Windows: сообщение о доступности MXC для общего использования, 8 октября 2026 года
Что такое MXC и какую задачу он решает
MXC — это исполняемый слой с политиками доступа, который приложение может использовать для запуска недоверенного кода, инструментов или самого агента. Разработчик описывает ресурсы, необходимые для работы, например каталог проекта, команды сборки и список сетевых направлений. Затем MXC запускает рабочую нагрузку через подходящий механизм изоляции. Политика находится за пределами контроля модели: агент не должен суметь расширить её одной лишь командой или сгенерированным кодом.
Представим coding agent, которому нужно поправить сайт. Ему можно разрешить читать и изменять репозиторий, запускать Git и тесты, а конфигурацию production-сервера оставить только для чтения. Личные документы, домашние каталоги и произвольные сетевые адреса не нужны этой задаче. Если агент попытается выйти за границы, ограничение срабатывает на уровне среды исполнения, а не по просьбе к модели «будь осторожной».
Важное отличие: MXC — не отдельная языковая модель и не гарантия правильного поведения агента. Он ограничивает то, до чего рабочая нагрузка может дотянуться через контролируемые системные ресурсы. Корректность действий внутри выданных полномочий, безопасность приложения, учётные записи, секреты и данные всё ещё требуют проектирования и проверки.
Уровни изоляции: от процесса до виртуальной машины
Microsoft описывает несколько вариантов для разных задач. В Windows 11 доступны контейнер процесса, отдельная пользовательская сессия и среда WSL; MicroVM обозначена как экспериментальная. На macOS и Linux заявлена поддержка контейнера процесса через предусмотренные в этих ОС механизмы изоляции. Конкретные возможности зависят от ОС и backend, поэтому общая схема политики не означает одинаковую степень изоляции на каждой платформе.
- Контейнер процесса подходит для быстрых коротких операций: запуска сгенерированного кода, тестов или инструментов агента. В Windows используется AppContainer, на macOS — Seatbelt, на Linux — Bubblewrap.
- Контейнер сессии для Windows 11 запускает длительную или интерактивную работу в отдельной системной сессии. Она отделена от пользовательского рабочего стола, буфера обмена и ввода.
- WSL-контейнер помогает запускать Linux-инструменты и цепочки сборки на Windows 11 в знакомом для разработчика окружении.
- MicroVM предназначена для более рискованных нагрузок, где требуется аппаратно поддерживаемая виртуализация; в анонсе Microsoft этот вариант назван экспериментальным.
Выбор стоит делать по модели угроз и рабочему сценарию. Небольшой линтер в репозитории и агент, который запускает сторонний код с доступом к клиентским данным, не обязаны работать в одинаковой среде. Более сильная изоляция может добавить время запуска, требования к ресурсам и сложности интеграции; это нужно измерить на своей задаче.
Файлы, сеть и интерфейс задаются отдельно
Политика может определить, какие каталоги разрешено читать, куда можно записывать, какие ресурсы запрещены, доступна ли входящая или исходящая сеть и может ли нагрузка взаимодействовать с графическим интерфейсом. На практике это позволяет дать агенту право менять исходный код, читать документацию, но запретить доступ к личной папке пользователя и закрыть соединения, не нужные тесту.
В MXC описаны три режима работы с правилами. Enforcement блокирует всё, на что нет разрешения, и предназначен для запуска с подготовленной политикой. Learning также блокирует неразрешённый доступ, но записывает попытки в отчёт, помогая разработчику понять, каких ресурсов не хватает. Permissive разрешает такие действия, но регистрирует их, чтобы наблюдать за нагрузкой при настройке. Это режим сбора сведений о поведении, а не подтверждение того, что политика уже защищает систему.
Начинать полезно с Learning: прогнать повторяемый набор сценариев и посмотреть, какие пути, команды и домены агент реально запрашивает. Затем проверить каждую потребность вручную, убрать случайные и широкие разрешения и перевести пилот в Enforcement. Не включайте permissive для недоверенного агента на компьютере с реальными корпоративными данными только ради удобной диагностики.
Как внедрить песочницу в продукт или внутренний процесс
- Опишите задачу и активы. Зафиксируйте, какую папку агент меняет, что он читает, какие команды запускает, к каким адресам подключается и какие данные особенно чувствительны.
- Выдайте минимальный набор прав. Разведите чтение и запись, production и тестовый контур, внутреннюю сеть и публичный интернет. Если задаче нужен один API, не открывайте агенту произвольное сетевое подключение.
- Соберите тестовые случаи. Помимо нормального сценария включите просьбу открыть соседний каталог, изменить запрещённый файл, вызвать незнакомую команду, подключиться к другому хосту и продолжить после отказа в доступе.
- Проверьте поведение при ограничении. Если политика блокирует нужный ресурс, агент должен объяснить, какой шаг остановлен, предложить безопасный вариант или запросить подходящее подтверждение. Он не должен тихо пропустить часть задачи и выдать неполный результат за готовый.
- Измерьте цену контроля. Сравните время запуска и выполнения, долю успешных задач, число заблокированных действий, ручные перенастройки и время разбора отчёта. Пилот полезен, если команда понимает не только что заблокировалось, но и зачем агент вообще просил этот доступ.
Для собственного приложения интеграция MXC не отменяет серверную авторизацию и проверку бизнес-правил. Системная песочница ограничивает локальное исполнение, а API всё равно должен проверять пользователя, объект и разрешённую операцию. Не передавайте секреты в переменные окружения без оценки того, какие процессы могут их прочитать, и не пишите токены в диагностические журналы.
Что уже доступно, а что ещё в планах
Microsoft указывает MXC как доступный для общего использования на Windows 11 и сообщает об общем доступе поддержки Windows 365. Поддерживаемые возможности различаются между платформами и backend. Управление контейнерами процесса через политики Intune, а также идентификация действий агента через Microsoft Entra и Agent 365 в анонсе отнесены к будущим возможностям. Не стоит считать их уже подключёнными к любой конфигурации только потому, что базовый MXC получил статус GA.
В анонсе Microsoft перечисляет уже интегрированные решения, включая GitHub Copilot, OpenClaw, OpenAI Codex, Replit и LM Studio, а поддержку ряда других продуктов называет предстоящей. Перед пилотом проверьте фактическую поддержку нужного агента, версию SDK, конфигурацию ОС и требуемый режим изоляции. Статус общей доступности самого слоя не означает, что каждый агент автоматически запускается в нём.
Ограничения, которые важно учесть
Изоляция сужает последствия ошибок, но не делает рабочую нагрузку безвредной. Если вы разрешили запись во весь репозиторий, агент всё ещё может удалить важный файл проекта. Если разрешили сеть к нужному API, он может отправить туда неверные данные. Скомпрометированная библиотека может повлиять на файлы в выданной области. Поэтому используйте резервные копии и контроль изменений, подтверждение рискованных действий, аудит, ограничение секретов и отдельные среды.
Песочницу нужно проверять как часть продукта: воспроизводить запрещённые действия, анализировать обновления backend и пересматривать правила после изменения инструментов или сценариев агента. Режим, который подходит локальной генерации кода, не обязательно подойдёт автоматизации с графическим интерфейсом или обработке чувствительных документов.
Частые вопросы
Что означает GA для Microsoft Execution Containers?
Microsoft объявила общую доступность MXC на Windows 11 7 октября 2026 года. Отдельные механизмы, сценарии, интеграции и корпоративные функции могут иметь собственные условия и стадии доступности.
MXC работает только на Windows?
Microsoft заявляет поддержку контейнера процесса на Windows, macOS и Linux. Контейнеры сессии и WSL относятся к Windows 11; MicroVM указана как экспериментальная для Windows 11 и Linux.
Достаточно ли песочницы, чтобы защитить корпоративные данные?
Нет. MXC ограничивает доступ рабочей нагрузки к заданным ресурсам. Авторизация API, защита секретов, бизнес-проверки, аудит, резервное копирование и работа с чувствительными данными остаются отдельными задачами.
С какого режима начать?
Для изучения запросов ресурсов подходит Learning: неразрешённые обращения блокируются и попадают в отчёт. После проверки и настройки минимальных прав используйте Enforcement для запуска с утверждённой политикой.
Подойдёт ли MXC для проверки идеи AI-приложения?
Да, если заранее ограничить тестовую область и определить критерии качества. Начните с искусственных данных, небольшого набора задач и проверки отказов; затем сравните результат и операционные затраты с обычным API или отдельной серверной средой.
TigerNova / Практические материалы о цифровых продуктах