Microsoft Launches Azure Container Apps Sandboxes Preview

Azure Container Apps Sandboxes is Microsoft externalizing infrastructure it already runs internally: per the Apps on Azure blog and InfoQ's reporting, the same isolation fabric already powers Cloud Sandboxes in GitHub Copilot, Foundry Hosted Agents, and Azure Container Apps Express. Turning internal plumbing into a general-purpose product is a recognizable pattern once a platform vendor has already solved a hard operational problem, in this case safely executing untrusted, model-generated code, at its own scale. It also lands in a market with committed competitors: InfoQ's coverage places the announcement alongside Cloudflare's Sandboxes (launched April 2026), E2B's Firecracker-based platform, and Fly.io's Sprites (launched January 2026), each pursuing a different tradeoff between ephemeral and persistent state.

Per the Apps on Azure blog (Jun 2, 2026) and Microsoft Learn documentation, Azure Container Apps Sandboxes entered public preview as a first-class ARM resource type, Microsoft.App/SandboxGroups, alongside existing Container Apps resources like jobs and dynamic sessions. Each sandbox starts from an OCI container image, runs inside a hardware-isolated microVM, and supports snapshot-based suspend and resume that preserves full memory and disk state, sub-second startup from prewarmed pools, scale-out to hundreds of concurrent sandboxes, and scale-to-zero billing when idle. Managing sandboxes requires the Azure role Container Apps SandboxGroup Data Owner, and Microsoft Learn cautions that preview sandboxes and the SDK/CLI surface may change before general availability. Resource tiers currently top out at 2 cores and 4GB memory per sandbox (tier L), with three smaller tiers below it.

A companion post on the Linux and Open Source Blog describes an integration with Microsoft's Agent Governance Toolkit through a Python package, agt-sandbox, that enforces policy in two independent layers: AST scanning and tool allowlists applied before a code snippet executes, and network egress allowlisting enforced at the proxy layer inside the sandbox. Per InfoQ's technical writeup, network egress defaults to deny, so outbound calls are blocked unless a host is explicitly allowlisted, regardless of what the in-process policy permits, giving teams two independent points of enforcement rather than one.

Teams running LLM-generated code have historically built isolation themselves, using layered container runtimes with restrictive seccomp profiles or dedicated Kubernetes clusters running Kata Containers, both of which require ongoing operational investment. InfoQ frames the risk plainly: when an agent executes LLM-generated code in-process, the execution surface becomes the attack surface, and a single prompt injection can be enough to exfiltrate credentials or run arbitrary payloads without a hard isolation boundary. Azure's pitch bundles Entra-integrated identity, ARM-native resource management, and egress control with infrastructure already proven at GitHub Copilot's scale, whereas dedicated providers like E2B still offer faster cold starts (E2B claims sub-200ms) and more deployment flexibility, including bring-your-own-cloud options, for teams outside Azure.

Teams currently running custom isolation stacks for agentic code execution should weigh Azure's bundled identity and governance integration against real preview-stage caveats: changeable APIs, no committed GA date, and a narrower resource-tier ceiling than some dedicated sandbox vendors offer. Production adoption should track API stability, pricing changes at general availability, and whether Microsoft publishes independent security audits of the microVM and egress-proxy boundary rather than relying on marketing claims alone.

Whether ISVs and agent-platform builders adopt Sandbox Groups and the agt-sandbox policy layer in CI/CD and production agent runtimes; whether Microsoft ships the dedicated C#/Python SDKs currently listed as coming soon; and how Azure's pricing compares once general-availability pricing is published, since the current preview confirms scale-to-zero billing without full price-per-second detail.