Если вы следите за агентной инфраструктурой, за последний месяц виден паттерн: каждый крупный вендор хочет стать слоем, который безопасно запускает AI-агентов. 7 октября 2026 года в эту гонку вступила Microsoft с Microsoft Execution Containers (MXC), теперь general available на версии v1.0.0.[1][3][4][5] Это уже третий серьёзный вход примерно за месяц - прямое продолжение волны managed-песочниц, которую мы покрывали при запуске Harness Runtime, Action Gateway и позже Agent Droplets у DigitalOcean.

Соблазнительно поставить MXC в один ряд с этими и считать всё три «местом, куда деплоить агентов». Это была бы ошибка. MXC - продукт другого типа с другой задачей, и понимание разницы - весь смысл этой статьи.

Что такое MXC на самом деле

MXC - это policy-driven слой выполнения для недоверенного кода или динамически генерируемых ворклоадов - в агентных терминах, для model-generated output, плагинов, инструментов, агентного харнеса или целого агента.[1][2] Разработчики и IT-администраторы объявляют ресурсы, которые может использовать ворклоад (файлы, сетевые назначения, UI), и MXC принудительно соблюдает эту границу в рантайме через OS-контейнер.[1]

Здесь важны три свойства:

  • Политика находится вне контроля ворклоада. Агент, модель, сгенерированный код, плагины - никто из них не может выдать себе больше доступа, чем разрешает политика. MXC валидирует запрос на создание контейнера, выбирает бэкенд и запускает ворклоад в контейнере, границу которого сам ворклоад расширить не может.[1][2]
  • Это SDK, а не сервис. MXC встраивается в ваше приложение. Вы пишете версионированную JSON-конфигурацию, а SDK мапит запрошенные контроли на подходящий для платформы бэкенд. Поддерживаемые SDK - Rust (mxc_sdk::v1), .NET (Microsoft.Mxc.Sdk.V1) и Node.js (@microsoft/mxc-sdk/v1).[2][3][4][5]
  • Он кросс-платформенный, но центр тяжести - Windows. MXC работает на Windows 11, Linux и macOS, но самые дифференцированные бэкенды - session-контейнер, который изолирует агента в отдельной OS-сессии с отдельным десктопом, буфером обмена и вводом, - только для Windows.[1]

Спектр изоляции

MXC - это не одна песочница. Это бэкенды с разной силой изоляции, и вы выбираете по риску ворклоада:[1]

Бэкенд Доступность Лучше всего для
Process container Windows 11, macOS, Linux Лёгкая изоляция для отзывчивых ворклоадов - сгенерированный код, выполнение инструментов (AppContainer на Windows, Seatbelt на macOS, Bubblewrap на Linux)
Session container только Windows 11 Долгоживущие агенты/автоматизация, которым нужен десктоп или более сильное отделение от интерактивного пользователя (отдельный Windows-аккаунт и сессия)
WSL container (WSLc) только Windows 11 Linux-first агентные тулчейны, зависящие от Linux-пакетной и дев-экосистемы
MicroVM Windows 11 и Linux (экспериментальный) Высокорисковые ворклоады, которым нужна аппаратно-подкреплённая виртуализированная граница

Репозиторий на GitHub перечисляет ещё больше примитивов - включая Windows Sandbox, LXC и Hyperlight - часть из которых помечена как экспериментальные.[2]

Сама политика объявляется по пяти областям: containment (какая среда изоляции), process (команда, аргументы, cwd, env), файловая система (изменяемые, read-only и недоступные локации), сеть (входящие/исходящие, включая loopback) и пользовательский интерфейс (десктоп и доступ к UI).[1]

Три режима написания и применения политики

Написать least-privilege политику, когда вы ещё не знаете каждый ресурс, к которому обращается ворклоад, сложно. Ответ MXC - три режима:[1]

  • Enforcement - запуск ворклоада с его прод-политикой; непредоставленный доступ блокируется.
  • Learning - по-прежнему блокирует непредоставленный доступ, но пишет отказы в JSON activity report, чтобы разработчики могли диагностировать сбои и убедиться, что политика даёт ровно нужное.
  • Permissive - записывает, что было бы отклонено, но пропускает операцию; удобно при написании политики. (Permissive mode не обходит другие OS- или организационные ограничения.)

Только Windows process-контейнеры дополнительно могут выдавать agent activity report - какие ресурсы ворклоад пытался использовать - конкретную помощь при составлении least-privilege политик.[1]

Что на самом деле значат v1.0.0 и «general available»

MXC был представлен как ранний SDK-preview на Build 2026 в июне.[6] Октябрьский релиз объявляет границу совместимости 1.x и стабильные SDK-поверхности, и - важно - пакеты SDK на сегодня - 1.0.1 (патч к GA 1.0.0) во всех трёх реестрах: @microsoft/mxc-sdk на npm, Microsoft.Mxc.Sdk на NuGet и mxc-sdk на crates.io.[3][4][5]

Из совместного чтения текущего репозитория GitHub и анонса следует два вывода:

  • Ядро - в GA; слой управления - нет. Слой containment (SDK, бэкенды, три режима) general available, и поддержка Windows 365 для MXC - тоже GA. Но окружающие куски явно «coming soon» без дат: Intune policy для MXC-контейнеров, Microsoft Entra, отличающий активность агента от активности пользователя, и контроли Agent 365 (атрибуция, per-agent политика, расследование) для локальных агентов.[1]
  • Репозиторий заметно созрел. Во время preview в README MXC было предупреждение, что генерируемые SDK политики «чрезмерно разрешительные» и что «никакие MXC-профили пока не стоит считать security boundaries». В эпохе 1.0.0 текущий README больше не несёт этой оговорки - но он всё ещё опирается на бэкенды платформы с разной зрелостью (несколько, включая MicroVM и Hyperlight, остаются экспериментальными).[2]

Это чтение из первых рук важно, если вы оцениваете MXC, - и именно поэтому эта статья сверяет репозиторий, а не цитирует только анонс.

MXC против DigitalOcean против self-hosted: что для чего

Это хостинг-сайт, поэтому вопрос читателей конкретный: агентов надо где-то запускать - MXC это ответ? Честный короткий ответ - нет, не для того, что вы, скорее всего, пытаетесь сделать - MXC это containment, а не хостинг. Вот настоящий расклад.

MXC: где работают агенты, а не на чём они крутятся

MXC не деплоит веб-приложения. Это не VPS, не PaaS и не маркетплейс. Это слой, который держит доступ агента в объявленных границах - поэтому он подходит, когда вы запускаете агентов там, где уже есть Windows-окружение: на машине разработчика, на Cloud PC в Windows 365 или на флоте корпоративных Windows 11, которые IT подписывает Intune (когда интеграция с Intune выйдет).[1]

Его identity-история - подсказка о целевой аудитории. Анонс обрамляет MXC вокруг containment, identity и manageability - отделение активности агента от активности человека, инструменты IT для управления и аудита. Это enterprise-питч про управление Windows, нацеленный на организации, которые уже управляют устройствами и хотят, чтобы агенты на этих устройствах оставались в коробке. GitHub Copilot, OpenAI Codex, Replit, OpenClaw, LM Studio и Unsloth - среди агентов, уже поддерживающих MXC.[1]

DigitalOcean: агенты как managed-облачная подписка

Агентные продукты DigitalOcean - противоположный конец спектра - облачные подписки, а не OS-слои. Harness Runtime запускает каждую агентную сессию в собственном Firecracker microVM с посекундным биллингом и pause/resume/checkpoint/fork; Action Gateway - managed MCP-эндпоинт, брокерящий доступ к 16 000+ инструментам.[7] Затем Agent Droplets упаковывают весь стек - compute, инференс, session storage, инструменты - в плоские $50/мес Pro или $200/мес Team.[8] Если вы вообще рассматриваете агентную нагрузку в облаке DigitalOcean, наш обзор Agent Droplets разбирает, что входит в этот плоский тариф, а что нет.

Где MXC говорит «содержи агента, который работает на уже управляемом тобой Windows-устройстве», DigitalOcean говорит «мы запустим агента за тебя в облаке, обчитаем по потреблению и отгейтим его доступ к инструментам». По модели compute пересечения нет: DigitalOcean - это хостируемый рантайм, MXC - слой containment, встроенный в ваше приложение на вашем устройстве.

Self-hosted: ваш VPS, ваша ответственность

Третий путь - тот, что предполагает этот сайт: запускать агентов на подконтрольном вам сервере, со своей песочницей там, где нужно. Дешёвый Droplet (Basic 1 vCPU / 1 GiB - $6/мес) может сегодня запускать coding agents знакомым вам тулингом - self-hosted MCP-серверы, Docker, свой выбор изоляции.[8] Инструменты вроде Coolify против Dokploy (Coolify - Apache-2.0, self-hosted) могут даже дать managed-подобный PaaS-слой поверх вашего сервера, а если цель - выставить наружу локально запущенного агента, то self-hosted HTTP-туннель даст нужный эндпоинт.[9]

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

Честная сравнительная таблица

MXC Бандл агентов DigitalOcean Self-hosted VPS
Что это OS-принудительный слой containment (SDK) Managed-облачная подписка Ваш сервер + ваш тулинг
Где работает устройство Windows 11 / macOS / Linux; Windows 365 облачные microVM DigitalOcean ваш VPS
Изоляция OS-бэкенды: process / session / WSL / MicroVM гипервизорный microVM на сессию то, что вы построите сами
Модель политики объявленная JSON-политика, три режима план + шлюз доступа к инструментам вручную
Лучше всего для Агентов на managed-корпоративных Windows / Cloud PC Команд, которые хотят хостируемую биллинговую агентную инфраструктуру Разработчиков, которым нужен контроль и переносимость
Не для Деплоя веб-приложений / общего хостинга Бутстрапа полностью вашего Linux-сервера Команд без инфра-мощностей

Какой сценарий побеждает для вас

Скажу прямо, потому что вендорского шума тут много.

MXC - правильный ответ, если ваши агенты работают в Windows-enterprise контексте: вы управляете Windows 11, хотите, чтобы агенты на этих устройствах были изолированы и в итоге управлялись Intune и Entra, и вам нужна OS-уровневая граница, которую агенты не могут расширить. Это возможность containment, и вы принимаете её внутри агентов и харнесов, которыми уже пользуетесь. Это не повод покупать хостинг.

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

Self-hosted VPS - правильный ответ, если вы уже запускаете серверы, хотите полный контроль и переносимость или плоскую предсказуемую стоимость Droplet за $6 вместо метрируемого или подписочного ценообразования. Это по-прежнему самый гибкий путь - и самый требовательный к сопровождению.

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

Вывод

Microsoft Execution Containers - по-настоящему важный вход в нишу изоляции агентов: открытый, MIT-лицензируемый, policy-driven слой containment с реальными SDK и реальным OS-принуждением, теперь стабильный на v1.0.0.[1][2][3] Но это containment, а не хостинг - он отвечает на вопрос где заканчивается доступ агента, а не где агент работает.

Когда вы решаете «где хостить агентов в 2026», вы выбираете между тремя разными типами ответов: содержать агента на уже принадлежащей вам инфраструктуре (MXC, на managed-Windows), арендовать managed-агентный compute (DigitalOcean) или владеть всем стеком на подконтрольном VPS (self-hosted). Ни один из них не «лучше» в абстракции - они подходят под разные сценарии, и честный ход - выбирать по тому, где реально работают ваши агенты, кто управляет машиной и сколько операционной нагрузки вы готовы нести.

Источники

  1. Microsoft Windows Developer Blog - «Microsoft Execution Containers: Policy-driven containment for AI agents» (07.10.2026; анонс GA; containment/identity/manageability; таблица бэкендов; пять областей политики; три режима; Intune/Entra/Agent 365 «coming soon»; Windows 365 GA; поддерживаемые агенты). https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/ - проверено 2026-10-11
  2. microsoft/mxc - README репозитория GitHub (MXC как SDK-зависимость; JSON-конфиг; SDK Rust/.NET/Node; бэкенды process/seatbelt/bubblewrap/lxc/microvm/hyperlight/WSLc; экспериментальные; лицензия MIT; примеры). https://github.com/microsoft/mxc - проверено 2026-10-11
  3. npm - @microsoft/mxc-sdk (latest-тег 1.0.1). https://www.npmjs.com/package/@microsoft/mxc-sdk - проверено 2026-10-22
  4. NuGet - Microsoft.Mxc.Sdk (latest 1.0.1). https://www.nuget.org/packages/Microsoft.Mxc.Sdk - проверено 2026-10-22
  5. crates.io - mxc-sdk (max stable 1.0.1). https://crates.io/crates/mxc-sdk - проверено 2026-10-22
  6. Microsoft Windows Developer Blog - «Build 2026: Furthering Windows as the trusted platform for development» (02.06.2026; MXC SDK представлен как ранний preview). https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/ - проверено 2026-10-11
  7. DigitalOcean Harness Runtime / Action Gateway - pricing и Docs (Firecracker microVM на сессию; посекундный consumption-биллинг; managed MCP-шлюз к 16 000+ инструментов). https://www.digitalocean.com/pricing/harness-runtime - проверено 2026-10-11
  8. DigitalOcean - Droplet pricing (Basic 1 vCPU / 1 GiB - $6/мес); Agent Droplets pricing (Pro $50/мес, Team $200/мес). https://www.digitalocean.com/pricing/droplets; https://www.digitalocean.com/pricing/agent-droplets - проверено 2026-10-11
  9. Coolify - GitHub (Apache-2.0, self-hosted) и self-hosted docs. https://github.com/coollabsio/coolify; https://coolify.io/docs/start-with-self-hosted - проверено 2026-10-11