Версия Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Как настроить политику MXC для команд, созданных агентом

> MXC SDK от Microsoft позволяет разработчикам задавать команду и политики доступа к файлам и сети. Это руководство, основанное только на документации, описывает настройку для Node V1, режимы диагностики и ограничения бэкендов.

By BIG CHANGE Editorial

Published: 2026-10-08T05:14:55.341Z
Updated: 2026-10-08T05:14:55.341Z
Canonical: https://bigchange.ai/blog/mxc-agent-command-containment-guide

![Conceptual charcoal illustration of a small computer with an external drive connected and a network cable lying unplugged beside its port.](https://bigchange.ai/api/media/file/mxc-explicit-connections-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no MXC product interface, hardware, security test or enforcement result is depicted.

7 октября 2026 года Microsoft объявила о всеобщей доступности Microsoft Execution Containers (MXC). Для команд, запускающих команды, предложенные ИИ-агентом, практический вопрос состоит в том, к каким файлам и сетевым соединениям нужен доступ и какой бэкенд MXC способен обеспечить эти ограничения. В [публикации о запуске](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) описана цель изоляции; [пользовательская документация репозитория](https://github.com/microsoft/mxc) содержит сведения о настройке. Это руководство опирается на эти документы. BIG CHANGE не устанавливала MXC и не запускала изолированную рабочую нагрузку.

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

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

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

MXC — библиотека, интегрируемая в приложение, которое запускает рабочую нагрузку. В её [README](https://github.com/microsoft/mxc) перечислены 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](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) указаны минимальные сборки для ProcessContainer и IsolationSession. На компьютере, который будет выполнять задачу, проверьте доступность хоста и поддержку запрошенной политики.

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

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

В руководстве по [Node SDK](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) описана эта структура V1. Установите SDK в приложение, работающее с поддерживаемой версией Node:

```bash
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](https://github.com/microsoft/mxc/blob/main/samples/README.md) показаны разрешения файловой системы, блокировка сети, захват вывода и регистрация отказов. Для них нужен подготовленный хост. BIG CHANGE не выполняла эти действия.

Для пользователей нативного исполнителя [стабильная схема JSON](https://github.com/microsoft/mxc/blob/main/docs/schema.md) — это `1.0.0`; полный запрос требует `version`, выбора изоляции и `process.commandLine`. Текущая схема разработки — `1.1.0-alpha`. V1 SDK самостоятельно выбирает протокол передачи, поэтому не указывайте версию нативной схемы в типизированном `ContainerRequest`. В руководстве по схеме также сказано, что старые поля, например `network.defaultPolicy` и `allowedHosts`, удалены. В текущей политике используются направленные `network.egress` и `network.ingress`; прямые правила и прокси среды выполнения различаются поведением и поддержкой бэкендов.

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

В [таблице режимов от 7 октября](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) Microsoft описаны три результата. Режим **Enforcement** блокирует неразрешённый доступ и не создаёт отчёт об активности. Режим **Learning** блокирует и регистрирует неразрешённый доступ. Режим **Permissive** регистрирует доступ, который политика должна была бы отклонить, но позволяет ему продолжиться. В [справке Microsoft по фиксации отказов](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) указано, что функции Learning доступны только в путях Windows ProcessContainer на основе AppContainer. Другие хосты не получают аналогичную отчётность только из-за поддержки общего поля политики.

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

Выбор бэкенда меняет гарантии, которые может дать политика. В [руководстве по схеме](https://github.com/microsoft/mxc/blob/main/docs/schema.md) говорится, что `isolation_session` не может ограничивать сеть и требует явно неограниченной сетевой конфигурации. Там также сказано, что ограничения UI применяют Windows ProcessContainer и macOS Seatbelt, а другие бэкенды их не реализуют; WSLC и IsolationSession отклоняют переданную политику UI. В [руководстве Seatbelt](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) указано, что нативный профиль macOS не фильтрует отдельные удалённые хосты, а [руководство Bubblewrap](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) описывает требования к среде выполнения и сети в Linux. Поэтому принятие одного поля JSON несколькими типами SDK не доказывает одинаковое применение политики. Изучите руководство выбранного бэкенда и проверьте запрос на целевом хосте.

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

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

- [Microsoft Windows Developer Blog, 7 октября 2026 года](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)подтверждает запуск, предполагаемый сценарий использования с агентами и определения трёх режимов. Это описание продукта Microsoft, а не тест безопасности BIG CHANGE.
- [README репозитория MXC](https://github.com/microsoft/mxc)перечисляет SDK, стандартные бэкенды хостов, экспериментальные бэкенды, требования к сборке и путь нативного исполнителя. Репозиторий меняется; сведения проверены 8 октября 2026 года.
- [Руководство пользователя Node SDK](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md)описывает требования к Node, импорт V1, типизированный запрос и захваченный вывод. Код выше адаптирован из его примера; здесь он не запускался.
- [Руководство по схеме конфигурации](https://github.com/microsoft/mxc/blob/main/docs/schema.md)различает стабильную нативную схему JSON `1.0.0` и изменяемую `1.1.0-alpha`, а также описывает поля политики и ограничения отдельных бэкендов.
- [Справка по режиму Learning и фиксации отказов](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md)описывает диагностику Windows ProcessContainer и предупреждает об аудите в режиме Permissive. Отчёты зависят от хоста и режима.
- [Руководства по бэкендам](https://github.com/microsoft/mxc/tree/main/docs/backends) и [таблица версий Windows](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) помогут проверить конкретный хост; эта статья не сертифицирует конфигурации на компьютере читателя.

## Sources

- [Запуск Microsoft Execution Containers](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) — Анонс общей доступности, границы рабочей нагрузки и ресурсов, определения трёх режимов; заявления поставщика не являются независимыми испытаниями.
- [README репозитория MXC](https://github.com/microsoft/mxc) — SDK, стандартные настройки хостов, пометки об экспериментальных бэкендах, путь нативного исполнителя, лицензия исходного кода и требования к сборке.
- [README MXC Node SDK](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) — Импорт V1, минимальная версия Node, типизированный запрос, вывод запуска и обнаружение хоста. Пример адаптирован, но не запускался.
- [Руководство по схеме MXC](https://github.com/microsoft/mxc/blob/main/docs/schema.md) — Контракты стабильной нативной схемы JSON 1.0.0 и разработки 1.1.0-alpha, политика сети, ограничения бэкендов и интерфейса.
- [Руководство MXC по фиксации отказов](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) — Поведение Learning и Permissive в Windows ProcessContainer, предупреждение о безопасности --audit и ограничения вывода.
- [Примеры MXC SDK](https://github.com/microsoft/mxc/blob/main/samples/README.md) — Официальный список примеров для файловой системы, сети, захвата вывода и фиксации отказов.
- [Поддержка MXC версий Windows](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) — Минимальные сборки Windows для ProcessContainer и IsolationSession.
- [Руководство по бэкенду Bubblewrap для MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) — Требования стандартного бэкенда Linux и поддержка сети.
- [Руководство по бэкенду Seatbelt для MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) — Ограничения нативного профиля macOS и фильтрации удалённых хостов.