Microsoft Execution Containers в общей доступности ограничивают права агента вне его собственного процесса

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

Седьмого октября 2026 года Microsoft объявила общую доступность Microsoft Execution Containers, сокращённо MXC. Это слой, в котором ограничения задаются политикой, а применяет их операционная система снаружи процесса агента. Впервые MXC показали как ранний предварительный вариант на конференции Build 2026 в июне. Теперь доступны контейнеры процесса и сессии, поддержка Windows 365 и пакет SDK, тогда как вариант с микровиртуальной машиной, MicroVM, остаётся экспериментальным. Ниже разобрано, из чего состоит политика, чем различаются режимы изоляции и как проверить на своей машине, что агент действительно заперт.

Контейнеры MXC держат политику вне агента, поэтому сгенерированный код не может расширить собственные права

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

Название вводит в заблуждение тех, кто ждёт привычного. MXC не сводится к контейнерам в духе Docker, где процессы делят ядро хоста и ограничены пространствами имён. Это политико-ориентированный слой исполнения: разработчик декларирует, что нужно нагрузке, а MXC сопоставляет декларацию с подходящим механизмом изоляции конкретной системы и следит за выполнением. Объектом защиты назван не только целый агент, но и плагины, инструменты и отдельные куски сгенерированного кода внутри обычного приложения.

Поддержку MXC уже заявили GitHub Copilot, OpenAI Codex, Replit, LM Studio, Unsloth AI и OpenClaw, и Microsoft обещает продолжение списка. Практический смысл ясен: агенты разных производителей начинают говорить с операционной системой на одном языке ограничений.

Политика описывает пять областей, а всё, что не разрешено явно, остаётся закрытым по умолчанию

Структура политики проще, чем можно ожидать. В ней пять областей. Первая называется containment и определяет саму среду изоляции: контейнер процесса, сессии и так далее. Вторая описывает запуск: команду, аргументы, рабочую директорию и переменные окружения. Третья относится к файловой системе, четвёртая к сети, пятая к интерфейсу пользователя.

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

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

Точный синтаксис декларации определяет SDK, и ниже он не воспроизводится. Для статьи важна логика: политика читается как перечень разрешений, а не как перечень запретов, и забытая строка делает операцию недоступной, а не доступной.

Контейнер процесса использует механизмы разных систем, а контейнер сессии отделяет учётную запись и рабочий стол

Одна декларация исполняется разными средствами. В MXC они называются механизмами изоляции, и выбор между ними определяет, насколько глубоко агент отделён от пользователя.

| Механизм | Где работает | Что делает | | Контейнер процесса | Windows, macOS, Linux | AppContainer в Windows, Seatbelt в macOS, Bubblewrap в Linux | | Контейнер сессии | только Windows 11 | отдельная учётная запись и сессия, свои рабочий стол, буфер обмена, интерфейс и ввод | | Контейнер WSL (WSLc) | только Windows 11 | среда Linux через WSL для инструментов, привязанных к Linux | | MicroVM | экспериментально | граница на уровне виртуальной машины с опорой на оборудование |

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

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

Среди экспериментальных вариантов в описаниях упоминаются также Windows Sandbox и Hyperlight. Опираться на них в работе пока рано. А вот выбор между первыми двумя вариантами уже реален и составляет основу эксперимента в конце статьи.

Режимы Enforcement, Learning и Permissive по-разному обращаются с неразрешёнными операциями и отчётом о действиях

Составить политику с нуля трудно: никто не знает заранее, какие файлы и адреса понадобятся агенту. Поэтому MXC предусматривает три режима, и различие между ними лежит в двух вопросах: блокируется ли запрещённое и остаётся ли запись.

| Режим | Неразрешённый доступ | Отчёт о действиях | Назначение | | Enforcement | блокируется | нет | рабочий запуск с боевой политикой | | Learning | блокируется и записывается | да | диагностика сбоев и проверка, что выдано только нужное | | Permissive | допускается и записывается | да | наблюдение без принудительного применения |

Отчёт хранится в формате JSON и показывает, к каким ресурсам нагрузка пыталась обратиться. Так выглядит рабочий цикл: сначала наблюдение в Permissive, затем Learning для уточнения политики, а в конце Enforcement. В режиме Permissive MXC фиксирует доступ, который политика запретила бы, но операцию не останавливает. Другие ограничения операционной системы и организации он не отменяет: если система и так не пускает, MXC не станет её переспорить.

Два ограничения в этой таблице легко упустить. Во-первых, отчёт о действиях может создавать только контейнер процесса и только в Windows. Контейнеры сессии, WSLc и MicroVM такого отчёта не дают. Во-вторых, боевой режим Enforcement отчёта не создаёт вовсе: попытка, которую MXC заблокировал, не оставит записи в виде JSON. Поэтому за блокировками в работе придётся следить другими средствами, а отчёт Learning остаётся основным инструментом настройки, но не журналом эксплуатации.

Централизованные возможности Intune и Entra объявлены как скорые, и общая доступность их не включает

Вокруг GA легко прочитать больше, чем сказано. В релиз вошли контейнеры, SDK и поддержка Windows 365, благодаря которой та же модель политики работает на облачных ПК рядом с обычной работой. Центральное управление в релиз не входит.

Политика Intune для контейнеров процесса на Windows 11 должна определять, как система оценивает создание контейнеров и какие границы применяются, но она объявлена как скоро. Разделение действий агента и пользователя в Microsoft Entra и элементы управления локальными агентами в Agent 365 тоже стоят в списке будущего. Сроков никто не назвал.

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

Стенд с восемью пробами показывает, действительно ли агент заперт в рабочей директории

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

$work = "C:\work\repo"

function Test-Tcp($h, $p) {
    $c = New-Object Net.Sockets.TcpClient
    try {
        if (-not $c.ConnectAsync($h, $p).Wait(3000)) { throw "timeout" }
    } finally { $c.Dispose() }
}

$tests = [ordered]@{
  "write_in_workdir" = { Set-Content "$work\probe.txt" "ok" -ErrorAction Stop }
  "read_config"      = { Get-Content "$work\config\app.json" -ErrorAction Stop | Out-Null }
  "write_outside"    = { Set-Content "$env:USERPROFILE\Documents\probe.txt" "x" -ErrorAction Stop }
  "read_user_keys"   = { Get-Content "$env:USERPROFILE\.ssh\config" -ErrorAction Stop | Out-Null }
  "loopback_tcp"     = { Test-Tcp "127.0.0.1" 8080 }
  "external_tcp"     = { Test-Tcp "example.com" 443 }
  "clipboard_read"   = { Get-Clipboard -ErrorAction Stop | Out-Null }
  "spawn_process"    = { Start-Process cmd.exe -ArgumentList "/c","exit" -Wait -ErrorAction Stop }
}

foreach ($name in $tests.Keys) {
    try   { & $tests[$name]; "{0,-18} ALLOWED" -f $name }
    catch { "{0,-18} DENIED  ({1})" -f $name, $_.Exception.GetType().Name }
}

Чтобы проба на loopback имела смысл, на хосте заранее нужно запустить любой локальный сервер, например python -m http.server 8080 --bind 127.0.0.1. Иначе отказ в соединении нельзя будет отличить от запрета политики. По той же причине в буфер обмена хоста полезно положить заметную метку перед запуском: пустой результат в контейнере сессии тогда читается как отделение буфера, а не как случайность.

Порядок эксперимента такой:

1. Выполнить сценарий на хосте без MXC и записать результат: все восемь проб должны вернуть ALLOWED, иначе сама проба написана неверно;
2. Составить минимальную политику: запись в рабочую директорию, чтение каталога с конфигурацией, запуск нужной команды, никаких сетевых адресов и никакого интерфейса;
3. Запустить сценарий в контейнере процесса в режиме Learning и сохранить JSON-отчёт о действиях;
4. Повторить запуск в контейнере сессии на Windows 11 и сравнить результат, особенно по пробе clipboard_read;
5. Сверить фактический результат с замыслом политики: две пробы на запись и чтение в рабочей директории разрешены, а пробы write_outside, read_user_keys, loopback_tcp, external_tcp и clipboard_read закрыты;
6. Посчитать долю неожиданно разрешённых проб из пяти запрещённых: целевое значение ноль из пяти, любое другое число означает дыру в политике или в понимании среды.

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

Минимальная политика строится из отчёта Learning, а итог проверяется повторной пробой в режиме Enforcement

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

Окончательная проверка делается в режиме Enforcement. Отчёта он не создаёт, зато сообщает самое важное: рабочая политика действует, и агент по-прежнему справляется с задачей. Для этого сценарий проб запускается внутри контейнера ещё раз, уже при боевой политике, а затем реальное задание агента выполняется целиком. Если обе проверки зелёные, политику можно считать пригодной.

Нужно помнить и о пределах. Контейнер ограничивает то, что агент может сделать на машине, но не то, что он решит сделать с выданными правами. Агент с записью в репозиторий по-прежнему способен испортить сам репозиторий. MXC уменьшает радиус последствий, а не отменяет ответственность за выданные разрешения. Один стенд на одной системе не доказывает, что результат повторится на другой версии Windows, и часть возможностей, вроде контейнера сессии, существует только на Windows 11.

Для автоматизации с ИИ эта оговорка, пожалуй, главная. Забор вокруг двора не делает собаку добрее, он лишь определяет, до каких грядок она сможет дотянуться. Когда границы описаны в политике, проверены пробами и подтверждены в боевом режиме, права агента перестают быть вопросом доверия и становятся вопросом конфигурации.