7 октября 2026 года Microsoft объявила о всеобщей доступности Microsoft Execution Containers (MXC). Для команд, запускающих команды, предложенные ИИ-агентом, практический вопрос состоит в том, к каким файлам и сетевым соединениям нужен доступ и какой бэкенд MXC способен обеспечить эти ограничения. В публикации о запуске описана цель изоляции; пользовательская документация репозитория содержит сведения о настройке. Это руководство опирается на эти документы. BIG CHANGE не устанавливала MXC и не запускала изолированную рабочую нагрузку.

Главное изменение

  • Что изменилось: Разработчики могут передать команду и политику её ресурсов через единый интерфейс MXC SDK, который выберет поддерживаемый бэкенд хоста. Выпуск от 7 октября предлагает документированный способ интеграции для инструментов агентов вместо надежды на то, что модель добровольно соблюдёт политику.
  • Почему это важно: Команда может предоставить программной команде доступ к рабочему каталогу, оставив другие расположения файлов и исходящие соединения вне полномочий рабочей нагрузки. Результат зависит от выбранных бэкенда и хоста, поэтому перед тем, как полагаться на ограничение, следует проверить, что именно обеспечивает бэкенд.
  • На что обратить внимание: Режимы настройки политик Microsoft помогают диагностировать заблокированные операции на поддерживаемых хостах Windows ProcessContainer. Следующее практическое решение — действительно ли необходимы предлагаемые разрешения и использует ли производственный запуск режим Enforcement после сужения политики.

Начните с хоста и команды

MXC — библиотека, интегрируемая в приложение, которое запускает рабочую нагрузку. В её README перечислены SDK для Rust, .NET и Node, а также нативные исполняемые файлы для приложений, в которые нельзя встроить SDK. Пакет Node содержит нативные компоненты среды выполнения и требует Node.js 24 или новее; для нативной передачи stdio в Windows репозиторий указывает Node 24.21.0 или новее либо 26.8.0 или новее. Публичный API импортируется из @microsoft/mxc-sdk/v1, а не из корня пакета. Пакет .NET также содержит нативные компоненты. Crate для Rust собирает SDK, движок и выбранные бэкенды в использующее их приложение. Для нативных исполняемых файлов нужна сборка репозитория под соответствующую платформу.

Выберите бэкенд до написания политики. В репозитории указано, что processcontainer — бэкенд по умолчанию для Windows 11, bubblewrap — для Linux, а seatbelt — для macOS. В Windows также доступны wslc и isolation_session; windows_sandbox, microvm и hyperlight помечены как экспериментальные. Linux требует выбранной среды выполнения, например Bubblewrap для стандартного бэкенда. В таблице версий Windows указаны минимальные сборки для ProcessContainer и IsolationSession. На компьютере, который будет выполнять задачу, проверьте доступность хоста и поддержку запрошенной политики.

Запишите фактическую команду, рабочий каталог, файлы, которые нужно читать и изменять, а также необходимые сетевые адреса. Считайте их параметрами политики, заданными приложением или оператором. Microsoft отмечает, что политика находится вне рабочей нагрузки агента, поэтому сгенерированный код не может расширить собственные разрешения. Ожидаемый вывод команды включает обычные stdout, stderr и код завершения, а также предупреждения или необязательные метаданные SDK. Отчёт об активности доступен только в документированных режимах диагностики на поддерживаемых хостах Windows ProcessContainer.

Задайте ограниченную политику с помощью Node SDK

В руководстве по Node SDK описана эта структура V1. Установите SDK в приложение, работающее с поддерживаемой версией Node:

Terminal
npm install @microsoft/mxc-sdk

В этом примере адаптирован вариант Microsoft с выполнением до завершения. Он запрашивает доступ только для чтения к текущему каталогу приложения и одновременно запрещает исходящие соединения. Команда лишь выводит одну строку, поэтому ни одно из этих ограничений не проверяется. Это документированная отправная точка, а не тест BIG CHANGE. Замените команду и пути на используемые рабочей нагрузкой; readwritePaths применяйте только к каталогам, которые ей необходимо изменять.

TypeScript
import { getPlatformSupport, run } from '@microsoft/mxc-sdk/v1';
import type { ContainerRequest } from '@microsoft/mxc-sdk/v1';

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC is not available on this host');
}

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  filesystem: { readonlyPaths: [process.cwd()] },
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const result = await run(request);
console.log(result.stdout, result.stderr, result.exitCode, result.warnings);

run возвращает захваченные stdout и stderr, код завершения, состояние тайм-аута и предупреждения. Заблокированный доступ к файлу может выглядеть для рабочей нагрузки как обычная ошибка «доступ запрещён»; успешное завершение само по себе не подтверждает проверку всех предполагаемых ограничений. Чтобы выполнить критерий успеха задачи, запустите на выбранном поддерживаемом бэкенде доверенную рабочую нагрузку, использующую разрешённый ресурс, а отдельно намеренно проверьте доступ к ресурсу без разрешения. Перед применением политики к командам, созданным агентом, проверьте результат и диагностические данные. В примерах SDK показаны разрешения файловой системы, блокировка сети, захват вывода и регистрация отказов. Для них нужен подготовленный хост. BIG CHANGE не выполняла эти действия.

Для пользователей нативного исполнителя стабильная схема JSON — это 1.0.0; полный запрос требует version, выбора изоляции и process.commandLine. Текущая схема разработки — 1.1.0-alpha. V1 SDK самостоятельно выбирает протокол передачи, поэтому не указывайте версию нативной схемы в типизированном ContainerRequest. В руководстве по схеме также сказано, что старые поля, например network.defaultPolicy и allowedHosts, удалены. В текущей политике используются направленные network.egress и network.ingress; прямые правила и прокси среды выполнения различаются поведением и поддержкой бэкендов.

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

В таблице режимов от 7 октября Microsoft описаны три результата. Режим Enforcement блокирует неразрешённый доступ и не создаёт отчёт об активности. Режим Learning блокирует и регистрирует неразрешённый доступ. Режим Permissive регистрирует доступ, который политика должна была бы отклонить, но позволяет ему продолжиться. В справке Microsoft по фиксации отказов указано, что функции Learning доступны только в путях Windows ProcessContainer на основе AppContainer. Другие хосты не получают аналогичную отчётность только из-за поддержки общего поля политики.

Для доверенного инструмента на этапе настройки политики нативный исполнитель Windows поддерживает поток --audit, создающий артефакты политики. Microsoft предупреждает, что для анализируемой рабочей нагрузки он отключает защиту песочницы, поэтому не подходит для ненадёжных команд. Если хост поддерживает такой режим, более безопасный путь диагностики — блокировать доступ и одновременно записывать отказ: попытка остаётся заблокированной, а отчёт показывает, что именно было запрещено. Сопоставьте каждый записанный путь или возможность с задачей, предоставьте только необходимые команде разрешения и запустите итоговую рабочую нагрузку в режиме Enforcement. В отчётах могут оказаться чувствительные имена ресурсов; обрабатывайте их соответствующим образом.

Выбор бэкенда меняет гарантии, которые может дать политика. В руководстве по схеме говорится, что isolation_session не может ограничивать сеть и требует явно неограниченной сетевой конфигурации. Там также сказано, что ограничения UI применяют Windows ProcessContainer и macOS Seatbelt, а другие бэкенды их не реализуют; WSLC и IsolationSession отклоняют переданную политику UI. В руководстве Seatbelt указано, что нативный профиль macOS не фильтрует отдельные удалённые хосты, а руководство Bubblewrap описывает требования к среде выполнения и сети в Linux. Поэтому принятие одного поля JSON несколькими типами SDK не доказывает одинаковое применение политики. Изучите руководство выбранного бэкенда и проверьте запрос на целевом хосте.

Репозиторий Microsoft распространяется по лицензии MIT, однако пользовательская документация не указывает цену пакета MXC. Расходы на хост, вычисления и любого поставщика моделей оплачиваются отдельно. В анонсе Windows MXC названа общедоступной, но несколько вариантов бэкендов остаются экспериментальными, а нативная схема разработки — альфа-версией. При выборе места запуска рабочей нагрузки учитывайте эти стадии выпуска отдельно.

Источники и дополнительная литература

  • Microsoft Windows Developer Blog, 7 октября 2026 годаподтверждает запуск, предполагаемый сценарий использования с агентами и определения трёх режимов. Это описание продукта Microsoft, а не тест безопасности BIG CHANGE.
  • README репозитория MXCперечисляет SDK, стандартные бэкенды хостов, экспериментальные бэкенды, требования к сборке и путь нативного исполнителя. Репозиторий меняется; сведения проверены 8 октября 2026 года.
  • Руководство пользователя Node SDKописывает требования к Node, импорт V1, типизированный запрос и захваченный вывод. Код выше адаптирован из его примера; здесь он не запускался.
  • Руководство по схеме конфигурацииразличает стабильную нативную схему JSON 1.0.0 и изменяемую 1.1.0-alpha, а также описывает поля политики и ограничения отдельных бэкендов.
  • Справка по режиму Learning и фиксации отказовописывает диагностику Windows ProcessContainer и предупреждает об аудите в режиме Permissive. Отчёты зависят от хоста и режима.
  • Руководства по бэкендам и таблица версий Windows помогут проверить конкретный хост; эта статья не сертифицирует конфигурации на компьютере читателя.