Microsoft вывела в публичное превью Azure Container Apps Sandboxes — новый сервис для безопасного запуска кода, который генерируют и исполняют AI-агенты. Для команд, строящих агентные платформы, это важная новость: sandbox стартует из OCI-образа меньше чем за секунду, масштабируется до тысяч инстансов и не тарифицируется в простое. Для русскоязычных разработчиков и IT-руководителей смысл простой: крупный облачный вендор начал продавать изоляцию для агентного кода как штатный сервис, а не как набор самодельных костылей поверх Kubernetes.
Речь идет о новом типе ARM-ресурса Microsoft.App/SandboxGroups, сообщает InfoQ. По модели Azure это отдельная сущность для управления группами песочниц: туда выносятся общие сетевые правила, managed identity, lifecycle-политики и ресурсные тарифы. Внутри каждая песочница работает в собственной microVM с аппаратной изоляцией от хоста, платформы и соседних окружений на той же инфраструктуре. Microsoft делает акцент не на абстрактной «безопасности AI», а на вполне приземленном сценарии: если модель сгенерировала код, а агент исполняет его в том же процессе, поверхность исполнения мгновенно становится поверхностью атаки.
И это не теоретическая угроза для презентаций с красивыми схемами. Даже без сторонних библиотек Python-агент может сходить по URL, прочитать переменные окружения, дернуть exec() или загрузить произвольный payload через стандартную библиотеку. Дальше сценарий знаком любой команде, которая хоть раз разбирала инцидент после prompt injection: утекшие ключи, неожиданные запросы наружу, компрометация внутреннего контура. До сих пор у многих компаний выбор был не слишком вдохновляющий. Либо собирать собственную изоляцию на контейнерных рантаймах с урезанными seccomp-профилями, либо поднимать отдельные кластеры Kubernetes с Kata Containers, а потом годами оплачивать операционную сложность этого решения. Azure Container Apps Sandboxes пытается закрыть именно этот класс задач сервисом из коробки.
Технически Microsoft обещает быстрый жизненный цикл за счет pre-warmed pools: песочницы поднимаются не «с нуля», а из заранее прогретых пулов, поэтому старт укладывается в время менее секунды. Источник выполнения — любой OCI-совместимый контейнерный образ, что снимает часть проблем с переносимостью. Для агентных нагрузок это выглядит логично: короткие bursty-задачи, много параллельных запусков, неровный профиль нагрузки и периоды полного простоя между сессиями. Отсюда и тарифная логика «ноль в idle»: платить предлагается не за постоянно живущий кластер, а за фактическое выполнение. Для платформенных команд и финконтроля это, возможно, даже важнее самого cold start. В обычной корпоративной реальности аргумент «безопаснее» часто проигрывает аргументу «не раздувает счет за инфраструктуру, когда агент ничего не делает».
Отдельно Microsoft подчеркивает операционные функции, без которых такой сервис быстро превратился бы в демонстрацию, а не в рабочий инструмент. Снимки состояния позволяют приостанавливать и возобновлять сессию с сохранением памяти и диска. На практике это означает, что агент может остановить многошаговое расследование, среду разработки с уже установленными пакетами или длинный workflow, уйти в zero scale, а потом продолжить без полной переинициализации. Для разработчиков это попытка примирить два мира: с одной стороны, жестко изолированную и короткоживущую среду, с другой — потребность не терять состояние после каждого шага. Рынок уже показал, что «полностью эфемерный» подход не всем нравится: чем сложнее агент, тем болезненнее пересобирать его окружение снова и снова.
Вторая важная часть — сетевые и идентификационные ограничения. В исходной конфигурации outbound-трафик запрещен, а доступ наружу открывается только к явно разрешенным хостам. Microsoft пишет, что это контролируется на proxy-уровне внутри sandbox, то есть запрет действует независимо от того, что считает допустимым код внутри процесса. Параллельно поддерживаются system-assigned и user-assigned Entra managed identities, чтобы песочницы ходили в Azure-сервисы без вшитых секретов и без передачи ключей через переменные окружения. Для enterprise-сценариев это звучит как главный selling point: не просто «запустили код в изоляции», а встроили его в обычную Azure-модель доступа, аудита и управления ресурсами.
Для дополнительного контроля Microsoft выпустила Agent Governance Toolkit с Python-пакетом agt-sandbox. Он добавляет два слоя проверок до запуска фрагмента кода: AST-сканирование и allowlist для инструментов. После этого отдельно работает сетевой allowlist уже на границе окружения. Microsoft специально разводит эти уровни: если вызов запрещен политикой, он не дойдет до исполнения; если агент все же попытается обратиться к хосту вне списка, запрос упрется в прокси, даже если внутренняя политика процесса его не заметила. Для команд, которые строят multi-tenant-платформы, LLM-интерпретаторы кода или CI/CD-автоматизацию, это важная деталь. В 2026 году рынок уже не спорит о том, нужна ли изоляция агентам. Вопрос теперь в том, где именно ставить границы: на AST, на уровне tool permissions, на сети, на runtime или сразу везде.
Контекст у анонса тоже показательный. Microsoft прямо называет продукты, которые уже сидят на этой инфраструктуре: Cloud Sandboxes в GitHub Copilot, Foundry Hosted Agents и Azure Container Apps Express. Это сильный архитектурный сигнал: компания не продает клиентам «новую модель доверия», а открывает тот же изоляционный слой, на котором строит собственные девелоперские продукты. На фоне конкурентов это и есть главная ставка Azure. В апреле 2026 года Cloudflare запустила Sandboxes с persistent Linux-окружениями и оплатой за активный CPU. E2B продолжает набирать вес как специализированная платформа для исполнения агентного кода на Firecracker microVMs, в том числе у крупных корпоративных клиентов, и делает ставку на быстрый cold start и опцию BYOC. Fly.io еще в январе 2026 года представила Sprites с persistent-by-default-моделью и локальным NVMe-хранилищем, фактически споря с самой идеей «пересоздавать состояние как норму». Иными словами, рынок уже crowded, но Microsoft идет не в лоб за самым эффектным числом миллисекунд. Ее ход — продать Azure-native интеграцию: ARM, Entra, сетевые политики и управляемый lifecycle без отдельного оркестрационного зоопарка.
Для бизнеса вывод довольно трезвый. Если компания уже живет в Azure и хочет запускать недоверенный код от AI-агентов без отдельной команды, которая будет поддерживать зоопарк из контейнерных ограничений, Kubernetes и пользовательских политик, у Azure Container Apps Sandboxes есть понятная ценность. Если же нужны GPU-нагрузки, жесткие требования по data residency вне Azure, собственный контур исполнения или предпочтение в пользу open source-изоляции, специализированные игроки пока выглядят гибче. Главный вопрос теперь не в том, приживутся ли песочницы для агентного кода как класс. Вопрос в другом: останется ли безопасное исполнение feature для отдельных платформ или в ближайший год превратится в такой же обязательный слой AI-инфраструктуры, как secrets management и observability. Подробности анонса собраны в материале .