Microsoft решила не ждать, пока AI-агенты окончательно превратятся в новый класс корпоративного риска, и 19 июня вывела в публичную повестку свою ставку на безопасность AI-агентов в Windows. Речь не о еще одном SDK для разработчиков, а о попытке сделать саму ОС местом, где агенту заранее отмеряют права, отдельную идентичность и наблюдаемость, чтобы он не гулял по машине как слишком любопытный стажер с правами администратора.
Как сообщает InfoQ, опорной частью этой схемы стал Microsoft Execution Containers, или MXC, в виде раннего preview SDK. В посте Windows Developer Blog от 2 июня Microsoft объясняет идею довольно прямо: для автономных агентов недостаточно проверять модель, промпты и приложение, потому что риск теперь живет еще и на уровне исполнения. Поэтому containment, identity и manageability компания хочет встроить в Windows как базовые примитивы. Иными словами, агенту предлагают не просто выдать задачу, а сразу посадить его в контролируемый контур, где видно, кто он, к чему он может прикоснуться и что именно сделал.
Технически MXC выглядит как policy-driven слой исполнения для Windows и WSL. Разработчик описывает ограничения в JSON или через TypeScript SDK, а система уже сама подбирает подходящий механизм изоляции под конкретный сценарий. Для более легких задач, например запуска кода, сгенерированного моделью, Microsoft предлагает process isolation. Для долгих сценариев с автоматизацией, которым нужен собственный рабочий стол, буфер обмена и отдельная сессия, есть session isolation. В последнем случае агент получает отдельную учетную запись, локальную или облачную с привязкой к Entra, а значит, его действия можно отделить от действий человека не на словах, а в логах и политиках доступа. Для корпоративных администраторов это важный сдвиг: проблема «кто именно полез в этот файл и почему» становится хотя бы формально разруливаемой.
Дальше Microsoft показывает дорожную карту, и она заметно амбициознее текущего preview. В планах есть micro-VM для более рискованных нагрузок, где нужен уже не просто процессный контейнер, а более жесткая граница изоляции через гипервизор. Отдельно обещана поддержка Linux-контейнеров через WSL для инструментов и ML-стеков, которые живут в Linux-мире и не собираются переезжать ради удобства корпорации из Редмонда. Еще один слой сверху — будущая интеграция MXC с Windows 365 for Agents, а сам сервис Windows 365 for Agents, по словам Microsoft, уже доступен в статусе general availability. Идея очевидна: часть агентных задач можно унести на облачный Cloud PC, чтобы компрометация не происходила на пользовательском устройстве. Параллельно управление обещают отдать стандартному корпоративному набору Microsoft: Entra ID, Intune, Defender и Purview. То есть компания продает не просто песочницу, а целый стек governable-агентов, который приятно показывать CISO и не стыдно тащить на комитет по рискам.
На бумаге все выглядит ровно так, как и должна выглядеть зрелая платформа под безопасность AI-агентов: минимум привилегий, отдельные identity, проксирование вызовов к инструментам, аудит, телеметрия, централизованные политики. Microsoft отдельно привязывает эту историю к своим давним системным инвестициям: Secure Boot, passwordless sign-in, hotpatching, драйверы на memory-safe языках и даже постквантовую криптографию в Insider-сборках. Логика простая: если Windows годами укрепляли как пользовательскую и корпоративную платформу, то агенты должны наследовать этот фундамент. Вдобавок Defender компания позиционирует как защитный слой против prompt injection и других уже вполне прикладных угроз для агентных систем.
Но здесь начинается самая интересная часть, и она уже не из пресс-релизов. Ранние разборы MXC довольно осторожны. Сам репозиторий Microsoft на GitHub прямо предупреждает: это early preview, текущие профили могут быть слишком разрешающими, а сами профили пока нельзя считать полноценной security boundary. Там же указано, что outbound network filtering на Windows еще не поддерживается. Для классического desktop-софта такая недоработка неприятна, для агента она критична: если компрометация и случится, то первое, что захочется злоумышленнику, — не обязательно ломать систему дальше, а спокойно вынести данные наружу. Поэтому MXC пока скорее направление развития, чем готовый ответ на вопрос, можно ли уже завтра запускать в нем автономных помощников с доступом к внутренним документам, CRM и dev-инфраструктуре.
И Microsoft здесь точно не бежит в одиночку. Вне Windows-экосистемы рынок уже давно тестирует другие модели: от OpenShell у NVIDIA до изоляции агентного кода в Kubernetes через gVisor и Kata Containers, плюс облачные sandbox-подходы на microVM. Linux-мир традиционно делает ставку ближе к ядру: cgroups, namespaces, seccomp, Landlock, eBPF и прочие инструменты, которыми можно обвешать агента без создания еще одной большой платформенной абстракции. На этом фоне MXC интересен именно тем, что пытается собрать разные механизмы под единым policy-слоем и засунуть их в mainstream Windows и WSL. Для разработчиков это снижает входной порог, для бизнеса обещает более предсказуемую модель управления, а для ИБ-команд создает шанс наконец говорить об агентах не как о магии вокруг LLM, а как о еще одном типе workloads с понятными границами и журналированием.
Практический вывод для русскоязычной IT-аудитории довольно приземленный. Если у вас в компании уже экспериментируют с coding agents, desktop automation или внутренними AI-помощниками, главный вопрос теперь не в том, умеет ли агент открыть файл или вызвать CLI, а в том, где заканчиваются его полномочия и кто это докажет после инцидента. Microsoft пытается сделать из Windows ответ на этот вопрос, но пока это именно ранняя инфраструктура, а не готовый бронежилет. Ближайшая интрига в том, какая модель окажется сильнее в проде: встроенная в ОС политика вроде MXC или более жесткие sandbox-решения из Linux и облачного мира, где безопасность AI-агентов давно измеряют не презентациями, а качеством границ. Проверить исходный разбор можно в .